Invalid unreachable case warning on Java-defined class with unbounded type parameter

[Arthurm1]

Compiler version

3.1.3

Minimized code

object TestMatch extends App {
  def getValues: Object = {
    val x = new java.util.Vector[Double]()
    x.add(1.0)
    x
  }
  val x = getValues
  x match {
    case l: java.util.Vector[_] =>
      l.get(0) match {
        case d: Double => println(s"got first $d") // unreachable case warning
        case _ => println("shrug")
      }
  }
  x match {
    case l: java.util.Vector[_] =>
      l.get(0) match {
        case d: Double => println(s"got second $d") // no warning
      }
  }
}

Output

unreachable case warning on line indicated with comment

Expectation

Running the app shows that the case is used so I'd expect no warning.

The second match statement doesn't have a warning for case d: Double so why does the first?

I get the correct warnings if getValues is not returned as Object.

I don't think this is the same as other open unreachable case issues. It doesn't involve unions or nulls

[SethTisue]

Nice catch! Thanks for the report.

Also reproduces on latest nightly.

Presumably it's crucial that java.util.Vector is Java-defined and thus there's confusion about whether the relevant top type is Any or AnyRef.

[SethTisue]

The nested pattern match isn't needed; the following is a sufficient reproducer:

def foo(xs: java.util.Vector[_]): Unit =
  xs.get(0) match {
    case d: Double =>
    case _ =>
  }

(A second case is needed in order for redundancy checking to kick in.)

[SethTisue]

Note that you get the same unreachable warning if you change the type of xs to java.util.Vector[AnyRef]. But in Scala 2 if you make that change, the compiler rejects the code outright ("pattern type is incompatible with expected type").

(Dale believes this was an intentional design change in Scala 3, but we're not sure if there's a ticket or discussion of record on that. But the long comment at the top of PatternTypeConstrainer.scala is useful background.)

[SethTisue]

Maybe it's “simply” that the redundancy checker “just” needs to be made to handle FromJavaObject properly, here? (See the long comment on FromJavaObjectSymbol in Definitions.scala for a crash course on FromJavaObject.)

We've verified that an upper bound of FromJavaObject is, as hoped/expected, reaching the redundancy checker as input. (Note that FromJavaObject ordinarily prints as Object, which is frustrating when you care about the difference; isFromJavaObject can be used to distinguish.)

[SethTisue]

Indeed, it was actually that simple. The right FromJavaObject logic already existed in subtype checking (in firstTry in TypeComparer), and we added the same logic to provablyDisjoint. The PR (#15769) includes both the test case from this report, and an inverted version of it where it's the pattern type rather than the scrutinee type that's FromJavaObject.