Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect type highlight in presence of macros #1654

Open
codebrainz opened this issue Oct 22, 2017 · 2 comments
Open

Incorrect type highlight in presence of macros #1654

codebrainz opened this issue Oct 22, 2017 · 2 comments

Comments

@codebrainz
Copy link
Member

codebrainz commented Oct 22, 2017

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

#define BLEH
struct foo BLEH { 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.

@b4n
Copy link
Member

b4n commented Oct 22, 2017

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:

G_GNUC_DEPRECATED_FOR+
G_GNUC_PRINTF+
G_GNUC_SCANF+
G_GNUC_FORMAT+
G_GNUC_*
G_DEPRECATED
G_DEPRECATED_FOR+
G_UNAVAILABLE+
G_DEFINE_TYPE+
G_DEFINE_TYPE_EXTENDED+
G_DEFINE_TYPE_WITH_CODE+
G_DEFINE_BOXED_TYPE+
GLIB_AVAILABLE_*
GIO_AVAILABLE_*
GDK_AVAILABLE_*
GTK_AVAILABLE_*
GLIB_DEPRECATED_IN_2_50_FOR+
GLIB_DEPRECATED_IN_2_48_FOR+
GLIB_DEPRECATED_IN_2_46_FOR+
GLIB_DEPRECATED_IN_2_44_FOR+
GLIB_DEPRECATED_IN_2_42_FOR+
GLIB_DEPRECATED_IN_2_40_FOR+
GLIB_DEPRECATED_IN_2_38_FOR+
GLIB_DEPRECATED_IN_2_36_FOR+
GLIB_DEPRECATED_IN_2_34_FOR+
GLIB_DEPRECATED_IN_2_32_FOR+
GLIB_DEPRECATED_IN_2_30_FOR+
GLIB_DEPRECATED_IN_2_28_FOR+
GLIB_DEPRECATED_IN_2_26_FOR+
GLIB_DEPRECATED_IN_*
GLIB_EXTERN
GLIB_VAR
__STL_NOTHROW
__THROW
GIT_EXTERN=extern
cairo_public
GEANY_DEPRECATED
GEANY_PRIVATE_FIELD
GEANY_DEPRECATED_FOR+

@masatake
Copy link
Contributor

I'm working this topic in u-ctags side.

With the change I proposed in universal-ctags/ctags#2543, ctags can capture foo well:

$ cat /tmp/foo.c
#define BLEH
struct foo BLEH { int _; };
$ u-ctags --param-CPreProcessor:_expand=1 --fields-C=+{macrodef} --fields=+S -o - /tmp/foo.c
<sor:_expand=1 --fields-C=+{macrodef} --fields=+S -o - /tmp/foo.c
BLEH	/tmp/foo.c	/^#define BLEH$/;"	d	language:C	file:	macrodef:
_	/tmp/foo.c	/^struct foo BLEH { int _; };$/;"	m	language:C	struct:foo	typeref:typename:int	file:
foo	/tmp/foo.c	/^struct foo BLEH { int _; };$/;"	s	language:C	file:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants