You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In C/C++ filetype, if you add some macros into a type definition (ex. struct, enum, etc), the last token before the opening brace of the definition seems to be taken as the type name. I guess this is a bug in old c.c ctags parser.
Example
#defineBLEHstructfooBLEH { int_; };
Here, BLEH gets highlighted as the type name instead of foo.
Use case
Using macros for things like GNU C's __attribute__ extension.
Version
I don't think version matters at all, but I'm using a fairly recent 1.32 build.
The text was updated successfully, but these errors were encountered:
Tricky preprocessor :) The thing is that it would be perfectly valid to have struct BLEH foo in your example, esp. as it expands to nothing. Meh.
Maybe you could try current Universal-CTags that has a totally new C and C++ parser, it would be interesting to see what the stock behavior is here (it might be better or worse I guess).
A workaround is to use ignore.tags and list your macros there. E.g. mine contains a lot of GLib's macros and a few others:
Description
In C/C++ filetype, if you add some macros into a type definition (ex. struct, enum, etc), the last token before the opening brace of the definition seems to be taken as the type name. I guess this is a bug in old
c.c
ctags parser.Example
Here,
BLEH
gets highlighted as the type name instead offoo
.Use case
Using macros for things like GNU C's
__attribute__
extension.Version
I don't think version matters at all, but I'm using a fairly recent 1.32 build.
The text was updated successfully, but these errors were encountered: