<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 21, 2013 at 11:24 PM, Serge Pavlov <span dir="ltr"><<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>As Richard pointed out, I used wrong wording, so let me give long explanation, just to be understood correctly.</div>
<div><br></div><div>The most common kind of error is typos. The next is something omitted, these errors are typical for experienced programmers ("brain is faster than fingers"). Misplaced and extra things are much rarer, the latter are more often for novices. So if we have wrong piece of code, we should try to recover assuming that something is missed. The original case:</div>
<div class="im">
<div><br></div><div>template struct pr15466a { int a; };</div><div><br></div></div><div>can be recovered by:</div><div>- Adding parameter list to 'template', making it a template definition, or</div><div>- Removal of 'template' turning it into non-template class definition.</div>
<div>According the above rules, missed things are more probable, than spurious 'template'. People are lazy, if a user typed 'template', there must a template somewhere. So this code should be recovered as template definition.</div>
<div><br></div><div>Now let's consider the next example:</div><div class="im"><div><br></div><div>template <class T> struct pr15466a;</div><div>template struct pr15466a { int a; };</div><div><br></div></div><div>
In this case we know that 'pr15466a' is a template, so almost definitely the second line must be recovered as a specialization by putting '<>' after 'template' and</div></div></blockquote><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div> template parameters after 'pr15466'. </div></div></blockquote><div style>Not to be too picky, but I think you meant "template arguments" here? :) </div>
<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Chances that a user made two different errors (typed extra 'template' and made a typo in 'pr15466') are pretty low.</div>
<div><br></div><div><div>Bottom line: in both cases I would complain about missed template arguments.</div></div></div></blockquote><div><br></div><div style>I believe there have been long and substantial discussions before this bug fix about the proper way to recover from errors. This fix does not address what is the proper way, but rather applies what seems to be the currently agreed-upon rules. Therefore, I'd say that the issue you raise here is orthogonal to this bug fix.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Another problem with your fix is too long messages. Short messages (no more that 5-6 significant words) are perceived as a whole, longer require reading which is substantially (several times) slower and annoy users. The message </div>
<div class="im">
<div><span style="white-space:pre-wrap"> </span>class cannot be defined in an explicit instantiation; if this declaration is meant to be a class definition, remove the 'template' keyword</div></div><div>I would make something like:</div>
<div><span style="white-space:pre-wrap"> </span>class cannot be defined in an explicit instantiation; spurious 'template'?</div></div></blockquote><div><br></div><div style>You may be right, but this bug fix did not make this message. So, I'd suggest filing a separate bug report addressing the length of error messages. </div>
<div style><br></div><div style>I hope this helps.</div><div style>Thanks,</div><div style>-- Larisse.</div><div style><br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div>Thanks,</div><div>--Serge</div></div><div class="gmail_extra"><div><div class="h5">
<br><br><div class="gmail_quote">2013/6/22 Larisse Voufo <span dir="ltr"><<a href="mailto:lvoufo@google.com" target="_blank">lvoufo@google.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Fri, Jun 21, 2013 at 1:46 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Fri, Jun 21, 2013 at 12:31 PM, Serge Pavlov <<a href="mailto:sepavloff@gmail.com" target="_blank">sepavloff@gmail.com</a>> wrote:<br>
> With this fix diagnostics in some cases look unclear. For instance, in these<br>
> declarations:<br>
><br>
> template <class T> struct pr15466a;<br>
> template struct pr15466a { int a; };<br>
><br>
> the second is obviously an instantiation with template arguments missing.<br>
<br>
</div>I think you mean, it's obviously meant to be a definition of the<br>
primary template.<br>
<div><br>
> Compiler messages however may be confusing:<br>
><br>
> t2.cpp:2:26: error: class cannot be defined in an explicit instantiation;<br>
> if this declaration is meant to be a class definition,<br>
> remove the 'template' keyword<br>
> template struct pr15466a { int a; };<br>
> ~~~~~~~~~ ^<br>
> t2.cpp:2:17: error: redefinition of 'pr15466a' as different kind of symbol<br>
> template struct pr15466a { int a; };<br>
> ^<br>
> t2.cpp:1:27: note: previous definition is here<br>
> template <class T> struct pr15466a;<br>
> ^<br>
><br>
> As pr15466a in this example is already known as a template, maybe a message<br>
> like "missing argumet list" is more appropriate?<br>
<br>
</div>That makes sense to me, but I think it's somewhat orthogonal to this<br>
bug fix. We should also produce a "missing template parameter list"<br>
diagnostic for a case like:<br>
<br>
template <class T> struct pr15466b;<br>
struct pr15466b { int a; };<br></blockquote><div><br></div></div></div><div>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.</div>
<div>We decided to select one of these two alternatives based on whether template arguments are explicitly provided. </div><div><br></div><div>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 (?).</div>
<div><br></div><div>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).</div>
<div><br></div><div>The only adjustment that this bug fix could do for the case you presented is to not produce the "<span style="color:rgb(80,0,80)">cannot be defined in an explicit instantiation" diagnosis when the existing template does not have a definition. </span></div>
<div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)">In other words, would you prefer the following diagnosis to the current one (above)?</span></div><div><div><span style="color:rgb(80,0,80)"><br>
</span></div><div><span style="color:rgb(80,0,80)">> t2.cpp:2:17: error: redefinition of 'pr15466a' as different kind of symbol</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">> template struct pr15466a { int a; };</span><br style="color:rgb(80,0,80)">
<span style="color:rgb(80,0,80)">> ^</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">> t2.cpp:1:27: note: previous definition is here</span><br style="color:rgb(80,0,80)"><span style="color:rgb(80,0,80)">> template <class T> struct pr15466a;</span><br style="color:rgb(80,0,80)">
<span style="color:rgb(80,0,80)">> ^</span><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)"><br></span></div></div><div><span style="color:rgb(80,0,80)">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...</span></div>
<div><span style="color:rgb(80,0,80)"><br></span></div><div><span style="color:rgb(80,0,80)">Thanks, </span></div><span><font color="#888888"><div><span style="color:rgb(80,0,80)">-- Larisse. </span></div>
</font></span><div><div><div><br></div><div><br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div><br>
> 2013/6/22 Larisse Voufo <<a href="mailto:lvoufo@google.com" target="_blank">lvoufo@google.com</a>><br>
>><br>
>> Problem solved. r184577.<br>
>> I hope I got everything right.<br>
>> Thanks,<br>
>> -- Larisse.<br>
>><br>
>><br>
>> On Wed, Jun 19, 2013 at 2:17 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br>
>>><br>
>>> On Jun 19, 2013, at 2:12 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:<br>
>>> > On Wed, Jun 19, 2013 at 11:42 AM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>><br>
>>> > wrote:<br>
>>> >> On Jun 19, 2013, at 10:59 AM, Larisse Voufo <<a href="mailto:lvoufo@google.com" target="_blank">lvoufo@google.com</a>> wrote:<br>
>>> >><br>
>>> >> On Wed, Jun 19, 2013 at 10:43 AM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>><br>
>>> >> wrote:<br>
>>> >>><br>
>>> >>> On Jun 19, 2013, at 9:15 AM, Larisse Voufo <<a href="mailto:lvoufo@google.com" target="_blank">lvoufo@google.com</a>> wrote:<br>
>>> >>>> Just out of curiosity, I have noticed that Clang currently allows<br>
>>> >>>> the<br>
>>> >>>> following program:<br>
>>> >>>><br>
>>> >>>> template<typename T> T f() { return 13; }<br>
>>> >>>> template int f() { return 1; }<br>
>>> >>>><br>
>>> >>>> It essentially parses the body of the explicit instantiation only to<br>
>>> >>>> ignore it.<br>
>>> >>>> Was this a conscious decision?<br>
>>> >><br>
>>> >><br>
>>> >> I just spoke to Richard Smith about this, and it appears that the<br>
>>> >> current<br>
>>> >> behavior is a bit different from the way I just described it above.<br>
>>> >> The declaration for the template instantiation is parsed, but the<br>
>>> >> 'template'<br>
>>> >> keyword is ignored, which leads to two different behaviors for the<br>
>>> >> calls f()<br>
>>> >> and f<int>().<br>
>>> >> While f() returns 1, f<int>() returns 13. f() picks up the declaration<br>
>>> >> "int<br>
>>> >> f() { return 1; }" while f<int>() picks up the template declaration<br>
>>> >> and<br>
>>> >> implicitly instantiates it.<br>
>>> >><br>
>>> >>><br>
>>> >>><br>
>>> >>> No; please file a bug. You cannot define a function in an explicit<br>
>>> >>> instantiation.<br>
>>> >><br>
>>> >><br>
>>> >> I can quickly fix this or submit a patch. Should I still file a bug?<br>
>>> >><br>
>>> >><br>
>>> >> Fixing it is better. :)<br>
>>> >><br>
>>> >>>> GCC 4.6.3 rejects the program with "expected ‘;’ before ‘{’ token".<br>
>>> >>><br>
>>> >>> Well, hopefully we can do better than that.<br>
>>> >><br>
>>> >><br>
>>> >> What do you have in mind?<br>
>>> >><br>
>>> >><br>
>>> >> "error: cannot implement a function in an explicit instantiation"<br>
>>> >><br>
>>> >> or something along those lines.<br>
>>> ><br>
>>> > My suggestion was:<br>
>>> > * If the declarator-id is not a template-id, issue a "function cannot<br>
>>> > be defined in an explicit instantiation" diagnostic and recover by<br>
>>> > ignoring the 'template' keyword<br>
>>> > * If the declarator-id is a template-id, issue an "explicit<br>
>>> > specialization requires 'template<>'" diagnostic with a fixit to add<br>
>>> > the <>, and recover as if it were an explicit specialization<br>
>>><br>
>>> Ah, yes, I wasn't thinking about the different recovery paths.<br>
>>> Good point.<br>
>>><br>
>>> John.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Thanks,<br>
> --Serge<br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br>Thanks,<br>--Serge<br>
</font></span></div>
</blockquote></div><br></div></div>