[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-commits
Subject:    Re: [PATCH] Fix parsing comma in default arguments.
From:       Eli Friedman <eli.friedman () gmail ! com>
Date:       2013-06-13 23:30:22
Message-ID: CAJdarcFprVGhe3SXA0HCmvuezF+7v=sF235tL-2DGM2KE1W9hA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Thu, Jun 13, 2013 at 4:17 PM, Olivier Goffart <ogoffart@kde.org> wrote:

> On Thursday 13 June 2013 13:52:47 Richard Smith wrote:
> > That's not really acceptable, if it can lead to rejecting valid code
> > that we accept now (such as your next example).
>
> Ok, the new attached patch fixes that issue.
>
> I'm now quite happy which what (i think) we cover.
> It even report good errors when one miss a default argument (on the right
> line)
>
> What is still not working is this:
>
> template <int, int =0> struct p { const static int w = 0; };
> struct T {
>      int i = p<0,  p<a<b>::w  >::w, p<0>::*j;
>      static const int a = 1, b = 2;
> };
>
> because a and b are declare after, and the TryAnnotateCXXScopeToken will
> display error as a and b are not defined yet.
>
> But clang did not accept this code before.  And gcc also seems to have a
> bug
> there.
>
>
> > > Also a template argument can contains = for example in this case:
> > >  struct S {constexpr S(){}; constexpr int operator=(int) const {return
> > >  5;}};
> > >  template <int> struct A {};
> > >  constexpr S s;
> > >  A<s=4> a;
> >
> > This is ill-formed.
>
> Why?
> the operator= is a constexpr


It isn't a question of what operator= resolves to; the issue is that the
grammar doesn't allow an '=' in that spot.  See [gram.expr].

-Eli

[Attachment #5 (text/html)]

<div dir="ltr">On Thu, Jun 13, 2013 at 4:17 PM, Olivier Goffart <span \
dir="ltr">&lt;<a href="mailto:ogoffart@kde.org" \
target="_blank">ogoffart@kde.org</a>&gt;</span> wrote:<br><div \
class="gmail_extra"><div class="gmail_quote"> <blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
class="im">On Thursday 13 June 2013 13:52:47 Richard Smith wrote:<br> &gt; That&#39;s \
not really acceptable, if it can lead to rejecting valid code<br> &gt; that we accept \
now (such as your next example).<br> <br>
</div>Ok, the new attached patch fixes that issue.<br>
<br>
I&#39;m now quite happy which what (i think) we cover.<br>
It even report good errors when one miss a default argument (on the right<br>
line)<br>
<br>
What is still not working is this:<br>
<br>
template &lt;int, int =0&gt; struct p { const static int w = 0; };<br>
struct T {<br>
     int i = p&lt;0,  p&lt;a&lt;b&gt;::w  &gt;::w, p&lt;0&gt;::*j;<br>
     static const int a = 1, b = 2;<br>
};<br>
<br>
because a and b are declare after, and the TryAnnotateCXXScopeToken will<br>
display error as a and b are not defined yet.<br>
<br>
But clang did not accept this code before.  And gcc also seems to have a bug<br>
there.<br>
<div class="im"><br>
<br>
&gt; &gt; Also a template argument can contains = for example in this case:<br>
&gt; &gt;  struct S {constexpr S(){}; constexpr int operator=(int) const {return<br>
&gt; &gt;  5;}};<br>
&gt; &gt;  template &lt;int&gt; struct A {};<br>
&gt; &gt;  constexpr S s;<br>
&gt; &gt;  A&lt;s=4&gt; a;<br>
&gt;<br>
&gt; This is ill-formed.<br>
<br>
</div>Why?<br>
the operator= is a constexpr</blockquote><div><br></div><div>It isn&#39;t a question \
of what operator= resolves to; the issue is that the grammar doesn&#39;t allow an \
&#39;=&#39; in that spot.  See [gram.expr].</div><div> <br></div><div>-Eli \
</div></div></div></div>



_______________________________________________
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[prev in list] [next in list] [prev in thread] [next in thread]