[cfe-commits] Rép: [PATCH] _has_feature support for new C1X features.

[Jean-Daniel Dupas]

Le 29 avr. 2011 à 20:07, Douglas Gregor a écrit :

> 
> On Apr 29, 2011, at 10:44 AM, Peter Collingbourne wrote:
> 
>> On Fri, Apr 29, 2011 at 08:13:05AM -0700, Douglas Gregor wrote:
>>> Sorry I missed this original discussion, but I actually disagree with Peter's suggestions. Both C++ and Objective-C feature-test identifiers have language prefixes (cxx_, objc_), and features that come from a particular revision of that language are tied to the appropriate LangOpts bit. I don't see any reason for C to deviate. Any claim they had about being a common subset evaporated with VLAs and their _Keyword_uglification strategy for C++ features :)
>>> 
>>> For example, consider "static_assert":  __has_feature(static_assert) doesn't mean that "static_assert" is a keyword, which is what one would expect from a common feature. It means that we have the C1x _Static_assert. I'd far rather have the unambiguous __has_feature(c_static_assert).
>> 
>> OK, I am fine with introducing a c_ prefix, for the reasons you
>> point out.  But the way I understand it is that __has_feature in fact
>> has 2 semi-orthogonal purposes:
>> 
>> 1) To test for support for Clang-specific extensions to the language.
>>  This is the purpose of the non-language-prefixed feature test
>>  identifiers.
>> 
>> 2) To test for Clang support for language features which have been
>>  standardised in the current language.  This is the purpose of the
>>  language-prefixed feature test identifiers.
>> 
>> However, there is a gap here in that there is no way to test for
>> the existence of Clang-specific language extensions which have been
>> standardised in other languages.  For example, generic selections
>> can be used to implement an OpenCL runtime library using Clang.
>> Since OpenCL is based on C99, generic selections would be classified
>> as an extension.  This makes it impossible to test for that extension.
>> 
>> One solution to this problem is to have 2 feature test identifiers
>> for each standardised feature (e.g. "c_generic_selections" and
>> "generic_selections"), each serving the 2 purposes mentioned above.
>> The disadvantage of this approach would obviously be the doubling up of
>> language feature identifiers.  Also, as you point out "static_assert"
>> would be ambiguous.
>> 
>> An alternative solution would be to introduce another macro, say
>> __has_extension, which takes the same feature test identifiers
>> as __has_feature.  __has_extension would test the features of
>> the compiler alone (approximately serving purpose 1) while
>> __has_feature tests the features of the compiler together
>> with the current language (approximately serving purpose 2).
>> 
>> So for example __has_feature(c_generic_selections) could be
>> used to test for support for generic selections in C1X while
>> __has_extension(c_generic_selections) could be used in any language.
>> I would imagine that __has_extension should act identically to
>> __has_feature if -pedantic-errors (or perhaps -pedantic) is enabled.
>> 
>> Please let me know what you think.
> 
> I think that __has_extension is an *excellent* idea!
> 
>>> With generic selections, I'd far rather have __has_feature(c_generic_selections) than what we currently have. However, we may be stuck with the name since it's been in the tree for a while. Peter, do you have any idea of whether anyone depends on the name __has_feature(generic_selections)?
>> 
>> I am not currently using __has_feature(generic_selections) neither
>> am I aware of any users.
>> 
>> I think we would be justified to rename the feature given that it
>> has not yet appeared in any released version of Clang.
> 
> Okay, great!



I tried to implements this new suggestion.
The has_feature variants are bound to the selected language and returns true only when compiling as C1X, and has_extension always returns true.
Is this what you had in mind ? 


-- Jean-Daniel



-------------- next part --------------
A non-text attachment was scrubbed...
Name: feature.diff
Type: application/octet-stream
Size: 5501 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110430/3b2b7b7b/attachment.obj>