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!
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
