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

> 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: [lahodaj at 108e5af](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!

Thanks! My feeling here is still that this is complementary to inference fixes, as long as there's a `} catch (Infer.InferenceException ex) {` I think it's worth considering treating that case conservatively, i.e. not assuming a switch is exhaustive if inference throws an exception.

If it's possible to ensure inference never throws an exception that needs to be caught that would also be good, and avoids this.

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

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