[cfe-dev] Start of source range for Decl nodes.

[Douglas Gregor]

On Mar 1, 2011, at 10:44 AM, Enea Zaffanella wrote:

> Hello.
> 
> In our application we are facing a problem related to the quality of
> source location information for Decl nodes. When using method
>    Decl::getSourceRange()
> we noticed a few cases where we obtain not so accurate location info for
> the start of the range.
> Here are a few examples.
> 
> For DeclaratorDecl nodes:
>  const int a;
>  static int b;
>  inline int foo() { return 5; }
> the range starts from "int", rather than "const" or "static" or "inline".
> 
> For a NamespaceDecl node such as
>  namespace N { }
> the range starts from the identifier N, rather than from the "namespace"
> keyword. Similarly for a linkage specification such as
>  extern "C" { ... }
> 
> All of these minor problems can be easily fixed as soon as there will be
> a place where the start for the range can be recorded. For instance,
> when creating a new VarDecl node in SemaDecl.cpp:2956
> 
>    NewVD = VarDecl::Create(Context, DC, D.getIdentifierLoc(),
>                            II, R, TInfo, SC, SCAsWritten);
> 
> the Declarator object D could provide accurate source range info, but
> the VarDecl constructor has no parameter accepting the start of such a
> range: it has a SourceLocation for the identifier loc and a
> TypeSourceInfo, which does not take into account syntactic elements such
> as storage classes, CVR qualifiers, inline specifiers, etc.
> As a result, we obtain strange-looking differences whereby declaration
>    int const a;
> has an accurate source range, whereas
>    const int a;
> is skipping the const keyword.
> 
> Assuming that the goal of obtaining precise source location info should
> be achieved by all means, now the question is: which is best place where
> this additional source location (the start of the range) for the Decl
> hierarchy should be stored?
> Would it be OK to store them at the top of the hierarchy?
> Are there better places?

I'd rather that we only add this information to those AST nodes that need it.

Also, the source range for a DeclaratorDecl (and anything else that stares with declaration specifiers) gets messy when there are multiple declarations, e.g.,

  static struct Point { int x, y; } p1, *p2, get_point(int x, int y);

Who claims the "static" keyword? Point? p1? Everyone?

If this occurred inside a DeclStmt, we'd have a DeclGroup to help us sort through this. At namespace scope, we don't have the equivalent notion. 

  - Doug