RFR: 8367530: The exhaustiveness errors could be improved [v4]

Jan Lahoda jlahoda at openjdk.org
Fri Nov 7 13:32:29 UTC 2025


On Tue, 4 Nov 2025 13:08:04 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
>> 
>>  - Merge branch 'JDK-8364991' into JDK-8367530
>>  - Fixing tests
>>  - Merge branch 'JDK-8364991-2' into JDK-8367530-2
>>  - Better visualisation.
>>  - Merge branch 'JDK-8367499' into JDK-8367530
>>  - Merge branch 'JDK-8364991' into JDK-8367499
>>  - Fixing tests.
>>  - Cleanup.
>>  - Cleanup.
>>  - Cleanup.
>>  - ... and 13 more: https://git.openjdk.org/jdk/compare/e6a3f0da...b7c33349
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 173:
> 
>> 171:     }
>> 172: 
>> 173:     private CoverageResult computeCoverage(Type selectorType, Set<PatternDescription> patterns, boolean search) {
> 
> This extra boolean parameter is subtle (because previously we didn't have a new mode of execution). Can you introduce either a top-level comment at the `computeCoverage` method or something more descriptive than `search` or an enumeration with the two modes? Because now it is calculating both the coverage result and the inverse (uncovered patterns).

I've introduced `PatternEquivalence`, and tried to document the use.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 893:
> 
>> 891: 
>> 892:                 for (Type componentType : componentTypes) {
>> 893:                     List<Type> variants;
> 
> Is this the same conceptually to `viablePermittedPatterns` for the binding patterns case? If yes, we can reuse the same name (just to match the concepts)?

I've adjusted the variable name.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 924:
> 
>> 922:                                                 .collect(Collectors.toCollection(HashSet::new));
>> 923: 
>> 924:                 //remove unnecessary:
> 
> It seems that the removal of the unnecessary patterns is common to the next step as well? If yes, would it be beneficial to extract?

Done, extracted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2503539624
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2503546230
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2503542592


More information about the compiler-dev mailing list