Menu
▾
▴
1 Attachments
#973 Functions affected by compiler option disappear from Symbols List
Geany version: 1.23 (built on Apr 7 2013 with GTK 2.24.10, GLib 2.32.3)
OS version: Ubuntu 12.04 (fully updated) running mainline kernel 3.4.49-030449-generic
The problem is, as stated in the title, functions affected by a compiler option disappear from Symbols List.
I'm attaching an example file to further evidence the problem.
Functions with or without the gcc __attribute__ appear just fine. However, if I have the need to use a #define keyword for flexibility or a non-gcc option the symbols list will not display such functions.
This is a know issue, and it's quite hard to address because macros can expand to absolutely anything. The only real perfect fix would be to expand macros, but it would require to know them -- and we don't (and won't) perform inclusion to get them.
The recommended workaround is to add your attributes to ignore.tags (see the documentation).
For the
@somethingattributes, what does use this? ICC? MSVC? Anyway if it's not too obscure we would accept a patch.Humm, ok. You say it is a known issue, but I searched for bugs involving symbols and didn't found a suitable one, so I opened one. Hope this wasn't a problem.
I understand and agree with your macro expansion argument. Besides as the list of options is quite manageable your suggested workaround works just fine for me.
However, just out of curiosity why would we want to parse the macro? I mean, why not just accept that "something" can be there and ignore it?
Regarding the patch, the options I have are for the IAR compiler. I don't think it is a good idea to incorporate in Geany a change for it, since it is a specific compiler and options (unfortunally) tend to change between versions. But thanks for being open to that option!
No problem to raise it, its "known" in the context of the general class of problems where an unexpanded macro that is incorrect syntax will break the parser even if its expanded form would be syntactically correct.
As for allowing "something" there (by which I presume you mean after the prototype) well, how much do you ignore?
Ignoring stuff at all the places where various compilers allow their non-standard extensions is likely to get the parser out of sync on other code and break it that way.
The gcc syntax is supported because 1) its a very popular compiler and others follow its lead, and 2) someone provided the patch (probably to the upstream ctags project).
We can only hope that C follows C++11 and defines an attribute syntax and eventually compiler makers support such a standard.
Sorry for my delay in seeing your reply, but I think a didn't got a notification.
You are right about the "how much" should be ignored...probably not so much without screwing the parser.
I'm glad there is a simple solution for me, if at some point this solution does not work for me, I'll probably try to submit a patch.