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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
