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

[Jan Lahoda]

On Thu, 6 Nov 2025 20:40:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ExhaustivenessComputer.java line 836:
>> 
>>> 834:         if (toExpand instanceof BindingPattern bp) {
>>> 835:             if (bp.type.tsym.isSealed()) {
>>> 836:                 //try to replace binding patterns for sealed types with all their immediate permitted types:
>> 
>> Can you reuse the word "viablePermittedPatterns" in this comment? That way the reader can formulate the properties of what this variable represents, faster. 
>> 
>> IIUC this is a process of minimization going from the `viablePermittedPatterns` to `reducedPermittedPatterns`. Not only that, but (I think) there is a property that reduction means that you prune the combinatorial space as long as there are no variables *and* the pattern is the most general. The actual invariants are actually coming from `isPossibleSubtypePredicate` which ensures castability and pattern inference. 
>> 
>> 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?
>
>> 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`.

I've changed the variable name, and adjusted the comment.

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

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