#973 Functions affected by compiler option disappear from Symbols List

C (2) tags (1)

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.

1 Attachments


  • Colomban Wendling

    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 @something attributes, what does use this? ICC? MSVC? Anyway if it's not too obscure we would accept a patch.

  • Colomban Wendling

    • labels: --> C, tags
    • Priority: 5 --> 3
  • DarkVenger

    DarkVenger - 2013-06-25

    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!

  • Lex Trotman

    Lex Trotman - 2013-06-26

    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.

    • DarkVenger

      DarkVenger - 2013-07-24

      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.

  • Colomban Wendling

    • Found in: --> v1.23
    • Fixed in: v1.24 --> None

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks