[PATCH] Generalized attribute support

Richard Smith metafoo at gmail.com
Wed Jan 15 12:20:18 PST 2014


On Wed Jan 15 2014 at 11:51:24 AM, Nico Weber <thakis at chromium.org> wrote:

> On Wed, Jan 15, 2014 at 3:41 AM, Alp Toker <alp at nuanti.com> wrote:
>
>
> On 15/01/2014 06:04, Nico Weber wrote:
>
> Does gcc allow this for C? Is C planning on standardizing this?
>
>
> The impression I get is that everybody's doing it but nobody's talking
> about it. Yet.
>
>
> Clarified on irc. gcc doesn't implement this, Alp meant that some people
> carry local patches to add this support.
>
> I'm skeptical of adding this if there's no standardization movement for
> this and no other compilers support this yet :-/
>

I agree. As far as I'm aware, we would be the *only* production C compiler
to support C++ attribute syntax. The good news is that we already have a
policy on allowing such extension: http://clang.llvm.org/get_involved.html

The only point where this extension falls down is point 4. Here's what the
C committee said about N1403 (see minutes in N1475):

Do you support double square brackets? [[ ]]
 Yes – 4
 No – 15
 Abs – 3

Do we want a syntax for non-Standard extensions?
 Yes – 4
 No – 12
 Abs – 6

I think it's fair to say we would *not* have the support of the C committee
here.

ISO C is reactionary so if we set a sensible standard there's a reasonable
> shot at getting it adopted. Likewise OpenMP and other dialects -- they'll
> go with the mainstream.
>
> This is also why we should use a name that's already recognised like
> "generalized attributes." Language bodies simply won't accept a foreign
> name like "C++ attributes" -- it has never happened before, given how
> fiercely independent these committees are -- so they'll end up each going
> their own route, choosing their own names. It's a better plan to
> consolidate proactively here.
>
> My view is that it matters because we're working with the people designing
> these standards and they respect our decisions when we put time into
> getting them right.
>
> Of there'll always be those with Richard Smith's point of view that "we
> really don't need to worry about theoretical future C17 or OpenMP
> constructs now" -- but assuming we do care (and I do), these are issues
> that matter.
>
> Alp.
>
>
>
>
>
>
> On Tue, Jan 14, 2014 at 5:50 PM, Richard Smith <richard at metafoo.co.uk<mailto:
> richard at metafoo.co.uk>> wrote:
>
>     On Tue, Jan 14, 2014 at 5:47 PM, Richard Smith
>     <richard at metafoo.co.uk <mailto:richard at metafoo.co.uk>> wrote:
>
>         On Tue, Jan 14, 2014 at 5:23 PM, Alp Toker <alp at nuanti.com
>         <mailto:alp at nuanti.com>> wrote:
>
>             This patch generalizes C++11 attributes for use in C and
>             C-like dialects, and additionally enables the new syntax
>             as an extension to C11.
>
>
>         Why do you allow this by default in C11? And conversely, why
>         not in C90 / C99?
>
>
>     I think maybe this was unclear. I'd prefer one of these two options:
>
>     1) A -fcxx-attributes argument (or similar) to enable C++
>     attribute syntax outside C++ (and either do or don't allow them by
>     default in C++98), or
>     2) C++ attributes available by default in all language modes.
>
>     I'd prefer the first option (defaulting to following the language
>     standard more strictly) -- I think this would be the first time we
>     enabled a C++ language feature in C modes, if we went with the
>     second option.
>
>         If we're going to allow these anywhere by default, C++98 would
>         seem like a good place to start. I don't believe they
>         introduce any ambiguities outside of Objective-C(++), and we
>         already disambiguate those cases. (There's an ambiguity with
>         lambdas, but we don't need to address that until/unless we
>         allow lambdas in C++98.)
>
>             All features are carried forward from C++11, including
>             usage on declarations, attributed statements, scoped
>             attribute names, GNU attribute aliases and the
>             clang-specific attribute namespace.
>
>             A new feature detection macro is provided, breaking from
>             the usual c/cxx prefix convention in order to facilitate
>             portable detection in C++ and C modes:
>
>             __has_feature(attributes) - 1 in C++11, otherwise 0.
>             __has_extension(attributes) - 1 in C++11 and C11, otherwise 0.
>
>
>         This is already available as __has_feature(cxx_attributes);
>         using __has_extension(cxx_attributes) in C would seem to be
>         the right approach here (we're allowing C++ attributes as an
>         extension in C). This is what we already do for C99 and C11
>         features which we accept in C++.
>
>             The new warning flag -W(no-)generalized-attributes
>             suppresses the new extension warning in C. The same flag
>             can also be used to selectively disable attribute
>             compatibility warnings produced by the pre-existing
>             -Wc++98-compat option.
>
>
>         OK, so this is why you wanted us to pick a name for this
>         feature; you're going to use it as a diagnostic name. I think
>         this should be called -Wc++-attributes, to match our existing
>         compatible-for-all-time feature name cxx_attributes. We can
>         add an alias to a better name if we ever need one, but for
>         now, we're pretty clearly allowing a C++ feature in C, so
>         calling it "c++-something" makes sense to me.
>
>             Newly added tests have been shared with C++11 where
>             possible to ensure consistency between language modes.
>
>
>         Does this do the right thing for (for instance)
>
>           struct S {
>             [[ gnu::aligned(8) ]] int n;
>           };
>
>         ? (Structs use different parsing code in C and C++. )
>
>
>
>     _______________________________________________
>     cfe-commits mailing list
>     cfe-commits at cs.uiuc.edu <mailto:cfe-commits at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
>
> --
> http://www.nuanti.com
> the browser experts
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140115/73674e1f/attachment.html>


More information about the cfe-commits mailing list