RFR: 8367530: The exhaustiveness errors could be improved [v8]
Jan Lahoda
jlahoda at openjdk.org
Wed Nov 19 16:48:07 UTC 2025
On Fri, 14 Nov 2025 14:14:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> test/langtools/tools/javac/patterns/ExhaustivenessConvenientErrors.java line 352:
>>
>>> 350: """,
>>> 351: "test.Test.Root(test.Test.R2 _, test.Test.R2(test.Test.Base _, test.Test.R2 _), test.Test.R2(test.Test.R2 _, test.Test.Base _))");
>>> 352: //ideally, the result would be as follow, but it is difficult to split Base on two distinct places:
>>
>> With recursion it should be possible -- but I guess the problem becomes, when do you stop?
>>
>> e.g.
>> `{ Base } -> { R1, R2 } -> { R1, R2(Base, Base) } -> ...`
>
> Perhaps an idea here (not sure how crazy -- possibly a lot) would be to run an analysis on the original patterns as defined in the source code, and determine the _max depth_, and then expand "up to that depth".
>
> So, in the above case, you would know that when you get to `{R1, R2}`, it's "good enough" for the level of depth that is present in the code.
The problem here for the current approach is that the current approach only expands one pattern at a time, but to get the optimal result here, both the `test.Test.Base _` patterns would need to be expanded at the same time (as some combinations of these two are required and some are not).
I was thinking of doing a full expansion originally, but I was worried a bit that for fairly small inputs, the number of combinations could be too high. For example, a newly added:
https://github.com/openjdk/jdk/blob/08fdb6d93ea721541a16b3e1456606dc13198136/test/langtools/tools/javac/patterns/ExhaustivenessConvenientErrors.java#L512
a relatively naive expansion (expanding components that have record patterns in the original pattern) would lead to a few hundreds of patterns, unless I am mistaken. There may be a way to limit the expansions, though.
We can look into this deeper, surely.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2542746286
More information about the compiler-dev
mailing list