[PATCH] Generalized attribute support

[Alp Toker]

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.

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