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

[Peter Collingbourne]

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 also wonder whether we should stop adding new non-standardised
features to __has_feature (strictly speaking, under the new regime
__has_feature(X) should always be 0 if X is a non-standardised
feature, but we shouldn't do this for existing features for backwards
compatibility reasons).  That is the way I wrote the documentation in
my patch, but I suppose an argument can also be made for maintaining
the existing behaviour of __has_feature and continuing to add
non-standardised features.

Thanks,
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-__has_extension.patch
Type: text/x-diff
Size: 25710 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110430/44339b44/attachment.patch>