Pattern Match Exhaustivity Error: 3.3.7-RC1

[He-Pin]

Compiler version

3.3.7-RC1

Minimized code

https://github.com/apache/pekko/actions/runs/17338073097/job/49227565939?pr=2104#step:7:729

      .map {
        case (`passedEnd`, r: U @unchecked) => (thisElem, r)
        case (l: A @unchecked, `passedEnd`) => (l, thatElem)
        case t: (A, U) @unchecked           => t
      }

Output

[error] -- [E029] Pattern Match Exhaustivity Error: /home/runner/work/pekko/pekko/stream/src/main/scala/org/apache/pekko/stream/scaladsl/Flow.scala:3234:8 
[error] 3234 |        case (`passedEnd`, r: U @unchecked) => (thisElem, r)
[error]      |        ^
[error]      |        match may not be exhaustive.
[error]      |
[error]      |        It would fail on pattern case: (_, _)

Expectation

1. no warning, because thecase t:(A,U) will match other cases

[He-Pin]

@tgodzik FYI

[tgodzik]

Thanks for reporting! That's under fatal warnings, right?

[tgodzik]

Looks like the issue is with https://github.com/scala/scala3-lts/pull/275/files I don't remember why I adjusted the test case, might have been due to similar changes that needed such workarounds.

We need to check if we can fix that in the LTS or remove the backport.

[He-Pin]

I have adjusted the case with

    case _                            => throw new RuntimeException() // compiler exhaustiveness check pleaser

But this code should be ok

[sjrd]

Ideally, this shouldn't make it into an LTS, indeed.

However, I don't think the new warning is erroneous. The pattern introduces type tests with : A and : U. From the type system's point of view (and hence as far as exhaustivity checking is concern), these can fail. So you can fall into unhandled cases with values that are not As and Us.

The fact that these are unchecked and uncheckable is irrelevant. That is an entirely different promise. Recall that @unchecked in patterns is essentially an asInstanceOf, except it wants to disguise itself in a more "noble" cloak. It is usually more honest, and safer, to write explicit asInstanceOfs on the right-hand-side instead. It avoids misleading the reader. (And if you do that here, you won't have the warnings anymore.)