<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 17, 2014 at 4:03 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Dec 16, 2014 at 4:17 PM, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br>
</span><span class="">> Ok, I moved -Wkeyword-macro into -pedantic in r224371. I also removed<br>
> -Wreserved-id-macro in the same revision, as it's not covered by the<br>
> standards bit you cited<br>
<br>
</span>I do not think -Wreserved-id-macro should be removed entirely, but I<br>
do think it should have a heuristic update before being recommitted,<br>
and is too chatty to leave in currently.<br>
<br>
[global.names] specifies that those names are reserved to the<br>
implementation, but implementations may require use of them. For<br>
instance, __need_size_t may need to be #defined before including<br>
<stddef.h>, and that's valid because the implementer expects that.<br>
However, __MY_SILLY_HEADER_GUARD__ should not be allowed.<br>
<br>
One heuristic which may work would be to make it only trigger on<br>
header include guards when defining macros and to always trigger on<br>
nonmacro names (and never in system headers). I'm not certain how<br>
chatty such a heuristic would be, but it would have less false<br>
positives than the previous patch did.<br>
<br>
FWIW, this can pick out real problems -- I ran into this myself when<br>
working on tablegenning attribute code, which would accidentally<br>
create identifiers like foo__bar, which are reserved to the<br>
implementation.</blockquote><div><br></div><div>Such identifiers are used quite frequently within Clang, where we do things like prefixing keywords with "kw_"; if the keyword starts with an underscore, this pattern gives you a double underscore.</div><div><br></div><div>IIRC, the point of this rule is that some old name mangling schemes used __ (the old GNU mangling scheme used it between function name and signature, and I think some compiler used it as a stand-in for ::). Since such names don't conflict with our mangling scheme (or indeed any modern mangling scheme, as far as I know), this warning should probably be under a different flag.</div></div></div></div>