I have a large code base of a library that uses __attribute((visibility ("default"))) to export the classes that should be part of the interface. KDevelop cannot handle these attributes which leads to errors in the code completion. Though this is a compiler specific problem (MSVC uses annotations like __declspec(dllexport)) and thus not valid c++, this severely impedes the user experience. Reproducible: Always Steps to Reproduce: The code below is a typical example of a class declaration we use: class __attribute((visibility ("default"))) Foo { Foo* child; }; Actual Results: The code completion/parser/... cannot resolve Foo in the declaration of child as a known class. Expected Results: Foo should be properly resolved, as is the case when removing the __attribute(...) Due to the compiler specificness of the problem the __attribute(...) is usually wrapped in a macro. This macro evaluates to the needed annotation. KDevelop seems to parse the macro just fine though.
Uhm isn't it __attribute__ (note the trailing two underscores)? That is actually being parsed just fine by our parser?
yeah, see also: http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
You are absolutely right... Interestingly GCC seems to accept __attribute((...)) just fine and there are some examples in the Documentation (man pages) where __attribute((...)) is used. Might be, that they changed the syntax some time ago and are now phasing out the support for the old version, Oh well, changing the macro to use __attribute__((...)) fixes the problem for me. Thanks a lot! :-)
Moving all the bugs from the CPP Parser. It was not well defined the difference between it and C++ Language Support and people kept reporting in both places indistinctively