On Sun, 11 May 2025 21:45:46 GMT, Luca Kellermann <d...@openjdk.org> wrote:
>> While the compiler does not allow invalid queries to flow into
>> `SwitchBootstraps:typeSwitch`, a library user could do that and `typeSwitch`
>> does not prevent such usage pattern errors resulting in erroneous evaluation.
>>
>> For example this is not valid Java (and protected) by javac:
>>
>>
>> byte b = 1;
>> switch (b) {
>> case String s -> System.out.println("How did we get here? byte is " +
>> s.getClass());
>> }
>>
>>
>> but this is a valid call (and not protected):
>>
>>
>> CallSite shortSwitch = SwitchBootstraps.typeSwitch(
>> MethodHandles.lookup(),
>> "",
>> MethodType.methodType(int.class, short.class, int.class), // models
>> (short, int) -> int
>> String.class);
>>
>>
>> The `SwitchBootstraps.typeSwitch` returns wrong result since the code was
>> reasoning erroneously that this pair was unconditionally exact.
>>
>> This PR proposes to add the safety check in unconditional exactness which
>> will return false in erroneous pairs and then the actual check will be
>> delegated to `instanceof`. For the case of erroneous pairs with primitive
>> `boolean`s there is a check in the beginning of the type switch skeleton.
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 782:
>
>> 780: else if (selectorType.equals(targetType) ||
>> 781: (targetType.isPrimitive() && selectorType.isPrimitive()
>> &&
>> 782: ((selectorType.equals(byte.class) &&
>> !targetType.equals(char.class)) ||
>
> Will `unconditionalExactnessMatch(byte.class, boolean.class` return `true`? I
> think it shouldn't, even if `isNotValidPair` is called before.
`unconditionalExactnessMatch` needs to return an answer whether a pair is
unconditional assuming it is applicable. Fusing them would need to elaborate
the type of the returned answer.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25090#discussion_r2086329089
