[code-reflection] RFR: Update the model of pattern matching when pattern variable identifier is underscore [v2]

[Paul Sandoz]

On Wed, 11 Sep 2024 00:21:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I realized i was confusing use of `_` in a type pattern `o instanceof T _` and a record pattern `R(_)`. The former is a type pattern but it has no binding of its match result. The name `BindingPatternOp` follows the naming in the compiler (`JCBindingPattern` and `BindingPatternTree`) ,which is confusing when there is no binding. We should rename `BindingPatternOp` to `TypePatternOp` and then we make it clearer whether there is a binding to a variable or not. (Mourad and I discussed this off-line.)
>
> Yep - this PR is about a type test pattern whose binding name is left unspecified (`_`). I was observing that unspecified names can occur in many places (method parameters, local var decls, etc.) so we probably need some uniform way to handle with "missing names" ? What I'm objecting to, in this PR, is that we're creating a binding, where the binding name is `_` - which strikes me as incorrect. The name is missing/absent, `_` is just the Java way of denoting missing names.

Right, they are interconnected. I proposed to Mourad we should use `null` to signal no binding/name. The corresponding Var modeling the pattern variable can have `null` for its name, which we can do generally for variables with no name.

For example for:

`boolean x = o instanceof String s`

the model is:


    %4 : java.lang.String = constant @null;
    %5 : Var<java.lang.String> = var %4 @"s";
    %6 : boolean = pattern.match %3
        ()java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> -> {
            %7 : java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> = pattern.binding @"s";
            yield %7;
        }
        (%8 : java.lang.String)void -> {
            var.store %5 %8;
            yield;
        };
    %9 : Var<boolean> = var %6 @"x";


For:

`boolean _ = o instanceof String _`

we could generate:


    %4 : java.lang.String = constant @null;
    %5 : Var<java.lang.String> = var %4;
    %6 : boolean = pattern.match %3
        ()java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> -> {
            %7 : java.lang.reflect.code.ExtendedOp$Pattern$Binding<java.lang.String> = pattern.binding;
            yield %7;
        }
        (%8 : java.lang.String)void -> {
            var.store %5 %8;
            yield;
        };
    %9 : Var<boolean> = var %6;


When lowering it might be possible to remove unnamed variables, they are never loaded.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/227#discussion_r1752979908