Clang doesn't SFINAE out constrained overload when substitution-failure happens in template-head

[cjdb]

GCC test concepts-defarg2.C fails in Clang. I'm not sure if GCC should be accepting the original lines, but Clang gets suspicious when I uncomment my addition (which I don't think should be failing).

// PR c++/97052
// RUN: %clang_cc1 -std=c++20 -fsyntax-only -verify %s

template<typename T, typename U = typename T::type>
concept C = true;

constexpr bool f(C auto) {
  return true;
}

// added by me
// constexpr bool f(auto) {
//   return true;
// }

static_assert(f(0));

C auto x = 0;

Diagnostics prior to uncommenting:

<source>:16:15: error: no matching function for call to 'f'
static_assert(f(0));
              ^
<source>:7:16: note: candidate template ignored: constraints not satisfied [with auto:1 = int]
constexpr bool f(C auto) {
               ^
<source>:4:44: note: because substituted constraint expression is ill-formed: type 'int' cannot be used prior to '::' because it has no members
template<typename T, typename U = typename T::type>
                                           ^
<source>:4:44: error: type 'int' cannot be used prior to '::' because it has no members
template<typename T, typename U = typename T::type>
                                           ^
note: in instantiation of default argument for 'C<int>' required here

Diagnostics after uncommenting:

<source>:4:44: error: type 'int' cannot be used prior to '::' because it has no members
template<typename T, typename U = typename T::type>
                                           ^
note: in instantiation of default argument for 'C<int>' required here

[llvmbot]

@llvm/issue-subscribers-c-20

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[shafik]

Based on the examples in temp.deduct p5 I think clang is not correct here.

CC @erichkeane

[erichkeane]

Interestingly, temp.deduct p5 is from a different bug report, so did you mean to respond to this one?

In this case, it seems to me that Clang is 'correct' in the as-done: I don't know how we're supposed to pick a template parameter for 'U' without looking at T::type (though, I DO know we don't implement parameter mapping for constraint evaluation, so perhaps that is supposed to happen here?).

After the 'added', we're left over with just the definition of 'x', which DOES require instantiation of C, but again, this might be the parameter mapping stuff that @zygoloid was discussing on the EWG mailing list.

[zygoloid]

Yes, this looks like the lack of parameter mapping / lazy parameter substitution during satisfaction checking.

[alexolog]

This looks like https://bugs.llvm.org/show_bug.cgi?id=50864, open 3 years ago.

Any progress on it? According to Compiler Explorer it fails on trunk.

[cor3ntin]

@zygoloid @hubert-reinterpretcast What's the historical reason for not basing satisfaction checking on the normalized form of the constraint?

[zygoloid]

@cor3ntin I'm not sure I understand what you're asking. Per the standard, satisfaction checking is supposed to be done on the normalized form of the constraint. In this case it looks to me like we should get an error during normalization, regardless of whether the second declaration is commented out.

[cor3ntin]

@cor3ntin I'm not sure I understand what you're asking. Per the standard, satisfaction checking is supposed to be done on the normalized form of the constraint. In this case it looks to me like we should get an error during normalization, regardless of whether the second declaration is commented out.

I'm asking if there was a specific reason we don't. Satisfaction checking is an entirely different code path from normalization, which seems to be both more complicated and also incorrect, so I am asking if there was a reason why we did it that way or if it's just accidental.