<div>On Wed Jan 29 2014 at 1:17:50 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jan 29, 2014 at 4:01 PM, Richard Smith <<a href="mailto:metafoo@gmail.com" target="_blank">metafoo@gmail.com</a>> wrote:<br>
> On Wed Jan 29 2014 at 12:54:14 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> On Wed, Jan 29, 2014 at 3:45 PM, Richard Smith <<a href="mailto:metafoo@gmail.com" target="_blank">metafoo@gmail.com</a>> wrote:<br>
>> > I'm not really sure what this is for: don't we want to have a flag for<br>
>> > 'cannot have parens' rather than 'is a standardized C++ attribute'?<br>
>><br>
>> Since standardized C++ attributes all have custom parsing rules (some<br>
>> can have parens, some can't, and the future holds mystery), I think it<br>
>> makes sense to have two cases: things which the standard mandates the<br>
>> parsing rules for, and things which can be generically parsed.<br>
><br>
><br>
> So this flag is (at best) misnamed, then, since we want the generic parsing<br>
> logic for [[deprecated]]?<br>
<br>
We don't want generic parsing logic for [[deprecated]] because it's a<br>
standards-based attribute (in C++1y). We need to error out at parse<br>
time if it's ill-formed, don't we?<br></blockquote><div><br></div><div>We need to diagnose it somewhere. It could be in Sema -- that's what we do for all other attributes, and I don't see any need to be inconsistent here.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the flag is properly-named based on what I was intending --<br>
identify which attributes are C++ standards-based attributes.<br></blockquote><div><br></div><div>When is that useful?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

><br>
> It's also causing us to do the wrong thing for [[clang::fallthrough]];<br>
> (which starts to accept arguments with this patch, but should not).<br>
<br>
It is true that this would change behavior for fallthrough. Inn<br>
handleFallThroughAttr, I should be ensuring the attribute accepted no<br>
arguments.<br></blockquote><div><br></div><div>We don't want to allow parens here, either.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> It seems like what we want is a flag that means "may not have an argument<br>
> clause".<br>
<br>
It's my (perhaps totally wrong) understanding that with<br>
standards-blessed C++ attributes, we want to handle these sort of<br>
things at parse time, but with implementation-specific attributes, we<br>
can handle it in sema. Eg) we need to error out at parse time with<br>
[[noreturn()]] or [[deprecated(12)]], but we can error out at sema<br>
time with [[clang::fallthrough("foo")]] and even accept<br>
[[clang::fallthrough()]].<br>
<br>
>><br>
>> > Also, it<br>
>> > seems easy to detect standard attributes: they're C++ attributes with no<br>
>> > scope token. We don't need to generate a flag for that.<br>
>><br>
>> Except there's nothing mandating that (for instance, gcc or MSVC<br>
>> [someday] could arbitrarily add a C++ style attribute without a scope,<br>
>> ignoring the non-normative note to the contrary). This gives us<br>
>> flexibility to handle it, though it's not required today.<br>
><br>
><br>
> If they do, we should publicly shame them and refuse to implement it. =)<br>
<br>
:-)<br>
<br>
><br>
>><br>
>> > It looks like this causes a regression: we start rejecting<br>
>> > [[deprecated("foo")]] with it, don't we?<br>
>><br>
>> We don't support [[deprecated("foo")]] yet, nor are there any tests<br>
>> for it. We only support [[deprecated]] currently.<br>
><br>
><br>
> We do support it, and it works (but I agree, we seem to have forgotten to<br>
> handle this properly and there are no tests for it). The argument clause is<br>
> ignored entirely for '[[deprecated]]' today, which is not entirely<br>
> conforming, since we're required to reject arguments that aren't<br>
> string-literals, but is more conforming than rejecting such arguments.<br>
<br>
I don't see this as regressing anything; we didn't handle C++11-style<br>
deprecated with a parameter list previously, and this patch doesn't<br>
change that. But it's a moot point.<br></blockquote><div><br></div><div>I don't know what you mean. We used to accept it. With your patch we reject it. That seems like a regression to me! =)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

My goal was to be a bit more declarative instead of having a<br>
hard-coded list, but really, I think that list is somewhat unavoidable<br>
and very slow to grow. So I don't think this patch is as useful as I<br>
had originally expected.<br>
<br>
~Aaron<br>
</blockquote>