The existence of QT_HAS_INCLUDE is a mistake; that fundamentally doesn't work. Instead of trying to work around this mistake in the compiler, you should get Qt to fix their macro. And we should do the same for libc++ where we made the same mistake.

The characters after '__has_include(' have special lexing rules that can't possibly be applied when __has_include is generated by a macro. And this kind of usage will lead to problems such as the one you're seeing here. Per Clang's documentation / SD-6, the correct way to deal with this is:

#ifndef __has_include
#define __has_include(...) 0
#endif

not to define your own wrapper macro.

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.

Thanks for the explanation! I have no idea why Qt or libc++ added another macro so
I will try to submit a patch to Qt remove those uses. I'll also try to do it for libc++.

Should I also open another bug that we should be diagnosing use of __has_include in a macro?

We can repurpose this bug to cover Clang's failure to diagnose __has_include misuse if you prefer. It was pointed out on the C++ core reflector that the code in question is ill-formed per:

http://eel.is/c++draft/cpp.cond#7.sentence-2

(because the __has_include token is not permitted to appear in a #define directive at all.) I've started a discussion in the reflector over exactly which cases should be ill-formed.

*** Bug llvm/llvm-bugzilla-archive#43982 has been marked as a duplicate of this bug. ***

(because the __has_include token is not permitted to appear in a #define
directive at all.) I've started a discussion in the reflector over exactly
which cases should be ill-formed.

I'm going to remove the QT_HAS_INCLUDE macro from Qt and replace it with fallback #define __has_include(...) 0 suggested above.

In Qt we also have similar macro wrappers for:

• __has_builtin
• __has_attribute
• __has_cpp_attribute
• __has_include_next

Are these okey to replace with the same fallback #define?

http://eel.is/c++draft/cpp.cond#7.sentence-2 only mentions __has_cpp_attribute explicitly, but based on https://clang.llvm.org/docs/LanguageExtensions.html it looks like the fallback #define is recommended for them all?

(AFAIK the choice in Qt of a wrapper macro was due to not being sure if it was okey to #define internal/reserved identifiers such as __has_include).

Qt fix in https://codereview.qt-project.org/c/qt/qtbase/+/284037

mentioned in issue llvm/llvm-bugzilla-archive#43982