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

[Alp Toker]

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.

Beyond names we raise warnings for right now, all names starting __is_* 
and to a lesser extent __has_* are best considered reserved prefixes for 
maximum compatibility going forward.

This is suggested out of practicality given that new type trait 
intrinsics are proposed all the time and will be handled as straight 
keywords, not just by clang but all mainstream compilers.

The existing keywords were only accepted as type names by clang due to 
an old compatibility hack to support GNU stdc++ headers. It's invasive 
to the parser and changes the way tokens are handled so we're warning on 
this starting 3.4 to get system headers fixed. New code should not be 
relying on the fallback.

The quad-underscore prefix in your patch is a matter of taste. Another 
option may be to use a different naming convention or just a single 
underscore, putting the structs in a private namespace so they aren't 
visible to user code.

Whichever approach you take, I recommend clearing all of the __is_* and 
__has_* occurrences, not just ones that are keywords today, in order to 
avoid a new conflict each time an intrinsic is added to the compiler or 
a different language standard is selected. Keyword names are predictable 
and highly likely to follow the existing convention.

I further recommend that libc++ switches on system header warnings in 
the development build. We're adding new diagnostics in clang intended to 
assist standard library developers and it's a shame to suppress them 
during the LLVM development and testing cycle.

Alp.



>
> -Dimitry
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-- 
http://www.nuanti.com
the browser experts