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@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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
