Clang complains about concept depending on itself

[craffael]

Version of Clang

clang version 17.0.0 (https://github.com/llvm/llvm-project.git 5b461d5ec172d21029da492064704fe3da6f8bab)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/compiler-explorer/clang-trunk/bin

Steps to reproduce the problem

Try to compile the following program with clang++ main.cpp -std=c++20 -ftemplate-backtrace-limit=0:

#include <type_traits>

template <class OPERATOR>
concept Operator = std::is_nothrow_copy_constructible_v<OPERATOR>;

struct AnyOperator {

  template <Operator OP>
  explicit AnyOperator(OP op) noexcept {}

  /// Copy constructor
  AnyOperator(const AnyOperator&) noexcept = default;
};


static_assert(Operator<AnyOperator>);

It produces the following output (see also Godbolt):

<source>:4:20: error: satisfaction of constraint 'std::is_nothrow_copy_constructible_v<OPERATOR>' depends on itself
concept Operator = std::is_nothrow_copy_constructible_v<OPERATOR>;
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:4:20: note: while substituting template arguments into constraint expression here
concept Operator = std::is_nothrow_copy_constructible_v<OPERATOR>;
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:8:13: note: while checking the satisfaction of concept 'Operator<AnyOperator>' requested here
  template <Operator OP>
            ^
<source>:8:13: note: while substituting template arguments into constraint expression here
  template <Operator OP>
            ^~~~~~~~
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.1/../../../../include/c++/13.0.1/type_traits:3306:7: note: while checking constraint satisfaction for template 'AnyOperator<AnyOperator>' required here
    = __is_nothrow_constructible(_Tp, __add_lval_ref_t<const _Tp>);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.1/../../../../include/c++/13.0.1/type_traits:3306:7: note: in instantiation of function template specialization 'AnyOperator::AnyOperator<AnyOperator>' requested here
<source>:4:25: note: in instantiation of variable template specialization 'std::is_nothrow_copy_constructible_v<AnyOperator>' requested here
concept Operator = std::is_nothrow_copy_constructible_v<OPERATOR>;
                        ^
<source>:4:20: note: while substituting template arguments into constraint expression here
concept Operator = std::is_nothrow_copy_constructible_v<OPERATOR>;
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:16:15: note: while checking the satisfaction of concept 'Operator<AnyOperator>' requested here
static_assert(Operator<AnyOperator>);
              ^~~~~~~~~~~~~~~~~~~~~
<source>:16:1: error: static assertion failed
static_assert(Operator<AnyOperator>);
^             ~~~~~~~~~~~~~~~~~~~~~
<source>:16:15: note: because substituted constraint expression is ill-formed: constraint depends on a previously diagnosed expression
static_assert(Operator<AnyOperator>);
              ^
2 errors generated.

Correct behavior

Clang should accept the code. As far as I know the code is valid. It compiles fine with MSVC and GCC.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[llvmbot]

@llvm/issue-subscribers-c-20

[shafik]

I think this should work but really @erichkeane should take a look

[erichkeane]

I don't see any reason this shouldn't work, that looks right? And I admit the error message doesn't do a great job telling us what went wrong unfortunately. However, can anyone create a min-repro for this for me that doesn't include the include of the type trait? I wonder if the type trait is doing something goofy here.

[erichkeane]

Actually, I got it down to:

template <class OPERATOR>
concept Operator =
  __is_nothrow_constructible(OPERATOR, OPERATOR&);

struct AnyOperator {

  template <Operator OP>
  explicit AnyOperator(OP op) noexcept {}

  AnyOperator(const AnyOperator&) noexcept = default;
};

static_assert(Operator<AnyOperator>);

Unless that builtin has something wacky happening, I don't see the recursion. The code that does just checks to see if we're still in the evaluation of something while being asked to evaluate the same constraint, but I'm not sure where that could have come from.

[craffael]

I can only guess: If your remove the templated constructor it works. So I assume that:

1. We check whether AnyOperator fulfills the Operator concept.
2. I.e. we have to check whether AnyOperator is copy constructible. But for some reason not the copy constructor is selected, but the templated constructor: AnyOperator::AnyOperator<AnyOperator>
3. Now the compiler checks again whether AnyOperator fulfills the Operator concept. Now we are back at step 1 and we have a recursion...

[erichkeane]

AAh, so that builtin DOES cause this problem, and this is a legitimate diagnostic as far as I can tell. If I remove the diagnostic, we hit our template implementation limit.

__is_nothrow_constructible is causing us to evaluate whether AnyOperator is constructible from an AnyOperator, which causes it to have to re-evaluate Operator with AnyOperator (for the constraint on AnyOperator::AnyOperator). I'm not sure how GCC is managing this, unless __is_nothrow_constructible has a way of constructing it without evaluating the constraint on the constructor.

So at the moment, I don't think this is a problem with the concepts stuff, but with that evaluation of the builtin. SO I'm not sure what I can do about it. @shafik : Perhaps its worth looking into that builtin/how GCC behaves with it?

[erichkeane]

I can only guess: If your remove the templated constructor it works. So I assume that:

1. We check whether AnyOperator fulfills the Operator concept.

2. I.e. we have to check whether AnyOperator is copy constructible. But for some reason not the copy constructor is selected, but the templated constructor: `AnyOperator::AnyOperator<AnyOperator>`

3. Now the compiler checks again whether `AnyOperator` fulfills the Operator concept. Now we are back at step 1 and we have a recursion...

Yep! Looks like we simul-posted, thats exactly what is happening. The builtin is effectively doing OPERATOR(OPERATOR&);, which is re-evaluating the constraint on the ctor. So I'm not sure what we can do about that. I still don't know how GCC figures that out, even using the same builtin.

[craffael]

I think the problem is that __is_nothrow_constructible selects the wrong overload. If I write

AnyOperator o = ...; // somehow initialize it
AnyOperator q(o);

then the copy constructor should be selected (and not the template constructor). GCC and Clang (for Clang we must remove the concept constraint) both select the copy constructor, i.e. they are both correct. But __is_nothrow_constructible somehow has problems, respectively seems to use some other logic to make the decision...

[erichkeane]

Hmm... yes, I think thats it. We've somehow decided that our initialization here requires evaluating the template, even though there is already a non-template match. But I don't know our initialization code well enough to know the answer to that. Perhaps there is a missing DR here that we aren't implementing @hubert-reinterpretcast ?