Type inference bug for type member based on a dependent type

Compiler version

3.0.0

Minimized code

trait X:
  type Out
  def value: Out

class XWrapper[XX <: X](val x: XX):
  type Out = x.Out

object XWrapper:
  type Aux[T, U] = XWrapper[T] { type Out = U }

def getValue[XX <: X, U](y: XWrapper.Aux[XX, U]): U =
  y.x.value

Output

Compilation error:

Found:    y.x.Out
Required: U
    y.x.value

Expectation

The compiler should know that y.x.Out and U are the same type

[smarter]

Both X and XWrapper have a member called Out, but they’re not the same member. Let’s give them their own name to make things clearer:

trait X:
  type A
  def value: A

class XWrapper[XX <: X](val x: XX):
  type B = x.A

object XWrapper:
  type Aux[T <: X, U] = XWrapper[T] { type B = U }

  def getValue[XX <: X, U](y: XWrapper.Aux[XX, U]): U =
    y.x.value

-- [E007] Type Mismatch Error: try/i12886.scala:12:8 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
12 |    y.x.value
   |    ^^^^^^^^^
   |    Found:    y.x.A
   |    Required: U

Here I think it’s clear that the issue is that A does not match U, the value of B doesn’t matter since y.x has type y.x.A.

[smarter]

When the compiler checks y.x.A <: U, U isn’t constrained (it’s declared as just U without bounds in def getValue[XX <: X, U]), the fact that U has to be equal to y.x.A is something that can be derived from the fact that it appears as the rhs of B and that B is already defined to be equal to x.A, but that’s a very indirect complex reasoning the compiler isn’t going to perform.