[PATCH] Generalized attribute support
Alp Toker
alp at nuanti.com
Wed Jan 15 12:23:26 PST 2014
On 15/01/2014 19:51, Nico Weber wrote:
> On Wed, Jan 15, 2014 at 3:41 AM, Alp Toker <alp at nuanti.com
> <mailto: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.
Right. I looked into this because a few different groups requested the
feature last week.
It makes a lot of sense but it's not a need on my end.
>
> I'm skeptical of adding this if there's no standardization movement
> for this and no other compilers support this yet :-/
Waiting for standardisation isn't a great idea if the C99-C11 interval
is anything to go by.
Seems reasonable to hold back and see if gcc implements the feature.
Let's revisit then?
Alp.
>
> 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>
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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
>
>
--
http://www.nuanti.com
the browser experts
More information about the cfe-commits
mailing list