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

[Peter Collingbourne]

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.

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

Thanks,
-- 
Peter