On Wed, 28 Jan 2026 08:53:25 GMT, Maurizio Cimadamore <[email protected]> wrote:
>> I've renamed the method. I also tried to put the check it on some other >> places; but unfortunately I couldn't find a better place where setting a >> sensible value (i.e. such that would not cancel tests in >> `ExhaustivenessConvenientErrors.java`, but would cancel >> `Exhaustiveness.testDeeplyNestedNotExhaustive`). >> >> Yes, during the "real" run, `baseChecks` should be `-`, and that should >> prevent the cancelation from happening. > > For now let's keep the code as is, and see how this goes (Maybe add a comment saying that the -1 is quite crucial to avoid exceptions being triggered in unexpected places). Another option could be to have a checker object that does nothing in normal paths, but then would be "reassigned" before the exhaustiveness logic kicks in to keep a count and throw an exception. Up to you -- it won't completely remove the problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27256#discussion_r2735533937
