Attribute spelling policy

Hal Finkel via cfe-commits cfe-commits at
Mon Oct 23 06:48:11 PDT 2017

On 10/21/2017 10:14 AM, Aaron Ballman via cfe-commits wrote:
> Attributes come with multiple spelling flavors, but when it comes to
> adding new attributes that are not present in other compiler tools
> such as GCC or MSVC, we have done a poor job of being consistent with
> which spelling flavors we adopt the attributes under. Some of our
> attributes are specified with only an __attribute__ spelling (about
> 100), while others are specified with both __attribute__ and
> [[clang::XXX]] (about 30), and still others are specified as only
> [[clang::XXX]] attributes (only 1). This puts additional burden on
> developers to remember which attributes are spelled with what syntax
> and the various rules surrounding how to write attributes with that
> spelling.
> I am proposing that we take a more principled approach when adding new
> attributes so that we provide a better user experience. Specifically,
> when adding an attribute that other vendors do not support, the
> attribute should be given an __attribute__ and [[clang::]] spelling
> unless there's good reason not to. This is not a novel proposal -- GCC
> supports all of their documented __attribute__ spellings under a
> [[gnu::XXX]] spelling, and I am proposing we do the same with our
> vendor namespace.

For attributes that both Clang and GCC support, where GCC provides a 
[[gnu::X]] syntax, do you propose that our policy will be to support the 

> Assuming this approach is reasonable to the community,
>   I will add a
> CLANG spelling that behaves similar to the GCC spelling in that it
> automatically provides both the GNU and CXX11 spellings as
> appropriate. There are some attributes for which a [[clang::XXX]]
> spelling is not appropriate:
>    * attributes that appertain to function declarations but require
> accessing the function parameters, such as disable_if or
> requires_capability

Is this restriction related to the change that p0542 proposes to make to 
the interpretation of attributes that appear after functions as part of 
the contracts proposal?

Thanks again,

>    * attributes with GNU spellings whose use is discouraged or
> deprecated, such as no_sanitize_memory
>    * attributes that are part of other vendor specifications, like CUDA or OpenCL
> These deviations are reasonable, but should be documented in
> near the Spelling definition for the attribute so that it's explicitly
> understood why the spelling differs.
> Additionally, I intend for the proposed CLANG spelling to be extended
> in the future to more easily expose [[clang::XXX]] spellings for
> attributes intended to be used in C (with
> -fdouble-square-bracket-attributes) as well as C++.
> As always, feedback is welcome!
> ~Aaron
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

More information about the cfe-commits mailing list