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

[Elias Volanakis <volanaki@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

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?

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?

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.

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")

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


Your comments will be appreciated.

Thanks for your time,
Elias Volanakis.

PS: All code snippets compile with g++ v3.2