[clang] Satisfaction of constraint depends on itself for type with single-argument constructor

[davidstone]

The following translation unit

template<typename LHS, typename RHS>
concept c = requires(LHS lhs, RHS rhs) { f(lhs, rhs); };

struct unconstrained {
	template<typename T>
	friend void f(unconstrained, T);
};

struct constrained {
	explicit constrained(int = 0);

	template<typename T> requires c<int, T>
	friend void f(constrained, T);
};

void g() {
	f(unconstrained(), constrained());
}

is rejected by clang with

<source>:12:32: error: satisfaction of constraint 'c<int, T>' depends on itself
   12 |         template<typename T> requires c<int, T>
      |                                       ^~~~~~~~~
<source>:12:32: note: while substituting template arguments into constraint expression here
   12 |         template<typename T> requires c<int, T>
      |                                       ^~~~~~~~~
<source>:2:42: note: while checking constraint satisfaction for template 'f<constrained>' required here
    2 | concept c = requires(LHS lhs, RHS rhs) { f(lhs, rhs); };
      |                                          ^
<source>:2:42: note: while substituting deduced template arguments into function template 'f' [with T = constrained]
<source>:2:42: note: in instantiation of requirement here
    2 | concept c = requires(LHS lhs, RHS rhs) { f(lhs, rhs); };
      |                                          ^~~~~~~~~~~
<source>:2:13: note: while substituting template arguments into constraint expression here
    2 | concept c = requires(LHS lhs, RHS rhs) { f(lhs, rhs); };
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:12:32: note: while checking the satisfaction of concept 'c<int, constrained>' requested here
   12 |         template<typename T> requires c<int, T>
      |                                       ^~~~~~~~~
<source>:12:32: note: while substituting template arguments into constraint expression here
   12 |         template<typename T> requires c<int, T>
      |                                       ^~~~~~~~~
<source>:17:2: note: while checking constraint satisfaction for template 'f<constrained>' required here
   17 |         f(unconstrained(), constrained());
      |         ^
<source>:17:2: note: while substituting deduced template arguments into function template 'f' [with T = constrained]
<source>:17:2: error: no matching function for call to 'f'
   17 |         f(unconstrained(), constrained());
      |         ^
<source>:6:14: note: candidate function [with T = constrained]
    6 |         friend void f(unconstrained, T);
      |                     ^
<source>:13:14: note: candidate template ignored: constraints not satisfied [with T = constrained]
   13 |         friend void f(constrained, T);
      |                     ^
2 errors generated.
Compiler returned: 1

See it live: https://godbolt.org/z/sn1bbq6Kz

Removing the constructor on line 10 removes the error message.

It seems that clang is instantiating the friend function template f from line 12 with constrained as T, and then before realizing that unconstrained cannot convert to constrained it tries to evaluate the concept which then attempts to instantiate this same function template.

The error message also goes on to say that there is no matching function for call to f, even though it lists the function template on line 5 (which is valid and is expected to be called) as a candidate.

This code is accepted in clang 20.1.0.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: David Stone (davidstone)

The following translation unit

template<typename LHS, typename RHS>
concept c = requires(LHS lhs, RHS rhs) { f(lhs, rhs); };

struct unconstrained {
	template<typename T>
	friend void f(unconstrained, T);
};

struct constrained {
	explicit constrained(int = 0);

	template<typename T> requires c<int, T>
	friend void f(constrained, T);
};

void g() {
	f(unconstrained(), constrained());
}

is rejected by clang with

<source>:12:32: error: satisfaction of constraint 'c<int, T>' depends on itself
   12 |         template<typename T> requires c<int, T>
      |                                       ^~~~~~~~~
<source>:12:32: note: while substituting template arguments into constraint expression here
   12 |         template<typename T> requires c<int, T>
      |                                       ^~~~~~~~~
<source>:2:42: note: while checking constraint satisfaction for template 'f<constrained>' required here
    2 | concept c = requires(LHS lhs, RHS rhs) { f(lhs, rhs); };
      |                                          ^
<source>:2:42: note: while substituting deduced template arguments into function template 'f' [with T = constrained]
<source>:2:42: note: in instantiation of requirement here
    2 | concept c = requires(LHS lhs, RHS rhs) { f(lhs, rhs); };
      |                                          ^~~~~~~~~~~
<source>:2:13: note: while substituting template arguments into constraint expression here
    2 | concept c = requires(LHS lhs, RHS rhs) { f(lhs, rhs); };
      |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:12:32: note: while checking the satisfaction of concept 'c<int, constrained>' requested here
   12 |         template<typename T> requires c<int, T>
      |                                       ^~~~~~~~~
<source>:12:32: note: while substituting template arguments into constraint expression here
   12 |         template<typename T> requires c<int, T>
      |                                       ^~~~~~~~~
<source>:17:2: note: while checking constraint satisfaction for template 'f<constrained>' required here
   17 |         f(unconstrained(), constrained());
      |         ^
<source>:17:2: note: while substituting deduced template arguments into function template 'f' [with T = constrained]
<source>:17:2: error: no matching function for call to 'f'
   17 |         f(unconstrained(), constrained());
      |         ^
<source>:6:14: note: candidate function [with T = constrained]
    6 |         friend void f(unconstrained, T);
      |                     ^
<source>:13:14: note: candidate template ignored: constraints not satisfied [with T = constrained]
   13 |         friend void f(constrained, T);
      |                     ^
2 errors generated.
Compiler returned: 1

See it live: https://godbolt.org/z/sn1bbq6Kz

Removing the constructor on line 10 removes the error message.

It seems that clang is instantiating the friend function template f from line 12 with constrained as T, and then before realizing that unconstrained cannot convert to constrained it tries to evaluate the concept which then attempts to instantiate this same function template.

The error message also goes on to say that there is no matching function for call to f, even though it lists the function template on line 5 (which is valid and is expected to be called) as a candidate.

This code is accepted in clang 20.1.0.

[shafik]

CC @cor3ntin @erichkeane

gcc also rejects, but edg/MSVC accept: https://godbolt.org/z/6PK8GbqWM

[cor3ntin]

I think this is expected from https://cplusplus.github.io/CWG/issues/2369
Previously, we would check the arguments before checking the constraint; now we do the opposite.
We did implement some mitigation for when the potential conversion sequence is not a template (as described https://isocpp.org/files/papers/P3606R0.html#addendum-cwg2369-and-recursive-constraint-checks).

It's not 100% clear to me why the constructor is load-bearing, but I suspect we decide that without a constructor, there cannot be a conversion sequence. @zyn0217

[davidstone]

The real-world code this came from for me is that I want a class template, wrapper<T>, that is equality comparable with U iff T is equality comparable with U. That seems reasonable to me and probably a fairly common pattern. With this change, a function that will definitely not be called is causing this error and the only way I've found to work around it is to stop using concepts and use SFINAE on the return type of my operator== (f in this example).

[zyn0217]

This is an unfortunate fallout of CWG2369, as Corentin had pointed out.

The keypoint that makes our behavior peculiar is that we're trying to mimic GCC's workaround for certain breakages, without which we would break much more real world use cases and that would essentially defeat the feature.

The workaround is, in short, before we check the constraint that now happens before substitution, we first check the non-dependent conversions of the function parameters. And that is where the magic happens: If we can realize that there is no user-defined conversion from the argument to the parameter, then we bail out of the overload resolution of that function. This helps us evade many of the self-dependent errors.

The criteria of checking non-user defined conversions is pretty arbitrary at the moment (GCC first figured out these and we have to follow them in the end).Since diving into the user-defined conversion risks triggering unwanted instantiations that should have been otherwise ruled out by constraints, which again defeats the feature, we rely on a very simple heuristic:

If the type of parameter has a converting constructor, then we assume there will occur such a conversion and thus we stop the heuristic and continue to check the constraints, which will surface errors in the end as you can see here.

GCC had a similar limitation, who used to only allow aggregate types to hijack the constraint checking, which makes its behavior even funny before:

https://godbolt.org/z/5TM1sT8ns

And they have improved that on trunk recently, which I think we (clang and GCC) should agree for most cases now.

Still, it's very very unfortunate that something as simple as a converting constructor breaks everything so badly. However I think it's the best we can do so far, unless someone can figure out more clever solutions.

@zygoloid

[zygoloid]

There's no converting constructor here -- the constrained constructor is declared explicit. Perhaps Clang's missing a check for that?

[zygoloid]

I also wonder if the "perfect match" logic could be modified to help here. The other friend would be a perfect match (and the problematic friend would not); can we detect that before we do any constraint checks?