RFR: 8340145: Problem with generic pattern matching results in internal compiler error [v2]
Aggelos Biboudis
abimpoudis at openjdk.org
Mon Nov 18 14:09:38 UTC 2024
On Thu, 24 Oct 2024 16:15:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:
>> 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).
Added a test with multiple bounds IIUC @lahodaj: https://github.com/openjdk/jdk/pull/21606/commits/f9f9888674577222ae268fd14fd1fdf978d6418e
Still ok, it seems. Hm.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21606#discussion_r1846649291
More information about the compiler-dev
mailing list