zygoloid wrote:
Hmm. See https://lists.isocpp.org/core/2024/06/15952.php -- I think we should
never be comparing constraints between functions whose signatures aren't
otherwise the same, and in particular we should never compare the constraints
of a conversion function template against the constraints of a conversion
function.
Conversion functions do add another wrinkle here, because we can find them in
different scopes too. For example:
```c++
template<typename T> concept C = true;
template<typename T> concept D = C<T> && true;
template<typename T>
struct A {
operator T() requires C<T>;
};
template<typename U>
struct B {
operator U() requires D<U>;
};
struct X : A<int>, B<int> {};
int n = X();
auto p = &X::operator int;
```
It doesn't make sense to compare the constraints of the conversion functions of
the two templates here, because `T` simply has nothing to do with `U`. (Today,
Clang and MSVC report ambiguity for both `n` and `p`; GCC and EDG accept `n`
but reject `p`.)
That said... an example like the following sidesteps all these issues and still
crashes clang, so I think the above comments are somewhat orthogonal to this
patch (except that I think we should have something like this as a test case
instead of the current test case):
```c++
template<typename T> concept C = true;
template<typename T> concept D = C<T> && true;
struct X {
template<C T> operator T();
template<D T> operator T();
};
auto p = &X::operator int;
```
https://github.com/llvm/llvm-project/pull/98671
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
