RFR: 8341901: Using 'var' keyword switch pattern matching causes compiler error

[Aggelos Biboudis]

On Mon, 14 Oct 2024 13:20:14 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> 
> public class T {
>    record R(N.I i) {}
>    int test(Object o) {
>        return switch (o) {
>            case R(var nested) -> 0;
>            default -> 0;
>        };
>    }
>    static class N<T> {
>        interface I {}
>    }
> }
> 
> 
> This fails to compile since JDK 23, due to:
> 
> $ javac T.java 
> error: cannot select a static class from a parameterized type
> 1 error
> 
> 
> The reason for the error is this: the type of `nested` is inferred to `T.N.I`. This is correct. javac will then construct a synthetic AST for it, and the AST will be structurally correct as well: `T.N.I`. But a) the `Type` attached to `T.N` will be `T.N<T>` (which by itself is not correct), and b) after the synthetic AST is created, `Check.validate` is called on the type's AST, and fails, as the types is sees correspond to `T.N<T>.I`, which is illegal.
> 
> Note the synthetic AST is also set for local variable type inference, but the `validate` is called *before* the synthetic AST is created.
> 
> This PR proposes to do two things:
> - move the `validate` call before the synthetic AST creation for `visitBindingPattern`, to mimic the behavior for `var`s.
> - the `TreeMaker` is tweaked to inject erased types instead of parameterized types when generating qualified identifiers for classes or interfaces. This should correspond more closely to what happens when one types `T.N.I` in the source code.

According to my understanding, this bug is fixed by adjusting the `TreeMaker` to use the erased types. As a result the path `T.N.I ` is correct and the tests pass, correctly. Moving `chk.validate` is an optimization right? In this case `tree.var.vartype` will be null for both tests so the validate does nothing.

Otherwise LGTM

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

Marked as reviewed by abimpoudis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21495#pullrequestreview-2371780920