On Thu, 5 Oct 2023 08:14:53 GMT, Aggelos Biboudis <abimpou...@openjdk.org> wrote:
>> Aren't there cases here where the type of the expr is unconditional w.r.t. >> the type of the pattern (and so, no test is required) ? Perhaps the case I'm >> thinking of is dealt with one of the ifs at the beginning of this method. >> >> I have to say I'm a bit confused by how this method is arranged. From a >> logical perspective I would expect first and foremost to test if the pattern >> type is a primitive, because that's the only case where Lower needs to do >> anything (right?). >> >> Then you can have two cases: the expression has a reference type, in which >> case you need null check and unboxing. Or the expression has a primitive >> type. >> >> In both cases you can be in a situation where the conversion is provably >> exact, so no need to call the exactness routine - or you can be in an >> inexact situation where a runtime test is required. >> >> While I'm sure that is what happens in the above code, I think perhaps the >> various tests could be arranged in a way to make the above structure pop out >> a little more? > > Refactoring attempt No. 1 complete. I need to recheck the completeness of > `checkUnconditionallyExact`. In a following commit. `checkUnconditionallyExact` and dominance for constants were adjusted accordingly in https://github.com/openjdk/jdk/pull/15638/commits/c041d208a6fc6beaf785e8a400815fb4a7d08e78 🎉 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347473254
