[cfe-dev] Explicit instantiation with body?

Richard Smith richard at metafoo.co.uk
Fri Jun 21 13:46:35 PDT 2013


On Fri, Jun 21, 2013 at 12:31 PM, Serge Pavlov <sepavloff at gmail.com> wrote:
> With this fix diagnostics in some cases look unclear. For instance, in these
> declarations:
>
> template <class T> struct pr15466a;
> template struct pr15466a { int a; };
>
> the second is obviously an instantiation with template arguments missing.

I think you mean, it's obviously meant to be a definition of the
primary template.

> Compiler messages however may be confusing:
>
>  t2.cpp:2:26: error: class cannot be defined in an explicit instantiation;
> if this declaration is meant to be a class definition,
>       remove the 'template' keyword
> template struct pr15466a { int a; };
> ~~~~~~~~~                ^
> t2.cpp:2:17: error: redefinition of 'pr15466a' as different kind of symbol
> template struct pr15466a { int a; };
>                 ^
> t2.cpp:1:27: note: previous definition is here
> template <class T> struct pr15466a;
>                           ^
>
> As pr15466a in this example is already known as a template, maybe a message
> like "missing argumet list" is more appropriate?

That makes sense to me, but I think it's somewhat orthogonal to this
bug fix. We should also produce a "missing template parameter list"
diagnostic for a case like:

  template <class T> struct pr15466b;
  struct pr15466b { int a; };

> 2013/6/22 Larisse Voufo <lvoufo at google.com>
>>
>> Problem solved. r184577.
>> I hope I got everything right.
>> Thanks,
>> -- Larisse.
>>
>>
>> On Wed, Jun 19, 2013 at 2:17 PM, John McCall <rjmccall at apple.com> wrote:
>>>
>>> On Jun 19, 2013, at 2:12 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>> > On Wed, Jun 19, 2013 at 11:42 AM, John McCall <rjmccall at apple.com>
>>> > wrote:
>>> >> On Jun 19, 2013, at 10:59 AM, Larisse Voufo <lvoufo at google.com> wrote:
>>> >>
>>> >> On Wed, Jun 19, 2013 at 10:43 AM, John McCall <rjmccall at apple.com>
>>> >> wrote:
>>> >>>
>>> >>> On Jun 19, 2013, at 9:15 AM, Larisse Voufo <lvoufo at google.com> wrote:
>>> >>>> Just out of curiosity, I have noticed that Clang currently allows
>>> >>>> the
>>> >>>> following program:
>>> >>>>
>>> >>>> template<typename T> T f() { return 13; }
>>> >>>> template int f() { return 1; }
>>> >>>>
>>> >>>> It essentially parses the body of the explicit instantiation only to
>>> >>>> ignore it.
>>> >>>> Was this a conscious decision?
>>> >>
>>> >>
>>> >> I just spoke to Richard Smith about this, and it appears that the
>>> >> current
>>> >> behavior is a bit different from the way I just described it above.
>>> >> The declaration for the template instantiation is parsed, but the
>>> >> 'template'
>>> >> keyword is ignored, which leads to two different behaviors for the
>>> >> calls f()
>>> >> and f<int>().
>>> >> While f() returns 1, f<int>() returns 13. f() picks up the declaration
>>> >> "int
>>> >> f() { return 1; }" while f<int>() picks up the template declaration
>>> >> and
>>> >> implicitly instantiates it.
>>> >>
>>> >>>
>>> >>>
>>> >>> No;  please file a bug.  You cannot define a function in an explicit
>>> >>> instantiation.
>>> >>
>>> >>
>>> >> I can quickly fix this or submit a patch. Should I still file a bug?
>>> >>
>>> >>
>>> >> Fixing it is better. :)
>>> >>
>>> >>>> GCC 4.6.3 rejects the program with "expected ‘;’ before ‘{’ token".
>>> >>>
>>> >>> Well, hopefully we can do better than that.
>>> >>
>>> >>
>>> >> What do you have in mind?
>>> >>
>>> >>
>>> >> "error: cannot implement a function in an explicit instantiation"
>>> >>
>>> >> or something along those lines.
>>> >
>>> > My suggestion was:
>>> > * If the declarator-id is not a template-id, issue a "function cannot
>>> > be defined in an explicit instantiation" diagnostic and recover by
>>> > ignoring the 'template' keyword
>>> > * If the declarator-id is a template-id, issue an "explicit
>>> > specialization requires 'template<>'" diagnostic with a fixit to add
>>> > the <>, and recover as if it were an explicit specialization
>>>
>>> Ah, yes, I wasn't thinking about the different recovery paths.
>>> Good point.
>>>
>>> John.
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
>
> --
> Thanks,
> --Serge




More information about the cfe-dev mailing list