Upper bound lost from Int to Any on Scala 3.1.2 and later

[soronpo]

Pretty weird error. It disappears when removing the clue parameter from check.

Compiler version

3.1.1 - compiles
3.1.2 and later - compilation error

Minimized code

import compiletime.ops.int.Max

trait DFSInt[W <: Int]
trait Candidate[R]:
  type OutW <: Int
object Candidate:
  given [W <: Int, R <: DFSInt[W]]: Candidate[R] with
    type OutW = W

def foo[R](rhs: R)(using icR: Candidate[R]): DFSInt[Max[8, icR.OutW]] = ???

object Test:
  def check[A](a: A, clue: Int = 1): Unit = ???
  val x: DFSInt[8] = ???
  check(foo(x))

Output

Type argument Any does not conform to upper bound Int in subpart compiletime.ops.int.Max[(8 : Int), Any] of inferred type 
  Playground.DFSInt[?
     >: compiletime.ops.int.Max[(8 : Int), Any] & (8 : Int) <: 
      compiletime.ops.int.Max[(8 : Int), Any]
     | (8 : Int)
  ]

Expectation

Should compile.

[soronpo]

First bad nightly: 3.1.2-RC1-bin-20211217-b3ab102-NIGHTLY

[Kordyjan]

@soronpo You have mentioned elsewhere that this issue manifested to you as you bumped the compiler version from 3.3.0 to 3.3.1-RCx. Did it happen in https://github.com/DFiantHDL/DFiant or another project? Which branch was that? I wanted to investigate what exactly changed between 3.3.0 and 3.3.1-RCx.

BTW. Since there is at least one released version on Maven Central, DFiant will be part of the Open CB starting this weekend, so new regressions will be detected (and even bisected) automatically.

[soronpo]

@Kordyjan Thank you for looking into this. I'm hesitant on putting the library in the OpenCB since it's still a WIP, but I see the benefit since it's a regression magnet 😄. I created a branch that will be stable for the community build: scala_opencb
https://github.com/DFiantHDL/DFiant/tree/scala_opencb

Locally just check out the branch and run sbt test. You should see the tests pass.
If you update to 3.3.1-RC5, you will hit issue #18171, so until that is backported you won't be seeing the other issues that I mentioned like this one and #18263. You can see them if you use the 3.3.2-nightly release. I hope this makes things clearer.

[SethTisue]

Dale and I are digging into this, at least experimentally. No idea yet what a fix might look like.

Here's the test code minimized a bit further:

import scala.compiletime.ops.int.Max

trait Foo[A]
trait Bar[B]:
  type Out <: Int
object Bar:
  given inst[C <: Int]: Bar[C] with
    type Out = C

class Test:
  def mkFoo(using bx: Bar[2]): Foo[Max[1, bx.Out]] = ???
  def check[Y](yy: Y, clue: Int = 1): Unit = ()

  def test: Unit = check(mkFoo)

it's a bit less noisy, but all the big pieces are still there, despite our best efforts 😕

[SethTisue]

Note that a default getter always has all the same type parameters as the method it comes from, even if they aren't used. So the getter for clue has the type parameter Y. So that helps explain why the default argument is even relevant here.

[soronpo]

Note that a default getter always has all the same type parameters as the method it comes from, even if they aren't used. So the getter for clue has the type parameter Y. So that helps explain why the default argument is even relevant here.

Oh, finally it make some sense. I was really surprised when I got this minimization.