[cfe-dev] Possible bug with __has_cpp_attribute

[Kal]

Am 06.05.15 um 14:21 schrieb Aaron Ballman:
> On Wed, May 6, 2015 at 4:28 AM, Kal <b17c0de at gmail.com> wrote:
>> Hi,
>> The following seems like a clang bug.
>>
>> You can't use __has_cpp_attribute with namespaces in a header that is
>> included from C. For example:
>> #if __has_cpp_attribute(clang::fallthrough)
>>     ...
>> #endif
>>
>> Yields:
>> error: builtin feature check macro requires a parenthesized identifier.
>>
>> Shouldn't __has_cpp_attribute() evaluate to 0 for C programs?
> That's debatable. I would say it should be an error for C programs to
> refer to __has_cpp_attribute because it should not be a predefined
> macro there. I think the bug is that __has_cpp_attribute isn't flag as
> being available only for C++. Then you could use the canonical
> #if/#elif block for C++ attribute feature testing, without needing the
> __cplusplus bit in yours.
>
> ~Aaron

 From claim documentation for __has_cpp_attribute: " If the attribute is 
not supported by the current compliation target, this macro evaluates to 
0." No C++ attributes are supported when compiling for C, so shouldn't 
they just all return 0? If __has_cpp_attribute wasn't defined at all for 
C programs that would also be good. Either way, what clang does now 
seems broken.

>
>> I worked around the issue with something like:
>>
>> #ifndef __has_cpp_attribute
>> #define __has_cpp_attribute(x) 0
>> #elif defined(__clang__) && !defined(__cplusplus)
>> #pragma clang diagnostic push
>> #pragma clang diagnostic ignored "-Wbuiltin-macro-redefined"
>> #define __has_cpp_attribute(x) 0
>> #pragma clang diagnostic pop
>> #endif
>>
>> Is there a better way?
>>
>> -Kal
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150506/c5a7c72a/attachment.html>