| [cdt-dev] Analysis and solutions for Open Declaration/Definition: MSVC extensions |
Another big 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.
In my testing, I implemented 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). The code for this is uninteresting so it's not included here. (Both extensions are a hack, IMHO: I think these specifiers should be stored in the DOM, if only as strings, since they may provide added context later on -- for instance, these attributes/declspecs can indicate deprecated APIs, and code completion shouldn't propose these.)
BTW, regarding parser extensibility mentioned in Doug's recent CDT DOM slides: I think the current model of providing extension configurations is a good direction to go. Codewarrior worked similarly (though with build-time macros) and different targets could implement custom parsers for certain things like #pragmas, declspecs, attributes, and inline assembly.
If the parser extensions could also do parsing and create IASTNodes and types, then you could really have a reasonably generic and extensible C/C++ parser. It may be useful to query for adapters on the extension configuration to support future extensions, rather than adding new methods and revving the internal API for every oddball case out there....
-- Ed