[cfe-dev] Declaration name qualifiers.

Enea Zaffanella zaffanella at cs.unipr.it
Wed Mar 10 12:04:01 PST 2010


Hello.

In the C++ AST, name qualifications are stored using NestedNameSpecifier 
objects. These are currently used in some expression nodes (e.g., 
DeclRefExpr and MemberExpr), some declaration nodes (e.g., 
UsingDirectiveDecl and NamespaceAliasDecl) and some type nodes (e.g., 
QualifiedNameType and TypenameType).

However, there are other AST nodes that can be qualified in the program 
sources but are not currently provided by a NestedNameSpecifier.
We would like to modify these AST nodes so that they can provide the 
required info to applications working at the program source level. 
Namely, we would like to make sure that, whenever a name qualification 
can appear in the source code, then it is possible to obtain from the 
corresponding AST node a NestedNameSpecifier* (for the qualifier) and a 
SourceRange (for the start/end locations of the qualifier in the sources).

Would this be reasonable from the point of view of clang's designers?

If so, the next step is to identify all AST nodes that need such an 
addition. In our opinion this is needed at least for
   - VarDecl
   - FunctionDecl (and its derived classes)
   - CXXRecordDecl
   - EnumDecl

Is this list complete?
It seems that TemplateDecl and Friend(Template)Decl do not need to store 
such a qualifier, since it can be stored in the actual declaration they 
refer too (coorect?).
What about the ObjC nodes?

As soon as we have a complete list of nodes to be "upgraded", we should 
be able to identify a minimum set of nodes in the AST hierarchies where 
  these two data (NNS and range) will be added.

For instance, one option would be to add these data to

   - DeclarationDecl (covering both VarDecl and FunctionDecl, but also 
FieldDecl, where such a name qualifier seems to be not really needed);

   - TagDecl (covering both EnumDecl and CXXRecordDecl, but again also 
RecordDecl where it is not needed).

Would that be OK?


Regards,
Enea Zaffanella.




More information about the cfe-dev mailing list