[PATCH] D37436: Initial implementation of C attributes (WG14 N2137)

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D37436#867965, @aaron.ballman wrote:

> In https://reviews.llvm.org/D37436#867287, @rsmith wrote:
>
> > If this is just supposed to be an experiment to get feedback on the feature,  then I don't think we should be treating it as a different attribute syntax at all. Rather, I think we
> >  just want to permit C++11 attributes to be parsed in other language modes. If/when this becomes part of some future C working draft, I think that's the time to have a
> >  separate attribute syntax with a distinct set of valid unqualified attribute names.
>
>
> I do not think that's the correct approach. These are not C++ attributes (for instance, no `using` insanity is allowed, `::` is a new lexing token in C, etc). Also, I don't think it's a good idea to enable all C++11-style attributes in C mode without giving each attribute some appropriate thought (what does `abi_tag` *do* in C mode? What happens with _Noreturn vs [[noreturn]] etc). Also, I'm not comfortable adding a bunch of vendor-specific `gnu::` attributes that GCC does not implement in C yet.


On this last point, I disagree. Implementation experience is about all of the messy things that occur in production. In production, if we have this syntax, then we'll end up enabling it for a bunch of vendor-specific attributes. Do you think that we wouldn't? N2137 specifically talks about this as a use case. If so, this will include `gnu::` attributes that we have in Clang (even if GCC does not implement them). From my perspective, lack of consistency here between Clang's C and C++ modes is much more problematic than a lack of consistency between what Clang and GCC implement.


https://reviews.llvm.org/D37436