RFR: 8364991: Incorrect not-exhaustive error [v3]

[Vicente Romero]

On Mon, 13 Oct 2025 12:00:55 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 ...
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding tests with generic records.

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

> 1077:                                                 }
> 1078:                                                 if (rpOne.nested[i] instanceof BindingPattern bpOne) {
> 1079:                                                     if (!types.isSubtype(types.erasure(bpOne.type), types.erasure(bpOther.type))) {

it seems from the description that the subtyping test is in the critical path when no hashes are being used. Would it make sense to use a cache and probably reduce the number of times we need to do the full fledged subtyping?

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

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