patch: add GCC bit to Attr.td and use it to disable -Wgcc-compat

Aaron Ballman aaron at aaronballman.com
Tue Oct 29 10:04:18 PDT 2013


On Tue, Oct 29, 2013 at 12:56 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> On 29 Oct 2013 08:46, "Aaron Ballman" <aaron at aaronballman.com> wrote:
>>
>> On Mon, Oct 28, 2013 at 10:52 PM, Nick Lewycky <nlewycky at google.com>
>> wrote:
>> > On 18 October 2013 10:50, Aaron Ballman <aaron at aaronballman.com> wrote:
>> >>
>> >> Can this be done as part of the attribute spelling instead of a
>> >> separate bit?  Eg) introduce GCC as a spelling that implies GNU?
>> >
>> > You can add a GCC spelling but you can't make a single spelling imply
>> > both
>> > GNU and CXX11<"gnu",...>. I tried this first -- having one GCC entry in
>> > the
>> > Spellings list imply two spellings under the hood, but it was really,
>> > nasty.
>> > Do not suggest that I do this unless you try it.
>>
>> It may be nasty, but it's also far less error-prone for everyone
>> defining attributes.  You have an explicit assumption in the tablegen
>> that the GNU spellings will also have a matching CXX11 spelling with
>> gnu::, but that's extra, hidden work for people writing attributes.
>> It would be considerably less burden on everyone writing attributes
>> were this to not be an assumption within tablegen, but be an
>> obligation via the syntax.
>>
>> What I am proposing is to retain the GNU and CXX11 spelling as-is, but
>> add another spelling type: GCC.  GCC<"string"> is semantically
>> equivalent to GNU<"string">, CXX11<"gnu", "string"> for the spellings,
>> and let GCC = 1 for the extra bit you just added.
>
> I believe this is exactly the approach that Nick described as really nasty.

It is, but from the work I've done on tablegenning attributes, I don't
understand what is nasty about it.  Everything I described is either
already supported, or code that Nick just wrote, with the exception of
hooking things together.

> I'd be fine with tablegen just checking that the user got it right. We want
> to catch errors, but this file doesn't need to be maximally convenient to
> write. We don't add attributes that often.

Having been working very hard recently to reduce the amount of things
people screw up in Attr.td, I am loathe to add more to it without
understanding where the problems actually lie.  I see the rationale
for the changes as being good, but the implementation is a lateral
step in terms of the problem trying to be solved.  The fact that
people don't add attributes that frequently is all the more reason to
improve things.

~Aaron



More information about the cfe-commits mailing list