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

[Jean-Daniel Dupas]

Le 1 mai 2011 à 02:34, Jean-Daniel Dupas a écrit :

> 
> Le 30 avr. 2011 à 23:08, Peter Collingbourne a écrit :
> 
>> On Sat, Apr 30, 2011 at 08:08:06PM +0200, Jean-Daniel Dupas wrote:
>>> 
>>> Le 29 avr. 2011 à 20:07, Douglas Gregor a écrit :
>>> 
>>>> 
>>>> On Apr 29, 2011, at 10:44 AM, Peter Collingbourne wrote:
>>>>> 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!
>>> 
>>> 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 ? 
>> 
>> __has_extension should be a superset of __has_feature, so it should
>> also include the C++ and C++0x features, as well as the Clang specific
>> extensions.  This can be done trivially by calling HasFeature from
>> HasExtension.
>> 
>> I began an implementation (see patch), but this is incomplete since it
>> includes no tests.  I also haven't surveyed all of the C++0x features
>> to see which are supported as extensions to C++98.  If you like,
>> you can extend the patch to add the correct set of C++0x features as
>> well as tests.
>> 
> 
> I'm not very familiar with C++0x features supported as extensions but a quick look in diagnostics gave 3 more features.
> Someone familiar with this part should definitively review this list.
> 
> I also add a couple of simple tests, for c1X features and has_extensions.
> 


If everybody is ok with has_extension, maybe someone can push the last version of the patch ? 

-- Jean-Daniel