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

Jan Lahoda jlahoda at openjdk.org
Thu Apr 10 16:43:35 UTC 2025


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

IIRC, I was looking into this when this came up. I think when I was debugging, there seemed to be incorrectly sorted bounds sent to intersection type, which then broke the rest of the inference machinery. I've had this:
https://github.com/lahodaj/jdk/commit/108e5afa2bca60c5ae9b1270c23865aa615bfe52

But I think, at that time, the idea was to take a better look at the (pattern) inference as a whole.

@mcimadamore - any insights? Thanks!

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

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


More information about the compiler-dev mailing list