<div>On Wed Jan 29 2014 at 12:54:14 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 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></blockquote><div><br></div><div>So this flag is (at best) misnamed, then, since we want the generic parsing logic for [[deprecated]]?</div><div><br></div>
<div>It's also causing us to do the wrong thing for [[clang::fallthrough]]; (which starts to accept arguments with this patch, but should not).</div><div><br></div><div>It seems like what we want is a flag that means "may not have an argument clause".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 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></blockquote><div><br></div><div>If they do, we should publicly shame them and refuse to implement it. =)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

> 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></blockquote><div><br></div><div>We do support it, and it works (but I agree, we seem to have forgotten to handle this properly and there are no tests for it). The argument clause is ignored entirely for '[[deprecated]]' today, which is not entirely conforming, since we're required to reject arguments that aren't string-literals, but is more conforming than rejecting such arguments.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
~Aaron<br>
<br>
><br>
> On Wed Jan 29 2014 at 11:56:34 AM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> This patch provides a declarative way to specify a standards-based<br>
>> C++11-style attribute using the StdCXX spelling class. It then removes<br>
>> a small, hard-coded list of standard attributes from the parser and<br>
>> uses a generated list to accomplish the same thing.<br>
>><br>
>> Since C++11 attributes are not in the std:: namespace, this also<br>
>> removes the std:: variant from standards-based attributes. However, if<br>
>> the std:: namespace were to become part of the standard, it can be<br>
>> handled when flattening out the attributes in the same way that we do<br>
>> for GCC spellings.<br>
>><br>
>> ~Aaron<br>
</blockquote>