Re: [cdt-dev] Observations on the Parser Component (ver 1.125)

[John Camelon <jcamelon@xxxxxxxxxx>]

For #1 - #3, please raise defects in bugzilla. 
My comments are inline. 

Thanks for taking a look at things, your feedback is appreciated. 
JohnC

cdt-dev-admin@xxxxxxxxxxx wrote on 11/26/2003 12:41:31 PM:

> Hi,
> 
> I'm currently evaluating c++ parsers for use in my master's thesis
> (a specialized code generation/refactoring tool). I've spend the
> last few days experimenting with CDT's parser and want to share
> my observations with you.
> 
> I've crosschecked with bugzilla before posting, but I
> apologize if these things are already known to you.
> 
> 
> Observations in COMPLETE_PARSE mode:
> 
> 1. Differentiating between a type name and a non-type name
>    in method bodies will cause the parse to fail. As seen in
>    "Annotated C++ Reference Manual", page 27:
> 
> struct s { /* ... */  };
> void f(int s) { struct s a; s++; }
> //                       ^-- fails here with ASTSemanticException
> 
> 2. Using '::typename' for type de-ambiguation is not noticed
>    (applies to QUICK_PARSE too):
> 
> struct s { int num; };
> 
> namespace namespc {
>  struct s { double num; };
>  s inner = { 3.14 };
>  ::s outer = { 42 };
> }
> 
>   Both inner and outer are reported as of type 's'. However
>   'namespc::s' and 's'  or  's' and '::s' would me more precise?
> 3. using namespace std (included through <...>) will cause
>    the COMPLETE_PARSE to fail. As in:
> 
> #include <iostream>
> using namespace std;
> int main(int argc, char** argv) {
>   cout << "Hello World" << endl;
> }
> 
>    I *assume* this one is because includes in <...> are not parsed,
>    so indeed there is no definition of std. An idea for a quick fix is
>    following: Adding a constructor(IASTScope, String, int, int)
>    to *.complete.ASTUsingDirective.
>    This would allow instantiation with just a string-name (eg. 'std',
>    as it is currently done in *.quick.ASTUsingDirective)
>    getNamespace() would still return null.
>    getNamespaceName() is modified to return the string-name when
>    the definition is null, otherwise the fully qualified name is
>    returned.
> 
> 
> Questions and Comments:
> 
> 4. As you know, COMPLETE_PARSE over code with templates
>    causes the parse to fail (works in QUICK_PARSE though).
>    How does template support in COMPLETE_PARSE compare to
>    template support in QUICK_PARSE? What does remain to be done?

For what is in the HEAD stream, the symbol table is not complete and AST 
structures have not been fully fleshed out.  Without a client driving 
these as requirements, it is not clear whether or not it shall be fixed in 
the near future.  A significant amount of work is still required in order 
to get full cross-reference information inside the AST. 
 
> 5. I'm thinking of modifying the parser, so that COMPLETE_PARSE
>    mode does *not* go into method/function bodies. Any hints
>    where I should start looking?

Parser::handleFunctionBody() ... keep in mind that this enhancement 
request has already been raised in bugzilla bug #47234. 
 
> 6. Is there a clever way to access preprocessor directives
>    (#ifdefs etc.) during scanning/parsing? Right know my best
>    bet is to modify the Scanner at the relevant places.

Modify the scanner and add additional callbacks to 
ISourceElementRequestor.  This may be something we need to do anyway post 
CDT 2.0. 
 
> 7. What are your thoughts on having something like
>    isCreatedByMacro() for types/methods/functions in the AST.
> 
>    This could be useful for the outline view, in order to suppress
>    refactoring-actions in context menus. This is useful, when the
>    classes/methods/functions shown have been generated by macro
>    expansion - refactoring them wouldn't make much sense. Example:
> 
> #define FOO(mess) int main() { std::cout << mess << std::endl; }
> #define CLASS(name) class name { private: int a; public: int getA() {
> return a; } FOO("bla") };
> #include <iostream>
> CLASS(Bar)
> CLASS(Baz)
> FOO("Hello")

I would consider it if we could get consistent results from something like 
that ...  is it necessary, however?  JDT executes the actions and reports 
errors if they are not allowed ... I do not think supression is compliant 
w/the Eclipse UI guidelines ... 

> 8. How much change is anticipated in the CDT's public API until v2.0 ?
> 

As much as is necessary to support the parser features that we are 
committing to.  2.0 is our last chance to get these interfaces "right" as 
we plan to publish API documentation for other software vendors to plug in 
easier to CDT.  While we shall try and minimize API churn, we shall change 
what is necessary to accomplish a high quality 2.0 release. 
 
> Your comments will be appreciated.
> 
> Thanks for your time,
> Elias Volanakis.
> 
> PS: All code snippets compile with g++ v3.2

The parser has never claimed to be GNU-extension compliant at this time. 
 
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev