RFR: 8367530: The exhaustiveness errors could be improved [v4]
Jan Lahoda
jlahoda at openjdk.org
Thu Nov 6 20:45:14 UTC 2025
On Tue, 4 Nov 2025 15:47:46 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 351:
>
>> 349: Type instantiated = instantiatePatternType(targetType, csym);
>> 350:
>> 351: return instantiated != null && types.isCastable(targetType, instantiated);
>
> If inference fails, does this mean that we get an exhaustiveness error with a sample generic instantiation?
If the inference fails, then the subtype won't be considered as necessary to cover the supertype, is it is an "impossible" type. For example, the code in this test:
https://github.com/openjdk/jdk/blob/8a0c47d4ba4db523d94689b3ac347e9cd35183ce/test/langtools/tools/javac/patterns/Exhaustiveness.java#L914
> I wonder how can we end up here with completely incompatible classes? (final A, final B) (so that the castability check return false in `isPossibleSubtypePredicate`). Wouldn't that be an error of applicability?
The exact point of `isPossibleSubtypePredicate` (here and in the existing exhaustiveness computation) is to not consider cases that would not be applicable. Like for example here:
https://github.com/openjdk/jdk/blob/8a0c47d4ba4db523d94689b3ac347e9cd35183ce/test/langtools/tools/javac/patterns/Exhaustiveness.java#L1663
Neither `A_I1` nor `B_I2` are applicable, and hence we don't need to consider them when computing exhaustiveness. They will fail the castability check, and the exhaustiveness algorithm will not consider them when computing coverage for `Z`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2500794798
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2500784792
More information about the compiler-dev
mailing list