r224012 - Emit warning if define or undef reserved identifier or keyword.

Richard Smith richard at metafoo.co.uk
Thu Dec 18 14:44:24 PST 2014


On Wed, Dec 17, 2014 at 4:03 PM, Aaron Ballman <aaron at aaronballman.com>
wrote:
>
> On Tue, Dec 16, 2014 at 4:17 PM, Nico Weber <thakis at chromium.org> wrote:
> > Ok, I moved -Wkeyword-macro into -pedantic in r224371. I also removed
> > -Wreserved-id-macro in the same revision, as it's not covered by the
> > standards bit you cited
>
> I do not think -Wreserved-id-macro should be removed entirely, but I
> do think it should have a heuristic update before being recommitted,
> and is too chatty to leave in currently.
>
> [global.names] specifies that those names are reserved to the
> implementation, but implementations may require use of them. For
> instance, __need_size_t may need to be #defined before including
> <stddef.h>, and that's valid because the implementer expects that.
> However, __MY_SILLY_HEADER_GUARD__ should not be allowed.
>
> One heuristic which may work would be to make it only trigger on
> header include guards when defining macros and to always trigger on
> nonmacro names (and never in system headers). I'm not certain how
> chatty such a heuristic would be, but it would have less false
> positives than the previous patch did.
>
> FWIW, this can pick out real problems -- I ran into this myself when
> working on tablegenning attribute code, which would accidentally
> create identifiers like foo__bar, which are reserved to the
> implementation.


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141218/61952af2/attachment.html>


More information about the cfe-commits mailing list