[PATCH] Generalized attribute support

[Nico Weber]

Does gcc allow this for C? Is C planning on standardizing this?


On Tue, Jan 14, 2014 at 5:50 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Tue, Jan 14, 2014 at 5:47 PM, Richard Smith <richard at metafoo.co.uk>wrote:
>
>> On Tue, Jan 14, 2014 at 5:23 PM, Alp Toker <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
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140114/da736e27/attachment.html>