[PATCH] Generalized attribute support

[Alp Toker]

On 15/01/2014 11:41, Alp Toker 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.
>
> 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.

To be clear, this isn't just about naming. The syntaxes will also end up 
differing if we end up with disparate "C++ attributes", "OpenMP 
attributes", "OpenCL attributes" (?), "C attributes"  -- potentially a 
bunch of different specifications and quirky parse rules with no way out.

We can do better than that by taking charge of the situation and setting 
a decisive precedent: This proposal introduces generalized attributes 
suitable for use in most C-like languages.

Alp.

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