Attribute spelling policy

[Saleem Abdulrasool via cfe-commits]

Very much a +1 on having attributes map in via `__attribute__` and
`[[clang::]]` uniformly when appropriate.

On Sat, Oct 21, 2017 at 8:14 AM, Aaron Ballman via cfe-commits <
cfe-commits at lists.llvm.org> 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.
>
> 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
>   * 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
>



-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20171022/ea2430b3/attachment.html>