Community
Participate
Working Groups
The structural parse mode in CDT uses the complete parser which expects code to be syntactically and semantically correct. This is not desirable behaviour when you want the parser to make a best attempt at building a model because certain non-fatal errors can cause the parser to bail out (especially in code involving templates). Structural parse mode should be using the quick parser. The only difference would be that it should also follow inclusions. I posted a patch for this as part of bug 185536, but I'll separate it out and post here because it's a significant enough change.
What do you mean by quick parse? Do you mean skipping function bodies? The error handling code in the parser was meant to recover from as many errors as possible. Would spending time enhancing this help? What are the ill affects of this change?
Just to clarify in case anyone wasn't sure, this is on the outline parser in 3.x, not in the DOM parser.
(In reply to comment #2) > Just to clarify in case anyone wasn't sure, this is on the outline parser in > 3.x, not in the DOM parser. Yes, that does make more sense now :)
> What do you mean by quick parse? Do you mean skipping function bodies? ParserMode.QUICK_PARSE, which entails skipping inclusions and function bodies. > What are the ill affects of this change? None from what I can see. Changing Parser to use QuickParseASTFactory instead of the CompleteParseASTFactory while in ParserMode.STRUCTURAL_PARSE mode actually speeds up the structural parse test cases without loss in accuracy. The only affected client is the model builder. No other clients use STRUCTURAL_PARSE.
Created attachment 67100 [details] Proposed patch
Applied to the cdt_3_1 branch. Thanks Jay.
Janees please verify.
Verified this fixed and works fine. But, there is a problem with the current approach, after making the changes in preference page (C/C++ -> Follow #includes while parsing working copies), i see that, the changes are not effected immediately, unless you modify the file or restart the workbench. This is an issue if the file is in source control. I suggest issue a refresh on all C/C++ project when this particular preference change, or Popup a dialog (OK /Cancel dialog) asking user, whether to restart the workbech for changes to take effect. Workbench can be restart by calling org.eclipse.ui.IWorkbench.restart()
> But, there is a problem with the current approach, after making the changes in > preference page (C/C++ -> Follow #includes while parsing working copies), i see > that, the changes are not effected immediately, unless you modify the file or > restart the workbench. This is an issue if the file is in source control. Since model information is cached, all open C/C++ editors would need to be closed and re-opened for this change to take effect. Similarly, any expanded files in the C/C++ Projects view would need to be collapsed and expanded.
Marking as VERIFIED. (In reply to comment #8) > I suggest issue a refresh on all C/C++ project when this particular preference > change, or Popup a dialog (OK /Cancel dialog) asking user, whether to restart > the workbech for changes to take effect. > Workbench can be restart by calling org.eclipse.ui.IWorkbench.restart() Please file a separate Bugzilla for the refresh issue. There are lots of places where changing parser, indexer, and language settings does not refresh the CModel, syntax highlighting, etc. due to the AST caching mechanism. An organized approach will have to be taken to addressing that and I personally do not want to try to address that in a point release.
