<div dir="ltr">Very much a +1 on having attributes map in via `__attribute__` and `[[clang::]]` uniformly when appropriate.<br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 21, 2017 at 8:14 AM, Aaron Ballman via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Attributes come with multiple spelling flavors, but when it comes to<br>
adding new attributes that are not present in other compiler tools<br>
such as GCC or MSVC, we have done a poor job of being consistent with<br>
which spelling flavors we adopt the attributes under. Some of our<br>
attributes are specified with only an __attribute__ spelling (about<br>
100), while others are specified with both __attribute__ and<br>
[[clang::XXX]] (about 30), and still others are specified as only<br>
[[clang::XXX]] attributes (only 1). This puts additional burden on<br>
developers to remember which attributes are spelled with what syntax<br>
and the various rules surrounding how to write attributes with that<br>
spelling.<br>
<br>
I am proposing that we take a more principled approach when adding new<br>
attributes so that we provide a better user experience. Specifically,<br>
when adding an attribute that other vendors do not support, the<br>
attribute should be given an __attribute__ and [[clang::]] spelling<br>
unless there's good reason not to. This is not a novel proposal -- GCC<br>
supports all of their documented __attribute__ spellings under a<br>
[[gnu::XXX]] spelling, and I am proposing we do the same with our<br>
vendor namespace.<br>
<br>
Assuming this approach is reasonable to the community, I will add a<br>
CLANG spelling that behaves similar to the GCC spelling in that it<br>
automatically provides both the GNU and CXX11 spellings as<br>
appropriate. There are some attributes for which a [[clang::XXX]]<br>
spelling is not appropriate:<br>
  * attributes that appertain to function declarations but require<br>
accessing the function parameters, such as disable_if or<br>
requires_capability<br>
  * attributes with GNU spellings whose use is discouraged or<br>
deprecated, such as no_sanitize_memory<br>
  * attributes that are part of other vendor specifications, like CUDA or OpenCL<br>
These deviations are reasonable, but should be documented in Attr.td<br>
near the Spelling definition for the attribute so that it's explicitly<br>
understood why the spelling differs.<br>
<br>
Additionally, I intend for the proposed CLANG spelling to be extended<br>
in the future to more easily expose [[clang::XXX]] spellings for<br>
attributes intended to be used in C (with<br>
-fdouble-square-bracket-<wbr>attributes) as well as C++.<br>
<br>
As always, feedback is welcome!<br>
<br>
~Aaron<br>
______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>