Attribute spelling policy

[Hal Finkel via cfe-commits]

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 
same?

>
> 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,
Hal

>    * 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 Attr.td
> 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 lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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