Wrong unreachable and exhaustiveness warnings for large tuples

[odersky]

Compiler version

3.4.0 RC1

Minimized example

@main def Test =
  val y: (
    Int, Int, Int, Int, Int, Int, Int, Int, Int, Int,
    "Bob", Int, 33, Int,
    Int, Int, Int, Int, Int, Int, Int, Int, Int, Int)
     =
      (0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
      "Bob", 0, 33, 0,
      0, 0, 0, 0, 0, 0, 0, 0, 0, 0)

  y match
    case b @ (x0, x1, x2, x3, x4, x5, x6, x7, x8, x9,
          "Bob", y1, 33, y2,
          z0, z1, z2, z3, z4, z5, z6, z7, z8, z9)
     => // !!! spurious unreachable case warning
      println(y)
    case _ => assert(false)

Output

-- [E030] Match case Unreachable Warning: ../new/test.scala:12:9 ---------------
12 |    case b @ (x0, x1, x2, x3, x4, x5, x6, x7, x8, x9,
   |         ^
   |         Unreachable case
13 |          "Bob", y1, 33, y2,
14 |          z0, z1, z2, z3, z4, z5, z6, z7, z8, z9)

Expectation

If I run the program it does get into the case and print the correct value.

Variant: If I drop the last case case _ => assert(false), I get this instead:

-- [E029] Pattern Match Exhaustivity Warning: ../new/test.scala:11:2 -----------
11 |  y match
   |  ^
   |match may not be exhaustive.
   |
   |It would fail on pattern case: _: *:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[("Bob" : String),*:[Int,*:[(33 : Int),*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,*:[Int,Tuple$package.EmptyTuple]]]]]]]]]]]]]]]]]]]]]]]]
   |
   | longer explanation available when compiling with `-explain`

[odersky]

This will be a huge problem for named tuples. Previously very few people would write a large tuple pattern like this. But with named tuple patterns, all it takes is:

case (name = "Bob", age = a) 

and the wrong unreachable warning will also pop up.

[odersky]

Another variant: There's no need to actually match on a tuple element. The following will also issue the wrong warning even though the tuple consists only of pattern variables.

  y match
    case (x0, x1, x2, x3, x4, x5, x6, x7, x8, x9,
          y0, y1, y2, y3,
          z0, z1, z2, z3, z4, z5, z6, z7, z8, z9)

[dwijnand]

When I (or anyone else) gets to this, then I think also #16186, #16657, and #14588 are either straight duplicates or closely related.

[bishabosha]

is this fixed by #19085 ?

[odersky]

No, it's independent.

[scala-center-bot]

This issue was picked for the Issue Spree No. 40 of December 5th, 2023 which takes place in 6 days. @dwijnand, @natsukagami, @iusildra will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

[dwijnand]

Found some of my notes in #14588 (comment)

We were able to find an initial, quickfix, for reachability, by special casing TupleXXL in isSubType:

    else tp2 match
      case tp2: TypeRef if tp2.symbol == defn.TupleXXLClass && tp1.tupleElementTypes.isDefined => true // arity?
      case _ => tp1 <:< tp2

Necessary because TypeComparer doesn't consider 23 ints to be a subtype of TupleXXL (which the pattern is typed as).

Unfortunately that doesn't help exhaustivity. In exhaustivity we try to calculate the Space of values that remains once all case patterns are considered. Using the test case in #16657, the pattern uses TupleXXL.unapplySeq, and is type cast to TupleXXL, which means that statically we're using a variadic extractor. We've suppressed the precise type of the pattern (with 23 bindings) which would precisely match the arity of the scrutinee (23 ints), so the SpaceEngine is doomed on exhaustivity. So we can either special case more, or try to fix this upstream, so that the abstraction is maintained and doesn't leak here.