Attribute spelling policy

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Mon Oct 23 07:33:01 PDT 2017


On Mon, Oct 23, 2017 at 9:48 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> 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?

Yes; we should use the [[gnu::X]] spelling instead of adding the same
attribute under [[clang::X]] unless we think our semantics need to
significantly differ from GCC's.

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

Of sorts. P0542 describes the same problem we're running into with
disable_if and others, but its solution is highly concerning because
it removes the ability to specify any attributes on the function type
and it introduces an irregularity in the way attributes are specified.
I really don't like the direction taken in P0542, but I agree with the
problem and think it needs to be solved.

~Aaron

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


More information about the cfe-commits mailing list