[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