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

[Jan Lahoda]

On Tue, 4 Nov 2025 13:16:45 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 157:
> 
>> 155:                         .stream()
>> 156:                         .flatMap(pd -> {
>> 157:                             if (pd instanceof BindingPattern bp && enum2Constants.containsKey(bp.type.tsym)) {
> 
> Can this be subsumed into `computeMissingPatternDescriptions` just to handle the generation of all kinds of incomplete patterns inside there? It seems to be that this client-side would be clearer, but ignore if it would be too much fuss.

I was thinking of this, and given where I think this code is heading with new features added, I think I would prefer to keep it as it is for now. I do agree it would be better if `computeMissingPatterDescriptions` would return the exact missing patterns including missing enum constants, but I think the more appropriate way to do it is using a pattern description for enum constant, and we are not there yet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2503592163