Hi,
On 30/09/19 20:46, Jason Merrill wrote:
On Mon, Sep 30, 2019 at 6:54 AM Paolo Carlini <paolo.carl...@oracle.com> wrote:
On 28/09/19 04:05, Jason Merrill wrote:
On 9/26/19 3:39 PM, Paolo Carlini wrote:
+template void foo<int>( // { dg-error "15:template-id .foo<int>.
used as a declarator" }
That's a strange diagnostic message; there's nothing wrong with using
a template-id as a declarator. Why are we even calling grokdeclarator
when we hit EOF in the middle of the declarator?
It's indeed a weird situation. Note, by the way, that for
template void foo<int>;
we end up giving the same diagnostic, only, the location was already fine.
Anyway, to explain why I say weird, clang believes it's dealing with an
explicit instantiation:
explicit instantiation of 'foo' does not refer to a function template,
variable template, member function, member class, or static data member
whereas EDG gives:
declaration is incompatible with function template "void foo<<unnamed>>()"
I *think* what we are issuing is closer in spirit to the latter, we
don't get fooled into thinking it's an instantiation and we say that as
a declaration doesn't work either. See what I mean?
Well, it is an explicit instantiation, the problem (as EDG says) is
that the instantiation declaration doesn't match the template.
Definitely it doesn't.
Removing completely
the diagnostic code doesn't seem fine either because we end up with very
confusing wordings like
variable or field declared void
or worse we mention variable templates, depending on the type (I already
mentioned this).
Any thought about my question about why we're calling grokdeclarator
in the first place?
Yes. If you look at cp_parser_explicit_instantiation, clearly
cp_parser_declarator doesn't return a cp_error_declarator and in such
cases we always call grokdeclarator. Do you think we should error out
here instead, much earlier? Currently grokdeclarator does quite a bit of
work before the diagnostic.
Paolo..
