<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 23/12/2013 20:16, Marshall Clow
wrote:<br>
</div>
<blockquote
cite="mid:9201D53D-058F-475C-AE56-F47503F9C6EF@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br>
<div>
<div>On Dec 22, 2013, at 6:37 PM, Alp Toker <<a
moz-do-not-send="true" href="mailto:alp@nuanti.com">alp@nuanti.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 11px; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: auto; word-spacing: 0px; -webkit-text-stroke-width:
0px;"><br>
On 23/12/2013 00:46, Marshall Clow wrote:<br>
<blockquote type="cite">On Dec 22, 2013, at 1:58 PM, Alp
Toker <<a moz-do-not-send="true"
href="mailto:alp@nuanti.com">alp@nuanti.com</a> <<a
moz-do-not-send="true" href="mailto:alp@nuanti.com">mailto:alp@nuanti.com</a>>>
wrote:<br>
<br>
<blockquote type="cite">On 22/12/2013 21:27, Dimitry
Andric wrote:<br>
<blockquote type="cite">Hi,<br>
<br>
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:<br>
</blockquote>
[snipped]<br>
<blockquote type="cite">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]<br>
struct __is_unsigned : public
___is_unsigned<_Tp> {};<br>
^<br>
9 warnings generated.<br>
<br>
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.<br>
<br>
Is the attached patch acceptable as a workaround?</blockquote>
</blockquote>
</blockquote>
</div>
</blockquote>
<br>
</div>
<div>I’m still confused.</div>
<div>I tried the following tests using today’s clang (and libc++):</div>
</blockquote>
<br>
Hi Marshall,<br>
<br>
I'll step you through each of the cases you posted.<br>
<br>
<br>
In your first example:<br>
<br>
<code>trait.cpp:1:39: error: expected '('</code><code><br>
</code><code> int main () { const int i =
__is_void<int>::value; }</code><code><br>
</code><code> ^</code><br>
<br>
__is_void is handled as an intrinsic keyword which the parser
expects to be written as a functional call. Try the following to get
it to compile:<br>
<br>
<code> int main () { const int i = __is_void(int); }</code><code><br>
</code><br>
<br>
<br>
In your second example:<br>
<br>
<code>trait.cpp:1:34: error: expected unqualified-id</code><code><br>
</code><code>int main () { const int i =
std::__is_void<int>::value; }</code><code><br>
</code><code> ^</code><br>
<br>
std:: is parsed as the beginning of a nested name specifier. When
the __is_void keyword is encountered, the scope specifier is no
longer valid and the error diagnostic is emitted.<br>
<br>
The error message in your third example is changed after inclusion
of headers because <type_traits> header activated the fallback
mode and downgraded __is_void to an identifier. You can get it to
compile as in your final example if you prefix __is_void with std::<br>
<br>
In the last two examples you've activated the GNU header
compatibility mode by attempting to introduce keywords as a type
name in system headers. The appropriate extension warning will have
been issued:<br>
<br>
<br>
<code>include/c++/v1/type_traits:288:29: warning: keyword
'__is_void' will be made available as an identifier for the
remainder of the translation unit</code><code><br>
</code><code>template <class _Tp> struct __is_void :
public false_type {};</code><br>
<br>
There are any number of __is_* compiler built-ins in clang and other
compilers, and there will be more added in the new year so it's a
good plan to move away from using these intrinsic names as type
names while we still have the keyword hack in the parser.<br>
<br>
Alp.<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.nuanti.com">http://www.nuanti.com</a>
the browser experts
</pre>
</body>
</html>