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

[Aggelos Biboudis]

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;


On way to solve this is to not merge two successive type patterns that have different namings (either both named or both unnamed).

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

Commit messages:
 - 8317048: VerifyError with unnamed pattern variable and more than one components
 - Add testfile

Changes: https://git.openjdk.org/jdk/pull/15983/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15983&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317048
  Stats: 89 lines in 2 files changed: 89 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15983/head:pull/15983

PR: https://git.openjdk.org/jdk/pull/15983