[RFC] Enable C++11/C2x attributes in all standard modes as an extension and remove `-fdouble-square-bracket-attributes`

[AaronBallman]

@philnik

A problem with this approach is that libraries cannot rely on the extension actually being present, so it’s not really possible to make use of the extension for them.

Libraries still cannot rely on the extension because nobody implements this as an extension in all language modes (at least, last time I checked). Updating __cpp_attributes will help library folks in C++ know whether the extension is supported or not, as that’s standardized. But what’s the plan for C folks (we don’t have standardized feature testing macros in C)? I think we could probably add a __has_extension entry for C, analogous to __has_extension(cxx_attributes). WDYT?

@philnik

That the flag is basically never used would suggest that it’s a good idea to just remove it, but I think the better thing to do would be to enable the extension unconditionally. Doing this will not break any users, since it’s a conforming extension and anybody who uses the flag to enable C++ attributes currently just gets them instead. This also allows libraries like libc++ to rely on the C++ attribute syntax being available, making it possible to simplify some code. Making C++ attributes available in all language modes simplifies the clang code a bit as well, since the language mode doesn’t have to be checked anymore. Another benefit is that diagnostics are better because a warning that you’re using an extension is emitted instead of complaining about unexpected tokens.

I’m in support of this idea. I think we should enable the extension unconditionally for Clang 17 with a release note mentioning that -fdouble-square-bracket-attributes will be removed in Clang 18 just as a kindness to users with proprietary code bases that might be using it.

@philnik

This would also allow Clang to stop using the GNU attribute syntax for newly introduced attributes, making it easier to distinguish between Clang and GCC extensions, and allowing access to clang statement attributes like [[clang::always_inline]] which are currently not possible use in C++03/before C2x.

Eh, not quite. New attributes added to Clang should be using the Clang spelling, which includes both a GNU- and a C+±style spelling. There are still a few cases where we only expose the attribute as a GNU spelling or under a different vendor namespace with a C+±style spelling, but those are one-offs.