[cfe-dev] Explicit instantiation with body?
Larisse Voufo
lvoufo at google.com
Fri Jun 21 15:12:09 PDT 2013
On Fri, Jun 21, 2013 at 1:46 PM, Richard Smith <richard at metafoo.co.uk>wrote:
> 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; };
>
Interesting. The general logic of the bug fix is that if a declaration
starts as if a template instantiation, but provides a body, then it is
likely meant to be either a non-template definition or a template
specialization.
We decided to select one of these two alternatives based on whether
template arguments are explicitly provided.
It sounds like you are suggesting to also consider the fact that the
existing template may not have been defined as an alternative, in which
case we should treat cases lacking explicit arguments as mis-entered
template definitions (?).
In this latter case, with our recovering from failure by removing the
template keyword (if no argument is provided), the issue becomes the same
as the case that Richard brings up (without the 'template' keyword).
The only adjustment that this bug fix could do for the case you presented
is to not produce the "cannot be defined in an explicit instantiation"
diagnosis when the existing template does not have a definition.
In other words, would you prefer the following diagnosis to the current one
(above)?
> 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;
> ^
If so, I can quickly update the bug fix appropriately. If not, then the
issue is probably whether and how the "redefinition" diagnosis should be
issued...
Thanks,
-- Larisse.
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130621/a6391876/attachment.html>
More information about the cfe-dev
mailing list