Attribute spelling policy

Arthur O'Dwyer via cfe-commits cfe-commits at lists.llvm.org
Mon Oct 23 08:16:09 PDT 2017


On Mon, Oct 23, 2017 at 7:33 AM, Aaron Ballman via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

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

This seems like a departure from what you wrote originally, unless you just
misspoke or I misinterpreted.
You originally said, "[New attributes] should be given an __attribute__ and
[[clang::]] spelling unless there's good reason not to."  I would 100%
agree with that policy, from a user's point of view. It would be awesome to
know exactly how an attribute is spelled without having to look it up in
the manual.
But when you used the word "instead" just now, you implied that the policy
would be more like "New attributes should be given an __attribute__ and
[[clang::]] spelling unless there's good reason not to, *or unless Clang is
copying work originally done by the GNU project*, in which case the new
attribute should be given __attribute__ and [[gnu::]] spellings but not a
[[clang::]] spelling." Is that really what you meant, or was your original
statement closer to what you meant?

As a user, I would strongly prefer to write all my attributes in a
consistent way. If that way has to be __attribute__((foo)), then okay. But
in C++11-and-later, it would be nice to write all my attributes as
[[clang::foo]], and not have to keep consulting the manual to find out
which of [[foo]], [[clang::foo]], and [[gnu::foo]] is the proper spelling
for this particular attribute.

Of course the worst possible outcome would be where [[clang::foo]] and
[[gnu::foo]] both exist and have different semantics. I hope that doesn't
happen!  But if it has already happened, then it becomes even more
important that a user of Clang never need to use the [[gnu::]] spelling for
any Clang attribute (because accidentally using [[gnu::]] on the wrong
attribute could cause bugs, in the hypothetical case that [[clang::foo]]
and [[gnu::foo]] have different semantics).

Basically, as a user, I would like to see:
- Attribute names never deliberately collide with other vendors
- Every attribute supported by Clang is available under __attribute__
- Every attribute supported by Clang is available under [[clang::]]
- Any attribute that mimics a GNU feature is available under [[gnu::]] (and
also under the two above)
- Any attribute that mimics an MSVC feature is available under [[msvc::]]
(and also under the first two above)
- Any attribute that mimics a GNU-and-MSVC feature (thus, a feature
available on all three platforms) is available under all of [[gnu::]],
[[msvc::]], and [[clang::]] (and also under __attribute__)

Then, as a user, I don't need to care about the historical accident of
which project's employees invented a feature first; I can just use the
[[xxx::]] prefix corresponding to my primary compiler, and either it will
work or it will error out (in which case I'll know that my primary compiler
does not support that feature).

my $.02,
–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20171023/7c6a5091/attachment-0001.html>


More information about the cfe-commits mailing list