| RE: [cdt-core-dev] Open C++ Parser |
Our current prototype allows you to give inclusion paths and macro definitions to the scanner to emulate -I and -D options. So, yes, we need to figure out how to get this information from the build to the scanner.
And, yes, the indexer needs to get involved to store a lot of this info. I want to take a look at how the JDT indexer works, especially since they are talking about moving it into a common layer so that we could reuse it.
And to your final point, yes again (8-)), we have put in place a flag that will cause the parser to skip over function bodies. This would probably make the parser fast enough for use in the reconciler.
Doug Schaefer
Senior Staff Software Engineer
Rational - the software development company
Ottawa (Kanata), Ontario, Canada
-----Original Message-----
From: Alain Magloire [mailto:alain@xxxxxxx]
Sent: December 12, 2002 2:25 PM
To: cdt-core-dev@xxxxxxxxxxx
Subject: Re: [cdt-core-dev] Open C++ Parser
>
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
>
> ------_=_NextPart_001_01C2A211.E09B67E0
> Content-Type: text/plain
>
> Thanks Alain, we definitely want to line up on strategy and work together to
> make the right choices.
>
We are very open on this, the more merrier 8-).
> Right now the focus is on performance since we're hoping to replace ctags
> and gather cross-reference information for the index. We will likely need
> to have races to see which parser is faster. I still don't have a sense of
> this yet.
>
When working on this, some of the issues(very briefly):
- Macro definition our tied to th builder.
#define _OLD_COMPAT_
#include <stdio.h>
parsing stdio.h depending on the defines will not show the same symbols.
- external includes
- defining a stategy for the storing mechanism, the indexer
could play a major role in holding the information.
- limiting the scope/depth of the parsing. Not every one needs
the AST(to drill down to the blocks).
etc ...
> The second issue will be extensibility. We're running into that quickly as
> the two compilers we're using here for testing (g++ and VC++) both extend
> C++ in wacky ways. The parser strategy will need to handle this. I'm not
> sure if JavaCC handles subclassing (I know ANTLR does) so this may be easier
> to do with a handwritten parser.
>
> I'll let everyone know when we've reached a reasonable level of quality and
> we can start comparing the options in more detail.
>
Thanks.
_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev