[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