This fixes crashes when using incomplete "type" declarations.
Fixes #2358, fixes #2982 and fixes #2428.
The `initTagEntry()` call is necessary to initialize the `TagEntryInfo` object. The `KIND_GHOST_INDEX` argument is taken from the uctags Pascal parser. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2987
-- Commit Summary --
* <a href="https://github.com/geany/geany/pull/2987/commits/4d0874e184fb8093ffd8d39acb54902cc3497a5a">Pascal parser: ensure TagEntryInfo is always initialized</a>
-- File Changes --
M ctags/parsers/geany_pascal.c (2) M tests/ctags/Makefile.am (1) A tests/ctags/issue2358.pas (20) A tests/ctags/issue2358.pas.tags (3)
-- Patch Links --
https://github.com/geany/geany/pull/2987.patch https://github.com/geany/geany/pull/2987.diff
@eht16 commented on this pull request.
@@ -51,7 +51,7 @@ static void createPascalTag (tagEntryInfo* const tag,
else { /* TODO: Passing NULL as name makes an assertion behind initTagEntry failure */
Not so sure about this comment but I left it as it is also still present in the uctags Pascal parser.
Is this fixed in #2984?
Is this fixed in #2984?
Not sure. I guess not as it doesn't contain parser changes.
Ok, good, that also means it won't undo it when #2984 is merged.
@eht16 pushed 1 commit.
bf6c1f7e9ffb5e4692a27c4b3c68ad35811bda1b Pascal parser: ensure TagEntryInfo is always initialized
Tested the problematic type declaration against #2984 *without* this change and it still crashes. Tested the problematic type declaration against #2984 *with* this change and it still works.
Also added another example declaration to the test case for better coverage (and it triggered Travis CI which is working again).
@techee what do you think? Should we consider merging this or rather handle it in #2991 (or a following PR)?
@techee what do you think? Should we consider merging this or rather handle it in #2991 (or a following PR)?
Has this change been submitted upstream so it doesn't get lost?
Basically this depends on the outcome of the discussion in #2991 (do you have any feedback for that one?). Pascal is one of the languages we could probably take from uctags and if we do (and this change isn't there yet), this patch should wait until #2991 is merged, otherwise it gets overwritten.
@techee what do you think? Should we consider merging this or rather handle it in #2991 (or a following PR)?
Has this change been submitted upstream so it doesn't get lost?
The change in the parser itself is actually taken from uctags.
Basically this depends on the outcome of the discussion in #2991 (do you have any feedback for that one?). Pascal is one of the languages we could probably take from uctags and if we do (and this change isn't there yet), this patch should wait until #2991 is merged, otherwise it gets overwritten.
https://github.com/geany/geany/pull/2991#issuecomment-981063263.
@eht16 I guess this pull request is superseded by #3043 and can be closed, right? (Just trying to keep track of all the parser pull requests we have open.)
@techee yes, that's the plan. This PR should be closed automatically when #3043 is merged.
Closed #2987 via #3043.
github-comments@lists.geany.org