RFR: 8364991: Incorrect not-exhaustive error

Chen Liang liach at openjdk.org
Mon Sep 29 15:35:40 UTC 2025


On Fri, 12 Sep 2025 07:53:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider this code:
> 
> $ cat Test.java
> package test;
> public class Test {
>     private int test1(Root r) {
>         return switch (r) {
>             case Root(R2(R1 _), R2(R1 _)) -> 0;
>             case Root(R2(R1 _), R2(R2 _)) -> 0;
>             case Root(R2(R2 _), R2(R1 _)) -> 0;
>             case Root(R2(R2 _), R2 _) -> 0;
>         };
>     }
>     sealed interface Base {}
>     record R1() implements Base {}
>     record R2(Base b1) implements Base {}
>     record Root(R2 b2, R2 b3) {}
> }
> 
> 
> javac (JDK 25) will produce a compile-time error for this code:
> 
> $ javac test/Test.java
> .../test/Test.java:4: error: the switch expression does not cover all possible input values
>         return switch (r) {
>                ^
> 1 error
> 
> 
> This error is not correct according to the JLS. JLS defines a set of possible reductions of pattern sets, and if there exists a series of reductions from the pattern set into a pattern set that covers the selector type, the switch is exhaustive.
> 
> One such reduction is that if there's a sub-set of (record) patterns that only differ in one component ("the mismatching component"), we can replace them with a (set of) patterns where this component is reduced, and the other components are unmodified.
> 
> Such path exists here (every line shows a set of patterns that is being transformed):
> 
> Root(R2(R1 _), R2(R1 _)), Root(R2(R1 _), R2(R2 _)), Root(R2(R2 _), R2(R1 _)), Root(R2(R2 _), R2 _)
> => choosing the second component as the mismatching component, then we can reduce Root(R2(R1 _), R2(R1 _)), Root(R2(R1 _), R2(R2 _)) => Root(R2(R1 _), R2 _); as we can reduce R2(R1 _), R2(R2 _) to R2 _
> Root(R2(R1 _), R2 _), Root(R2(R2 _), R2(R1 _)), Root(R2(R2 _), R2 _)
> => choosing the first component as the mismatching component, we can reduce Root(R2(R1 _), R2 _), Root(R2(R2 _), R2 _) => Root(R2 _, R2 _)
> Root(R2 _, R2 _)
> =>
> Root _
> =>
> exhaustive
> 
> 
> The problem here is that in the first step, javac chooses this path:
> 
> Root(R2(R1 _), R2(R1 _)), Root(R2(R1 _), R2(R2 _)), Root(R2(R2 _), R2(R1 _)), Root(R2(R2 _), R2 _)
> => reduce Root(R2(R1 _), R2(R1 _)),  Root(R2(R2 _), R2(R1 _)) => Root(R2 _, R2(R1 _))
> Root(R2 _, R2(R1 _)), Root(R2(R1 _), R2(R2 _)), Root(R2(R2 _), R2 _)
> => dead end, as there are no two patterns that would have the same nested pattern in the same component
> 
> 
> If javac would do full backtracking, it could go back, and choose the other path, and find out the switch is exhaustive. But, full naive backtracking is, I think, prohibitively too slow for even relatively small swit...

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1093:

> 1091:                                                         if (nestedRPOne.equals(currentReplaced)) {
> 1092:                                                             foundMatchingReplaced = true;
> 1093:                                                             break;

Can we just use `continue ACCEPT;`, and remove the `foundMatchingReplaced` variable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27247#discussion_r2388355666


More information about the compiler-dev mailing list