| [cdt-dev] Analysis and solutions for Open Declaration/Definition: remaining random issues |
Smattering of issues too small to put in individual messages:
* Not really related to Open Decl/Defn, but found along the way: You get "can not find include file" error dialogs from OpenIncludeAction when opening #includes from a non-workspace file editor's Outline, because there is no context for which project should provide #includes. I think a reasonable fallback is to search the same directory as the current file, since (1) most BSD-style compilers look up files relative to the current file and (2) assuming the current file is itself available via #include, anything it #includes from its own directory should be accessible as well. Sound reasonable?
* Also peripherally related: I noticed in several places (CModelManager#createTranslationUnitFrom, TranslationUnit#getLanguage) that the fallback for determining the ILanguage for header files is to treat them as C. Why? I'd argue that C++ is a better fallback, since it is mostly a superset of C (K&R notwithstanding). OTOH, parsing C++ source as C will almost always fail. Changing such fallbacks to use C++ improved the navigation experience, esp. when navigating from a C++ *.h file opened in isolation, as is common in S60/Symbian programming, whose C++ headers are all *.h. Any arguments against this?
* OpenDeclarationsAction has commented-out code reflecting the PDOM lookup style recommended in slide 17 of Doug's recent CDT slides:
int style = 0;
// IPDOM pdom = CCorePlugin.getPDOMManager().getPDOM(workingCopy.getCProject());
// if (!pdom.isEmpty())
// style |= ILanguage.AST_SKIP_ALL_HEADERS | ILanguage.AST_USE_INDEX;
IASTTranslationUnit ast = workingCopy.getLanguage().getASTTranslationUnit(workingCopy, style);
OpenDefinitionAction does use this style. Unfortunately, OpenDeclarationsAction fares better without it. I get much fewer results using the commented-out code. I haven't investigated why, yet. Thus, setting the style to 0 in both Open*Actions works pretty reliably but every F3/Ctrl-F3 lookup requires a full parse of the entire source file (which takes about four seconds with S60 headers included). Any suggestions?
-- Ed