Re: [cdt-dev] Re: CDT Parsing Callback

["Alain Magloire" <alain@xxxxxxx>]

> 
> Cool Alain, I just wanted to know my features up front. :-)
> 
> I am unsure as to why you believe that we do not need to parse function 
> bodies in order to provide the search feature.  Searching for references 
> is the meat of the overall feature, in my opinion. 
> 

oops! you are right, I was probably thinking of indexing, the "F3" hot key.
For searching for references you definitely need the complete AST/CDOM.

But we still can do stuff like
- Search for implementors: Pure virtual or abstract classes
- Search declarations: for globals and functions ..

No need for function bodies elements.

> Anyway, currently our parser is not structured in a way that makes the 
> type of callback you are talking about simple.  We do not maintain an AST, 
> so there are no "function" objects that we can pass into a requestor. 
> However, that is a direction we are thinking about going, since between 
> the DOM (outside the parser) and the symbol table (inside the parser), we 
> could have the equivalent of a full AST given a bit of refactoring.

hmm .. I think I see where your heading.  I was thinking of a more simple
mechanism; no "function objects" is provided:

public class SourceElementRequestor implements ISourceElementRequestor {  
	void createInclude(String name, int startOffset, int endOffset) {
		System.out.line("include " + name);
	}
	void createFunction(String name, int startOffset, int endOffset) {
		System.out.line("function " + name);
	}
...
}

Many requestor like the indexer or the StructureCreator do not need the dom objects
nor the ICElement object.  For example Eclipse provides the source code in zip file,
say org.eclipse.jdt.core: jdtcoresrc.zip, the Java parser is call with a buffer and
an ISourceElementRequestor to get the information and indexing the java file in the zip.
The JavaFile does not necessarly exist as IJavaElement yet or part of the WorkingCopy,
but still available when you hit "F3".

> Also, 
> the further into the C++ grammar I get, the more ambiguities I discover, 
> and I think it is becoming clear that the cost of backtracking out of 
> ambiguous decisions is much more difficult to do from multiple clients. We 
> are currently analyzing the pros and cons of moving to an AST solution.
> 

ho! I understand your pain 8-), it is not trivial.

>  I am interested in providing a dead-accurate search much like the JDT; 
> however, C++ is seriously more complex regarding how references and names 
> are resolved at compile time ( function overloading, implicit casts, user 
> defined conversion operators, template specializations and implicit 
> instantiations) and there is a lot of work to be done here on the parser 
> side.  If you have any ideas on what you would like a new callback 
> interface to look like, feel free to send it to me

No worries, we will work this out through iterations (trial and errors).
This can probably be done whithout changes to the parser, by just providing
a bridge.  Let me see if I can submit something later ... much later 8-).

>  or maybe we could meet 
> later this week to try and make sure that your indexer work is not held up 
> by these parser work-items. 
> 

I'll be busy the next weeks, but I'll drop by someday to show you my new Eclipse Hat 8-)
gift from Thomas(ESC).