[cfe-dev] Repeated NNS in Elaborated types?

[Douglas Gregor]

On Mar 2, 2011, at 8:44 AM, Enea Zaffanella wrote:

> Doug is doing a great job in creating and propagating nested name
> specifier location info in the AST. Here is one of the few places where
> we are still obtaining something not completely accurate:
> 
> ==================
> namespace ns {
>  template <typename T> struct S { typedef int FOO; };
> }
> 
> ns::S<int> x1;            // ns:: repeated
> struct ns::S<double> x2;  // ns:: repeated
> ns::S<double>::FOO x3;    // OK.
> ==================
> 
> The types for the first two VarDecl nodes (for x1 and x2) have the structure
> 
>  ETLoc -> TSTLoc -> QTN
> 
> that is
> 
>  ElaboratedTypeLoc
>    -> TemplateSpecializationTypeLoc
>         -> QualifiedTemplateName
> 
> We have an NNSLoc (for "ns::") inside the ETLoc nodes;
> we also have an NNS (again for "ns::") inside the QTN nodes.
> As a result, the AST dump contains a repetition of the qualification
> ns:: for both x1 and x2.
> 
> The simple patch attached tries to avoid these repetitions by NOT adding
> the NNSLoc info to the ETLoc nodes if they contain a QTN node. This is
> assuming that either TSTLoc or QTN nodes will evolve to include
> syntactic NNSLoc info (currently, TSTLoc has no qualifier info and QTN
> has a semantic NNS). The patch "as is" passes all clang lit tests except for
>    Clang :: Index/annotate-nested-name-specifier.cpp
>    Clang :: Index/recursive-cxx-member-calls.cpp
> 
> Does this sound as a reasonable approach?


Good find. I hadn't realized that this duplication actually occurred in our ASTs.

However, I suggest that we take the opposite approach: when we see that we're building a TemplateSpecializationType with a QualifiedTemplateName, map that QTN down to the underlying template name. The reasoning is that we'd like to move away from using TemplateName as the representation for the template in TemplateSpecializationType, and instead use a TemplateDecl * [1]. However, stripping off the QualifiedTemplateName would be a step in the right direction.

	- Doug

[1] Even better: introduce a TypeTemplateDecl into the Decl hierarchy, which is the common superclass of ClassTemplateDecl, TemplateTemplateParmDecl, and the not-yet-implemented AliasTemplateDecl. This isn't trivial, since RedeclarableTemplate currently gets in the way.