On Tue, Oct 29, 2013 at 12:56 PM, Richard Smith <[email protected]> wrote: > > On 29 Oct 2013 08:46, "Aaron Ballman" <[email protected]> wrote: >> >> On Mon, Oct 28, 2013 at 10:52 PM, Nick Lewycky <[email protected]> >> wrote: >> > On 18 October 2013 10:50, Aaron Ballman <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
