The multi-line comment within a macro means that `int y` (and all code following it) doesn't get parsed by ctags: ```c int x;
#define CHANGE_TREE(new_child) \ G_STMT_START { \ /* only change the tag tree if it's actually not the same (to avoid flickering) and if * it's the one of the current document (to avoid problems when e.g. reloading * configuration files */ \ if (child != new_child && doc == document_get_current()) \ { \ if (child) \ gtk_container_remove(GTK_CONTAINER(tag_window), child); \ gtk_container_add(GTK_CONTAINER(tag_window), new_child); \ } \ } G_STMT_END
int y; ``` Removing the comment restores parsing. The macro is actually from Geany's sidebar.c, but #2345 gets rid of it.
Escaping the newlines within the multi-line comment also seems to fix it.
Technically the macro is correct as is, translation phase 2 (removal of backslash newline pairs) and translation phase 3 (replacement of comments with a single space) are run before translation phase 3 (the preprocessor) which therefore will see the `#define` on one line as is required.
So its a ctags error, and if somebody could be bothered they could open a ctags issue.
To be clear, the reason it doesn't seem worth too much effort is:
1. its a function of the rather esoteric language lawyer ordering of the translation phases and I doubt ctags emulates them at all
2. @codebrainz has indicated a perfectly reasonable workaround that works for humans too
I think this bug is significant because it breaks parsing of all tags after the macro. I'll see if upstream has fixed it.
@codebrainz has indicated a perfectly reasonable workaround that works for humans too
People reading code like this typically don't have write access to the source repository. A project might not accept the change and argue it's valid C and therefore a geany bug that should be fixed.
@ntrel, ok if you want to merge an upstream patch into Geany's c.c good luck :)
I think it's worth supporting because IMO we should not break on valid input, but depending on the difficulty it might be worth waiting on us getting the new uctags C and C++ parser. Yes, I'll try and really get that thing merged "soon".
it's driving me nuts as well if you're constantly adding this file like I am currently. sidebar and goto definition become broken as well.
@b4n, good point the upstream "fix" might be part of that rather than the conventional `c.c`.
@kugel why don't you push a quick fix of putting the backslashes on the comment if its causing you so much problem.
...depending on the difficulty it might be worth waiting on us getting the new uctags C and C++ parser.
Not that I'm volunteering, but after having a peek in `lcpp.c`, I don't think it would be that hard to fix.
@elextr I'd like to keep the incentive to fix the problem for real, if it even occurs inside Geany's codebase.
@kugel, fine consider yourself incentivised, I'll expect a PR imminently :grin:
Though to be serious, as noted above it may only be until the new C/C++ parser is incorporated.
Closed #2349 via #3032.
github-comments@lists.geany.org