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

[Richard Smith]

On Wed, Dec 17, 2014 at 4:03 PM, Reid Kleckner <rnk at google.com> wrote:
>
> On Tue, Dec 16, 2014 at 1: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 would like to have something like -Wreserved-id-macro eventually, but
> it's really hard to differentiate between uses of internal C++
> implementation details (calling __builtin_foo()) and user defined names
> that are not part of "the implementation" (compiler + stdlib). This is
> partially covered by the C++ standard in [global.names]p1:
>
> """
> Certain sets of names and function signatures are always reserved to the
> implementation:
> — Each name that contains a double underscore _ _ or begins with an
> underscore followed by an uppercase
> letter (2.12) is reserved to the implementation for any use.
> — Each name that begins with an underscore is reserved to the
> implementation for use as a name in the
> global namespace.
> """
>
> It says nothing about macros, though, and this is such a hard problem that
> it's not clear to me that the committed implementation is worth having.
>

"for any use" is intended to include "for use as a macro".

For reserved identifiers, I think a reasonable heuristic might be:

* declaring any (non-macro) entity with a reserved identifier gets a warning
* using any such entity does not get a warning
* #defining a macro with a reserved name does not get a warning (we assume
it's being used to configure a system header)
* expanding a macro with a reserved name gets a warning *unless* the macro
was defined in a system header

So: you can define reserved names as macros to parameterize system headers,
and system headers can give you macros with reserved names for you to use,
but you can't use macros with reserved names for your own internal purposes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141218/8e7d047c/attachment.html>