[PATCH] D49067: Stop wrapping __has_include in another macro

[Alexander Richardson via Phabricator via cfe-commits]

arichardson added a comment.

In https://reviews.llvm.org/D49067#1172500, @EricWF wrote:

> Where are the special lexing rules specified?




In  https://bugs.llvm.org/show_bug.cgi?id=37990#c1 @rsmith wrote:

> The C++ standard appears to be missing a rule that says that a __has_include token produced by macro expansion results in undefined behavior (matching the corresponding rule for a 'defined' token produced by macro expansion), but that seems to just be a wording oversight. You should not expect this to work.


Looks like the special rules are explained in 3.2.2 of https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#recs.hasinc

> In the first form of the has-include-expression, the parenthesized header-name token is not subject to macro expansion. The second and third forms are considered only if the first form does not match, and the preprocessing tokens are processed just as in normal text.

While there is no mention of the define to 0 if not present for `__has_include` it is used in the example for `__has_cpp_attribute` in https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#recs.hasattr.



================
Comment at: include/__config:153
+#ifndef __has_include
+#define __has_include(...) 0
 #endif
----------------
EricWF wrote:
> I do prefer not hijacking this name, but if it's needed to make things work, then it's OK with me.
> 
> @mclow.lists Are you OK if we steal this identifier and `#define` it ourselves.
This is the correct way of dealing with missing `__has_include()` according to @rsmith


Repository:
  rCXX libc++

https://reviews.llvm.org/D49067