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@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > -- Saleem Abdulrasool compnerd (at) compnerd (dot) org
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits