Pascal parser: ensure TagEntryInfo is always initialized

[eht16]

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.

[eht16]

Not so sure about this comment but I left it as it is also still present in the uctags Pascal parser.

[elextr]

Is this fixed in #2984?

[eht16]

Is this fixed in #2984?

Not sure. I guess not as it doesn't contain parser changes.

[elextr]

Ok, good, that also means it won't undo it when #2984 is merged.

[eht16]

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).

[eht16]

@techee what do you think? Should we consider merging this or rather handle it in #2991 (or a following PR)?

[techee]

@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.

[eht16]

@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.

#2991 (comment).

[techee]

@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.)

[eht16]

@techee yes, that's the plan. This PR should be closed automatically when #3043 is merged.