[cfe-dev] Keyword warnings in libc++'s type_traits and other headers

Marshall Clow mclow.lists at gmail.com
Sun Dec 22 16:46:42 PST 2013

On Dec 22, 2013, at 1:58 PM, Alp Toker <alp at nuanti.com> wrote:

> On 22/12/2013 21:27, Dimitry Andric wrote:
>> Hi,
>> I ran into a situation where a C++ program was compiled with -Wsystem-headers.  When I did this with clang 3.4 or trunk, I got the following keyword warnings:
> [snipped]
>> include/type_traits:668:8: warning: keyword '__is_unsigned' will be made available as an identifier for the remainder of the translation unit [-Wkeyword-compat]
>> struct __is_unsigned : public ___is_unsigned<_Tp> {};
>>       ^
>> 9 warnings generated.
>> This seems to have been introduced with r196212 in clang by Alp Toker, but it is unfortunate the warning hits libc++. :-)  The cause is a bunch of Embarcadero keywords defined in clang's lib/Parse/ParseExpr.cpp, which are exactly the same as these libc++-internal identifers.
>> Is the attached patch acceptable as a workaround?
> Hi Dimitry,
> Thanks for looking into this. Your analysis of the situation is correct and the patch for libc++ is headed in the right direction.

I am strongly against this patch on several levels.

1) I would like to understand why (and how we came to) have two different sets of type traits implementations with the same name; one in libc++ and the other in the Embarcadero version of clang. Or maybe it’s not just in the Embarcadero version - though they are listed in TokenKinds.def as "Embarcadero Type Traits”

2). I would like to have a discussion about the *desirability* of having these in the compiler; clearly most of these type traits are implementable purely as a library.

3) I *hate* the idea of using “quad underscores” to differentiate names; I spent *two hours* a couple months ago trying to figure out why my code was failing, only to determine that I was calling __xxx instead of ___xxx. (triple underscore vs. double)  If we decide to change libc++ for this, I would recommend renaming __is_void to something like __libcpp_is_void - something visually different.

— Marshall

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

More information about the cfe-dev mailing list