RFR: 8340145: Problem with generic pattern matching results in internal compiler error

[Jan Lahoda]

On Mon, 21 Oct 2024 21:12:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> In the following code, when calculating recursively the covered binding patterns, the nested case assumed that the direct supertype of `T2` will always be represented by a `ClassSymbol`. This PR intervenes the erasure calculation.
>> 
>> 
>> static <T, T2 extends T> T unwrapOrElse(Option<T2> option, T defaultValue) {
>>   return switch (option) {
>>      case Option.Some(T2 value) -> value;
>>      case Option.None<T2> _ -> defaultValue;
>>   };
>> }
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 913:
> 
>> 911: 
>> 912:                     for (Type sup : types.directSupertypes(bpOne.type)) {
>> 913:                         ClassSymbol clazz = (ClassSymbol) types.erasure(sup).tsym;
> 
> general comment: I think that erasure should happen in the desugaring phase, we are already doing some erasure in Flow and all of it is related to patterns. I think that we should consider moving all these erasure to either TransTypes or TransPatterns

While I agree that erased type attributes int the AST should happen after `Flow`, I don't think that's what is happening here. The erased types here are used by the exhaustiveness machinery, which is specified in terms of erased type. The erased type produce here, however, shouldn't be recorded in the AST.

But, and the same time, I am not sure if the erasure is correct here. It `sup` is a type variable with multiple bounds, we'll get only the first bound. I think we need to check if that make a difference at this place, I was trying to look, but didn't find any (yet).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21606#discussion_r1815328118