[cfe-commits] [Patch][Review] __has_feature(__feature__)

[Jonathan Sauer]

Hello,

>> following the discussion in cfe-dev[*], I decided to put my money where my mouth is and have attached a patch
>> that makes it possible to use __has_feature(__feature__) in place of __has_feature(feature) to protect the
>> feature name in case the user defines a macro with the same name.
>> 
>> I modeled the patch after the similar handling of __attribute__ names.
> 
> This patch looks great to me, please commit!

As I have not commit access, I would kindly ask someone who has to do it for me.

I updated the patch to include Jean-Daniel's suggestion to handle __has_extension the same way. I also
modified the code slightly to make the normalization of the name work without invoking undefined
behaviour in case the string is shorter than 4 characters: Before, it depended on the assumption that an
unsigned integer underflow would result in a very large integer, which was then ignored as it was larger
than the string size. As this also was the case when normalizing the attribute name, I modified that
code as well.

I don't think that a feature "has_feature_supports_double_underscore" or similar is necessary. Simply
choose an arbitrary extension that is always supported in clang and check for the feature with and
without underscores:

  #if __has_extension(c_alignas) && !__has_extension(__c_alignas__)
  #  message Double underscores in extension names are not supported
  #else
  #  message Double underscores in extension names are supported
  #endif

If you disagree, just tell me and I'll add it.


I have attached the new patch.


Jonathan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: underscore_features.diff
Type: application/octet-stream
Size: 4148 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120225/3f86b354/attachment.obj>
-------------- next part --------------