Clang wrongly instantiates the `operator==` of a type with defaulted `operator==` despite its requires false

[AMP999]

According to a discussion on cpplang.slack.com , apparently, there is a bug in clang which causes the "PROBLEM" code (using =default) to be instantiated, despite its requires false.

https://godbolt.org/z/crcbr6xGz
GCC accepts this example; Clang and MSVC reject.

arthur-odwyer(@Quuxplusone):
(attn
@Nikolas Klauser
)
Where would we have to modify in the standard to get this to work as intended?
https://godbolt.org/z/nc4Kv3TT6
template
struct S {
Holder h;

#if PROBLEM
friend bool operator==(const S& s, const S& t)
requires false = default;
#else // NO PROBLEM
friend bool operator==(const S& s, const S& t)
requires false { return s.h == t.h; }
#endif
};
The "NO PROBLEM" code is quite properly never instantiated for any T, because it requires false; but the "PROBLEM" code (using =default) is instantiated, despite its requires false. Why does this happen, and can we make it not happen?

Brian Bi(@t3nsor):
I think that might be a bug in Clang. [temp.inst]/5 says that a friend function definition isn't supposed to be instantiated until "it is referenced in a context that requires a function definition to exist or if the existence of the definition affects the semantics of the program".

[llvmbot]

@llvm/issue-subscribers-clang-frontend