RFR: 8347291: Exhaustive switch over a generic sealed abstract class [v2]

[Liam Miller-Cushon]

On Sun, 6 Apr 2025 04:52:12 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change avoids javac incorrectly reporting switches like the example in [JDK-8347291](https://bugs.openjdk.org/browse/JDK-8347291) as exhaustive.
>> 
>> As Jan noted in the bug it seems like the inference behaviour here may not be correct. If it was able to infer a type without crashing that would also avoid the bug.
>> 
>> However with the current inference behaviour, it's safer to assume that if inference crashes the subtype may need to be handled by the switch, instead of assuming that it doesn't.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Handle error types in InferenceUnitTest
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - Merge remote-tracking branch 'origin/master' into JDK-8347291
>  - 8347291: Exhaustive switch over a generic sealed abstract class

> Feel free to ask for assistance if you need help with progressing this pull request towards integration!

Any thoughts on this? To me false positives in exhaustiveness checking seem a lot worse than false negatives, and the principled fix to inference to avoid the crash seems like it's going to be more challenging. I think in the short term there's a argument for making this change, so in the rare cases where this comes up the switches need an explicit `default:` instead of getting an unexpected MatchException.

But if this is too hacky, and there's a preference for leaving this alone until there's time to fix the inference crash, that's fine and I can drop the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23286#issuecomment-2794194020