Bogus "constraint depends on itself"

[Boris-Rasin]

#include <concepts>

struct A
{
    template <typename X>
        requires requires (A a) { func1<X>(a); }
    operator X() const
    {
        return {};
    }
};

template <std::same_as<bool> T>
void func1(int) {}

template <std::same_as<bool> T>
void func1(A) {}

int main()
{
    A a;
    bool b = a;
    
    return 0;
}

Clang 20.1.0
-std=c++20

Compiler Explorer:
https://godbolt.org/z/or9eh7bax

This works with gcc and msvc, but fails with clang:

<source>:6:18: error: satisfaction of constraint 'requires (A a) { func1<X>(a); }' depends on itself

Instantiating func1<int>() fails, but clang still tries to match the function parameter, as if func1<int>(int) instantiated successfully.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Boris Rasin (Boris-Rasin)

```cpp #include <concepts>

struct A
{
template <typename X>
requires requires (A a) { func1<X>(a); }
operator X() const
{
return {};
}
};

template <std::same_as<bool> T>
void func1(int) {}

template <std::same_as<bool> T>
void func1(A) {}

int main()
{
A a;
bool b = a;

return 0;

}

Clang 20.1.0
-std=c++20

Compiler Explorer:
https://godbolt.org/z/or9eh7bax

This works with gcc and msvc, but fails with clang:

<source>:6:18: error: satisfaction of constraint 'requires (A a) { func1<X>(a); }' depends on itself

Instantiating func1<int>() fails, but clang still tries to match the function parameter, as if func1<int>(int) instantiated successfully.
</details>

[shafik]

Interesting edg also produces the same diagnostic: https://godbolt.org/z/cW9eafGhP

I am not sure what is going on here CC @erichkeane @cor3ntin

[shafik]

May be a dup of: #62096

[erichkeane]

It looks like we are doing this while evaluating the foo1(int) variant. Evaluating func1<X>(a); means we're trying to do overload resolution there to make sure we've got a valid one, which requires checking constraints.

Since one of the variants of func1 requires a conversion operator, we again have to evaluate the operator bool, so it depends on itself. If you remove the func1(int) version it obviously passes.

This is perhaps similar ot work that @cor3ntin did on overload resolution. I wonder if the other compilers are doing a check of "is this an exact match" for the func1(A) variant, and skipping the rest of overload resolution.

I can't quote standard, but I THINK our behavior is standards complaint.

[Boris-Rasin]

First, compiler has to check if func1<bool>(int) can be called.

It successfully instantiates func1<bool>(int) function, then checks if A can be sent as parameter, i.e. A can be converted to int.

For this, compiler needs to check if func1<int> can be called with A as a parameter.

Compiler FAILS to instantiate func1<int> and should have stopped here, threw out func1<bool>(int) overload and went with func1<bool>(A) as the only option left.

Instead, compiler at this point tries to check conversion of A to int again, leading to "constraint depends on itself".

Why?

Instantiation of func1<int> failed, there is no function func1<int>(int).

[md5i]

I am noticing a very similar problem in another bit of code.

#include <concepts>
#include <ranges>

struct Foo : std::ranges::view_interface<Foo> {
  using iterator = char const *;
  Foo(Foo &&) = default;
  Foo & operator=(Foo const & other) = default;
  Foo & operator=(Foo && other) = default;
  [[nodiscard]] iterator begin() const noexcept {
    return nullptr;
  }
  [[nodiscard]] iterator end() const noexcept {
    return nullptr;
  }

  template <typename T>
  requires (
//    !std::derived_from<T, Foo> &&
    std::ranges::contiguous_range<T>
    && std::move_constructible<T>)
  Foo(T && x) {
  }
};

static_assert(std::ranges::contiguous_range<Foo>);

int main()
{
}

Compiler Explorer: https://godbolt.org/z/G7cozonbM

Is this the same problem, or should I submit a new bug report? Please note, if the commented line is un-commented, the problem disappears. In this case, I feel as if this should not be generating an error. Even if there is a failure attempting to pseudo-instantiate the second constructor with T as Foo, shouldn't it accept the copy or move constructors as a better match given that they are non-templated?

[md5i]

It looks like my case is covered by PR #136203

[zyn0217]

Will be fixed by b32afd2