Re: Rejected: [cdt-patch] Indexing show stopper parser patch

["Thomas Fletcher" <thomasf@xxxxxxx>]

Bogdan Gheorghe <gheorghe@xxxxxxxxxx> said:
> 
> > cdt-patch-admin@xxxxxxxxxxx wrote on 02/05/2004 05:11:31 AM:
> > 
> > > 
> > > I've filed a PR for this 51232, but in a nutshell every now and then
> > > the Parser's translationUnit call will throw an unexpected exception
> > > (these cases to be investigated as a secondary activity) which then
> > > causes all components which are expecting a binary return of parsed/
> > > notparsed from the Parser.java->parse() to fail.  The indexer is 
> > > one of these components unfortunately and when this occurs the
> entire
> > > index is considered empty. 
> 
> This is not quite true. You can have a failed parse and still have lots
> of elements in your index. If you turn on the indexer tracing
> (debug/indexer) you can see the actual elements that get put into the
> index as well as the overall parse result. 

True ... but this is not a "failed" parse, this is a parse which has 
thrown an exception uncaught all the way back to the guy who kicked
the index work off.

I did localize the statement to the particular project I have, which
is fairly early in the indexing process and when the "Open Type" dialog
is used (or any search for types), it comes back with a statement that 
there are no types.  From a users perspective, you are telling them that
the 15,000 source files they have have absolutely no class, enum, structs
or typedefs defined, essentially their index is empty =;-).  On the other
hand if I catch this exception and return "false" (which from John's reply
is not the thing to do) then the indexer seems quite content to not index
this file and move on to the next one.

I'll dig some more and see if I can come up with a less tumultuous patch
to the CDT that is localized only to the indexer components.

Thanks for the quick feedback,
 Thomas