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

Paul Sandoz psandoz at openjdk.org
Tue Sep 10 15:43:20 UTC 2024


On Tue, 10 Sep 2024 15:08:43 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ReflectMethods.java line 1229:
>> 
>>> 1227: 
>>> 1228:                     String varName = var.name.isEmpty() ? "_" : var.name.toString();
>>> 1229:                     result = append(ExtendedOp.bindingPattern(typeToTypeElement(var.type), varName));
>> 
>> Note sure about this - it's not like the variable has name `_`. The variable does **not** have a name. Which means there should be a way to build a pattern binding (and, more generally, `Var`) that do not have a name (I think?)
>
> Type pattern can't use var

In the JLS there is the `MatchAllPattern` in the grammar. I think it would be clearer to model this explicitly as a distinct pattern operation e.g. a `MatchAllPatternOp`, rather than model as a `BindingPatternOp` with a special name. For `_` there will be no binding to a pattern variable on a successful match (which is always successful and never partial) as there is no variable to bind to.

Separately, we probably should rename `BindingPatternOp` to `TypePatternOp` to be consistent with the names in the JLS.

@mcimadamore the current way the modeling works for `BindingPatternOp` (modelling a `TypePattern`) is the `Var` modeling the pattern variable only comes into existence when lowered, and it may be in a broader scope than in the source (since we currently don't do flow analysis and represent that in the model).

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

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


More information about the babylon-dev mailing list