Re: [cdt-core-dev] STRUCTURAL_PARSE in the outline confusions

["Alain Magloire" <alain@xxxxxxx>]

> 
> Do you have a sense on how this will impact all of the clients of the 
> CModel?

Good question, it will depend if the clients know that
	ITranslationUnit != IWorkingCopy

example:

ITranslationUnit unit = CoreModel.create("project/src/foobar.cc");
IWorkingCopy copy =  unit.findSharedWorkingCopy(...);
..
ICElement[] origChildren = unit.getChildren();
ICElement[] copyChildren = copy.getChildren();


Since one will use the STRUCTURAL_PARSE the other QUICK_PARSE

  ITranslationUnit.getChildren() != IWorkingCopy.getChildren()

and in this case it is not only delta differences but a complete different semantic, for
example Macros may not be expanded.

I can not predict how the clients will use the infos.  But there will be a dichotomy
that may corrupt clients.

> Does this have a chance to spread our performance woes to clients 
> who used to avoid such woes?
> 

The reconciler is an __important__ feature because it allows client to have "live" data(i.e not save to disk).
So when you going through ITranslationUnit(s) you can ask for the dirty buffers(the one in the CEditors) and readjust
your action.  Example, the browsing or the tyep hieararchy (Although we've taking this out because of the
duality STRUCTURAL_PARSE vs QUICK_PARSE) used to show the data "live"(showing classes even if the file is not yet save).

I do not see any magic solutions, we can live things unchange and just document that some actions
may change behaviour:
- some actions(open type, browsing, etc ...) may not have the correct information because the parsing
  is done with QUICK_PARSE, if you need more info switch to STRUCTURAL_PARSE with the performance penality.

And hopefully via iteration work on the parser/indexer it will be a non-issue after release CDT-5.0, 8-)