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

["Alain Magloire" <alain@xxxxxxx>]

> 
> Concern 1: 
> Without exposing the full cross-reference information out through the 
> CModel API, a frequent pattern may arise like: 
> Editor is saved, resource change event causes CModel to be rebuilt 
> w/STRUCTURAL_PARSE
> Notification sent out via element delta
> Client has to reparse the file again to get the same information that the 
> CModel threw away. 
> 

Correct, this is the way things are done.

To be clear the Core Model(CModel, ICElement API) provides a bridge or a rendez-vous
point to many modules:

- Binary Parser
- Source Parser(AST)
- PathEntry(cpath entries)
- indexer
- events deltas
- working copies
etc ....

The information is not complete, since the CModel does not drill in block(functions, methods)
The clients will have to go back to the indexer or the original module(ex: the Binary Parser)
for more info.

It was not in the plan to provide more but rather clean up this interface(too many loose ends
and inconsistencies).

And example of usage, Open Type:  the first wide search is done through the indexer, gather
all the classes etc ...(Since indexer is the maintainer of such things).  Once the large info set is gather,
the CModel is use(ICElement) to show content providers, CEditor actions, element
offsets, etc ....  The open type finds in the CModel all of the utilities.

> Concern 2: 
> If you switch between QUICK_PARSE (reconcile) and STRUCTURAL_PARSE (save), 
> the tree may change quite drastically once you do a save.  QUICK_PARSE is 
> an approximation, STRUCTURAL_PARSE is precise. 
> 

Agreed, see previous email.  I have no solution than to warn the users
on that behaviour.

> Concern 3: 
> STRUCTURAL_PARSE requires include paths in order to work properly.  Since 
> we have not done integrations to all toolchains as of yet, we would be 
> disabling the outline view out of the box for non-GNU clients. 
> STRUCTURAL_PARSE/COMPLETE_PARSE without include paths is even less 
> accurate than QUICK_PARSE. 
> 

You will __always__ have trouble for this level of integration, unless you
distribute the entire headers, libraries, compiler .. and OS.  Since you have control
you can set things properly.  For free style projects like "standard make"
it will be up to the user to set things correctly, control is in there hands.
We help by providing tools like the "auto discovery", we are working on
"GCC container path entries" etc ...

IMHO, to penalize everybody because of this, is taking a few step back.
CDT is a free IDE, it is not possible to provide n configurations for all the
m variations of OS, libraries, headers ...


> Concern 4: 
> Without having incremental parsing, there is no way we will be fast enough 
> to make STRUCTURAL_PARSE not noticable.  Try it out on a project with 
> files referencing numerous inclusions and see for yourselves.  The 
> difference in performance between QUICK_PARSE and STRUCTURAL_PARSE can be 
> several orders of magnitude, depending on how deep the inclusions go 
> (particularly with templates). 
> 
> Concern 5: 
> Irregardless of whether someone uses the hierarchy or browsing views, we 
> are impeding our scalability out of the box.  Ideally, the indexer should 
> be the only component doing a COMPLETE or STRUCTURAL parse on resource 
> change event.  The more clients parsing the same files at the same time 
> using the symbol table means more garbage collections or even 
> OutOfMemoryErrors. 
> 

Yes, I understand, the parser at the moment is not capable to deliver good
performance(parsing C++ is not ...hmm.. easy, and I'm glossing over the preprocessor
problems 8-).  And we ____REALLY___ appreciate all the work being done on this
and we will participate in all possible ways to improve this ... but too many
on the driver seat is not a guaranty of quality, so you guys are driving and
we will comply to your demands .. 8-).

If we can not use STRUCTURAL for now then be it.  We will just scale down
are use(i.e. disable some features or delay some enhancements) of the parser until
it gets better.  Some actions like say open type, etc .. will just be scale down
or delay 'till it is possible to implement cool stuff ... I'm not loosing sleep over this 8-).

> It is my belief that we need to make the best with what we have in the 
> short term (2.1), for the sake of scalability and the performance of our 
> primary workflows.  In my opinion, this is more important than rounding 
> out our feature set.

Agreed, but it is a trade off, you want also to deliver a certain
number of feature that makes an IDE and IDE, if not things can scale
very well using vi(emacs)/make.  If we want to attract folks to the CDT
we have also to put some meat on the bones.

But that said I do understand your point and we will work things out just fine.

> Alain, what APIs in particular in the AST do the 
> features listed in your email require to be exposed through the CModel?
> 

The CModel uses the source parser to build the children of the ITranslationUnit
for its clients.  It has one restriction, it does not drill into the blocks.
Whatever accuracy the parser provides it will be reflected on the CModel.

Let's look at a recent scenario, the "add include" action,
if you select "cout" and trigger the Add_Include_Action:
- the indexer is first you use to locate the declaration
  * the indexer says that "cout" is
       * in "/usr/include/c++/iostream"
       * and needs namespace "std".

The action(addInclude) contacts the CModel:
- check if the includes paths are correct via the pathentry(not implemented)
- check if "#include <iostream>" is a children of (ITranslationUnit), if not adds it.
- check if "using namespace std;" is already a children of (ITranslationUnit), if not adds it.

This action may not work correctly for QUICK parse since for this type you may not
return the using directives of the translation unit.