https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |emsr at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |jason at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I guess we should start with whether we preprocessing of the
__has_cpp_attribute and __has_attribute argument is desirable or not.
I've looked at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4200
and whether attribute-token is macro expanded or not is not really clear from
that.
Trying Marek's 1) testcase with normal -E rather than -traditional-cpp, it is
macro expanded in gcc (int i; is in the output), while it is not in clang (at
least 3.5.0).
If we don't want to expand macros, then we'd need to increment
state.prevent_expansion around the processing of the __has*_attribute built-in
macros.
If we do want to expand macros, then I'd say we most likely just don't want to
support it at all in -traditional-cpp mode (i.e. do the n -= 4 thing), because
to me expansion of the arguments looks fundamentally incompatible with the
traditional preprocessing, which works by recursively feeding the result of
macro expansion to the preprocessor again.
So, Ed/Jason, what does C++ intend here?
