Recursion limit exceeded error on mutual type member constraints

[pityka]

Compiler version

3.4.1

Minimized code

The following code fails on scala3 with a strange error message but compiles on scala2.

sealed trait Foo  { self =>
  type B <: Bar {
    type B = self.B
  }
}

sealed trait Bar { self =>
  type F <: Foo  {
    type B = self.B
    type F = self.F
  }
  type B <: Bar {
    type F = self.F
  }
}

Output

❯ scala-cli compile -S 3.4.1 proto.scala
Compiling project (Scala 3.4.1, JVM (17))
[error] ./proto.scala:4:13
[error] Recursion limit exceeded.
[error] Maybe there is an illegal cyclic reference?
[error] If that's not the case, you could also try to increase the stacksize using the -Xss JVM option.
[error] For the unprocessed stack trace, compile with -Yno-decode-stacktraces.
[error] A recurring operation is (inner to outer):
[error]
[error] find-member Bar#B
[error] find-member Bar#F
[error] find-member Bar#B
[error] find-member Bar#F
[error] find-member Bar#B
[error] find-member Bar#F
[error] find-member Bar#B
[error] find-member Bar#F
[error] find-member Bar#B
[error] find-member Bar#F
[error] ...
[error]
[error] find-member Bar#B
[error] find-member Bar#F
[error] find-member Bar#B
[error] find-member Bar#F
[error] find-member Bar#B
[error] find-member Bar#F
[error] find-member Bar#B
[error] find-member Bar#F
[error] find-member Bar#B
[error] find-member Bar#F
[error] type B <: Bar {
[error] ^

Expectation

Compiles with 2.13.13

❯ scala-cli compile -S 2.13.13 proto.scala
Compiling project (Scala 2.13.13, JVM (17))
Compiled project (Scala 2.13.13, JVM (17))

I would expect either to compile in both scala3 and scala2 or in none of them. I failed to identify any of the dropped features from scala3 which could relate to this.

If it is per specification that this should not compile on scala3 then a more helpful error message would be reassuring. The current error message leaves the user in doubt whether this is a bug in the compiler or an illegal program.

[pweisenburger]

This is another instance of the problem that would be addressed by #20236. So for now I still hope, we can get this fixed.