[code-reflection] RFR: 8337156: Generate code model for switch expression that throws when no label applies [v4]
Mourad Abbay
mabbay at openjdk.org
Thu Aug 8 07:49:46 UTC 2024
On Fri, 2 Aug 2024 15:00:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/reflect/code/op/ExtendedOp.java line 865:
>>
>>> 863: if (isLabelBody) {
>>> 864: Block.Builder expression = blocks.get(i + 1);
>>> 865: boolean isLastLabel = i == blocks.size() - 2;
>>
>> This is a bit tricky. The details on when a default case is added with a `throw` are spread between `TransPatterns` and `Lower`. Basically:
>> * `TransPatterns` will turn an unconditional pattern (see below) into a default label
>> * `Lower` will add a `default` throwing label, only if one isn't there
>> * the type of the exception is `IncompatibleClassChangeError` if selector is an enum, or `MatchException` otherwise.
>>
>> An unconditional pattern is a pattern whose type is guaranteed to always match the selector expression (e.g. because the type of the pattern is a supertype of the type of the selector expression). This property should be captured by `tree.hasUnconditionalPattern`. In fact, that flag seems to be set also when the switch has a `default` label. So just checking that flag should suffice (but please double check).
>
> Actually... this code is about a lowering step... I think the best way would be to automatically insert a `default` label when generating the code model in `ReflectMethods`. At that point, as explained, the compiler knows which switches are "unconditional" and which are not. We could maybe reflect this piece of info in the model, but I think it's actually better to remove edge cases and just add the missing case.
According to java spec, MatchException will be thrown when no label applies and the selector expression is not null. IncompatibleClassChangeError is not mentioned at all. @mcimadamore
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/195#discussion_r1708864948
More information about the babylon-dev
mailing list