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

[Maurizio Cimadamore]

On Tue, 10 Sep 2024 20:01:19 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> 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).
>
> 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.

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

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