This is an archive of the discontinued LLVM Phabricator instance.

Support the __gnu__ scoped attribute token
ClosedPublic

Authored by aaron.ballman on Oct 23 2018, 11:11 AM.

Details

Summary

GCC is currently considering a patch to accept __gnu__ as a scoped attribute namespace that aliases to gnu. This is useful for libstdc++ so that they don't have to worry about stepping on the user's namespace. The GCC bug can be found at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86288

This patch supports parsing __gnu__, but it does support __clang__ similarly because __clang__ is a predefined macro that expands to an empty expansion. In order to support [[__clang__::foobar]] as an attribute spelling, I think we'd need to introduce some frontend hacks. Rather than get bogged down in that support, I am proposing to support only __gnu__ for the moment, to ensure we remain compatible with libstdc++ when it makes the switch to the new attribute namespace.

Btw, an alternative implementation strategy here would be to make the GCC spelling introduce both the gnu and __gnu__ variants of the attribute in addition to the GNU-style spelling. We have no CXX11 spellings that manually specify gnu as the vendor namespace, so this would suffice, but it feels a bit more fragile than baking this into the attribute system directly.

Diff Detail

Event Timeline

aaron.ballman created this revision.Oct 23 2018, 11:11 AM
rsmith accepted this revision.Oct 23 2018, 6:29 PM

Looks good.

We should provide some reserved-name way of naming clang attributes too, but I'm not sure what would be best (__clang__ is a macro name). Maybe _Clang? (And maybe we should detect an integer literal 1 as a scope specifier and check whether it was written as a macro __clang__, and provide a custom error suggesting using whatever other scope specifier we prefer.)

This revision is now accepted and ready to land.Oct 23 2018, 6:29 PM
aaron.ballman closed this revision.Oct 24 2018, 5:36 AM

Looks good.

Thanks! I've commit in r345132.

We should provide some reserved-name way of naming clang attributes too, but I'm not sure what would be best (__clang__ is a macro name). Maybe _Clang? (And maybe we should detect an integer literal 1 as a scope specifier and check whether it was written as a macro __clang__, and provide a custom error suggesting using whatever other scope specifier we prefer.)

I agree. That's the approach I was thinking of taking as well. I wasn't quite certain if we needed _Clang though if we can just make __clang__ work through macro hacks.

Should #pragma clang attribute also be updated to support #pragma _Clang/__clang__ attribute?