Broken name range for function template specialization (and a related question)

[Richard Smith]

On Fri, Jul 18, 2014 at 12:17 AM, Abramo Bagnara <abramo.bagnara at bugseng.com
> wrote:

> Ping.
>
> Il 15/07/2014 12:58, Abramo Bagnara ha scritto:
> >
> > Tracking down a failure in one of our applications I've obtained the
> > following testcase:
> >
> > template<typename T>
> > int operator+(T&);
> >
> > template<>
> > int operator+(class c&);
> >
> > As far as I can see clang first produce an instantiation for function
> > template, then produces the explicit specialization as a redecl of the
> > former one.
> >
> > The first decl is not attached to visitable AST, but only available as
> > redeclaration of explicit specialization (as its canonical decl).
> >
> > In SemaTemplate.cpp near line 6706 we have:
> >
> >   // Note: do not overwrite location info if previous template
> >   // specialization kind was explicit.
> >   TemplateSpecializationKind TSK =
> > SpecInfo->getTemplateSpecializationKind();
> >   if (TSK == TSK_Undeclared || TSK == TSK_ImplicitInstantiation) {
> >     Specialization->setLocation(FD->getLocation());
> >     // C++11 [dcl.constexpr]p1: An explicit specialization of a constexpr
> >     // function can differ from the template declaration with respect to
> >     // the constexpr specifier.
> >     Specialization->setConstexpr(FD->isConstexpr());
> >   }
> >
> > The problem is that setLocation copy only a part of name info locations,
> > so the canonical decl ends up having a name range that starts from token
> > `operator' of specialization and ends at token `+' of template (i.e. a
> > negative/broken range).
> >
> > Likely this is easily fixable copying both edges of range (I'm guessing,
> > please confirm that) but I'd like also to understand why we need to have
> > *two* declarations (with one of them not reachable with ordinary visits).
>

We really shouldn't, but it's convenient for checking an explicit
instantiation (most of the checks we perform are just 'check that this
function is a valid redeclaration of the relevant implicit
specialization'). The template argument deduction mechanism is currently a
little too keen to build a specialization of the template from the deduced
arguments.

This seems fixable if you're prepared to put the effort into doing so, but
otherwise just copying across more locations would plug the immediate issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140722/24c2da3e/attachment.html>