Repeated NNS in Elaborated types?

Clang Frontend
1

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:

ETLoc.patch (2.68 KB)

2

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.

3

[...]

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.

We had a try on this, but we start suspecting that we have not enough
confidence with this portion of clang code, which also seems to be
changing very quickly. It is unclear to us, for instance, whether a QTN
can be mapped to a simple template name without breaking the existing
invariants. So, if you have a clearer picture of what needs to be done,
then your help will be greatly appreciated. On our side, we will keep
checking the accuracy of source location info and provide all feedback
we can.

Regards,
Enea.

4

[...]

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.

We had a try on this, but we start suspecting that we have not enough
confidence with this portion of clang code, which also seems to be
changing very quickly. It is unclear to us, for instance, whether a QTN
can be mapped to a simple template name without breaking the existing
invariants. So, if you have a clearer picture of what needs to be done,
then your help will be greatly appreciated. On our side, we will keep
checking the accuracy of source location info and provide all feedback
we can.

Perhaps something more than a try :wink: The truth is that the repeated NNS
breaks several tests from the testsuite of our application and it is an
unfortunate obstacle to adopt the otherwise great new NNSLoc machinery.

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.

Indeed this seems the right path.

5

r126946 is the easy way to do this, at least until we can do the more significant refactoring to introduce TypeTemplateDecl.

  - Doug

6

Everything looks simpler when done :wink:

Actually, we thought that the boolean flag for the presence of the
optional "template" keyword was to be saved somewhere ... but that can
really wait for the refactoring.

Enea.