RFR: 8317048: VerifyError with unnamed pattern variable and more than one components

[Aggelos Biboudis]

On Fri, 29 Sep 2023 10:20:10 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> There were situations when javac optimizes switch structures (by merging the head of cases recursively) when two neighboring cases have a mix of named and unnamed patterns. This resulted translation is like the following:
> 
> From this:
> 
> 
>   static <T1 extends Comparable, T2 extends Comparable> int compareTo(Tuple<R<T1>, R<T2>> o) {
>         return switch (o) {
>             case Tuple<R<T1>, R<T2>>(R1<T1> _, R1<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R1<T1> _, R2<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R2<T1> _, R1<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R2<T1> fst, R2<T2> snd) -> fst.value().compareTo(snd.value());
>         };
>     }
> 
> 
> to code like this from the deeper nested switch (sample taken from `translateTopLevelClass`):
> 
> 
> ...
> case 1:
>    if (!(let snd = (T8317048.R2)selector10$temp; in true)) {
>        index$11 = 2;
>        continue;
>    }
>    yield .value().compareTo(snd.value()); // boom, fst is missing
>    break;
> ...
> 
> 
> The reason is that in the `resolveAccumulator` we peek the first of the two to replace both, in this case the `R2<T1> _`. 
> 
> 
> JCPatternCaseLabel leadingTest = 
>         (JCPatternCaseLabel) accummulator.first().labels.head;
> 
> 
> One way to solve this is to not merge two successive type patterns that have different namings (either both named or both unnamed).

Keep open 🚀

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

PR Comment: https://git.openjdk.org/jdk/pull/15983#issuecomment-1784037183