Community
Participate
Working Groups
A blocker for Win32 development is silent failures while parsing due to unrecognized compiler extensions. Win32 SDKs, even when building with Cygwin, will have sources with the MSVC extension "__declspec( <stuff> )", primarily to mark symbols for import or export. Without this support, SDK classes, each of whose methods are imported/exported, are instead full of IProblemNodes, which obviously limits the success of a search. __declspec() has functionally equivalent extensions as GCC's __attribute__() but it appears in the declarator part of a declaration rather than being tacked on to the end. GCC supports __declspec under Cygwin as well. I tested a solution by implementing parser support similarly to __attribute__ (i.e., adding a configuration flag to the parser extension configuration, then if allowed, parsing it and throwing everything away). A more complete solution would have both the existing __attribute__ parsing and __declspec parsing add declaration specifiers to the DOM, since they contain information that may be useful in the future (for instance, marking API as deprecated, which can aid code completion). Is this is an appropriate solution?
Created attachment 50657 [details] test patch for __declspec() Another test patch. Note that the changes for the GNU configuration extension impls hackishly enable __declspec support based on the _host_ platform, not the _target_ platform.
Change component to non-deprecated one
Created attachment 54881 [details] test cases for this I've taken a look at this patch, and to the best of my limited understanding of the parser internals, it looks good. I've attached some test cases that I used to test it one question though - I saw on msdn that __declspec is not allowed as part of a declarator, yet the parser does not throw an exception or have problems in the AST. This might be a problem with my understanding but wanted to raise this. (there is a commented out test in the patch "test158192_false_positive()" that shows this)
(In reply to comment #3) > one question though - I saw on msdn that __declspec is not allowed as part of a > declarator, yet the parser does not throw an exception or have problems in the > AST. This might be a problem with my understanding but wanted to raise this. This is true for MSVC, but Codewarrior and GCC support this placement. IMHO, since the parser is not trying to compile the language, it should be more forgiving than the compiler when it comes to language extensions (because, being extensions, they are not standard, and may change over time).
It is certainly our intention to support the MSVC language extension officially. As of CDT 3.x, though MSVC isn't a supported environment. Part of my plan for supporting the Windows SDK will be to solve these problems.
> This is true for MSVC, but Codewarrior and GCC support this placement. yes, after trying out the different compilers I see this is a good behaviour for gcc, and a more useful behaviour (although not strictly correct) for MSVC I'd be happy to apply this to the 3.1 branch, if this is ok with you Doug?
Sure. The current extensions mechanism is hacky at best. But it'll take us quite a while before we figure out the right way to do it, so feel free to apply this.
Committed on 3.1 branch thanks Ed! :)
Created attachment 57608 [details] patch applied to CDT 4.0 HEAD applied Ed's fix to CDT 4.0 HEAD
