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

Douglas Gregor dgregor at apple.com
Fri Apr 29 08:13:05 PDT 2011


On Apr 29, 2011, at 7:32 AM, Jean-Daniel Dupas wrote:

> 
> 
> Début du message réexpédié :
> 
>> De : Jean-Daniel Dupas <devlists at shadowlab.org>
>> Date : 26 avril 2011 09:53:42 HAEC
>> À : Peter Collingbourne <peter at pcc.me.uk>
>> Cc : cfe-commits at cs.uiuc.edu
>> Objet : Rép : [cfe-commits] [PATCH] _has_feature support for new C1X features.
>> 
>> 
>> Le 26 avr. 2011 à 01:02, Peter Collingbourne a écrit :
>> 
>>> On Mon, Apr 25, 2011 at 09:15:09PM +0200, Jean-Daniel Dupas wrote:
>>>> As clang start to implements C1X, it may be useful to extend __has_feature to support the new implemented features.
>>>> 
>>>> Here is a patch that add 'c_static_assert' and 'c_generic_selection', and a test case similar to the one used for c++0x.
>>>> 
>>>> This patch adds 'c_generic_selection', but I don't know the status of this feature. If it is not ready yet, this part should be commented.
>>> 
>>> Hi Jean-Daniel,
>>> 
>>> We already have __has_feature(generic_selections).
>> 
>> My bad, I missed it.
>> I moved it next to "static_assert", so it would be easier to find what C1X extensions are already declared here.
>> 
>>> Prefixing C features with c_ is unprecedented (and it would of course
>>> be a bad idea to rename the existing C features/extensions) so I think
>>> that for the sake of consistency the C1X static assert feature should
>>> just be called "static_assert".
>> 
>> Of course, it would definitively be better to keep it consistent.
>> 
>>> Also, C1X static assertions are supported as an extension in all
>>> languages so the feature should not be predicated on the C1X language
>>> option.
>> 
>> 
>> Here is a patch that simply add "static_assert" and declare it enabled unconditionally.
>> 
> 
> 
> Is there someone to review (and apply) this minor change ? 


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

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)?

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110429/0ba3e1c7/attachment.html>


More information about the cfe-commits mailing list