[code-reflection] RFR: Add support for more types [v2]

[Maurizio Cimadamore]

On Thu, 25 Apr 2024 10:24:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR adds support for type-variables and wildcard type arguments in the code model `JavaType`'s hierarchy.
>> 
>> This allows the code model to reflect the source types much more accurately, as we no longer need to erase the source type at the first sign of a non-denotable type. Instead, we can use the a modified (see below) version of the `Types::upwards` function (type projection) to compute the closest **denotable** upper bound to the type found in the source code. This means that the type associated with every op in the model is a (denotable) supertype of the type in the javac AST. The fact that such type is denotable has three important consequences:
>> 
>> * the type can be expressed in the source code (in case the code model needs to be lifted back into Java source)
>> * the type must be expressible in the syntax of bytecode signature attributes (this is important e.g. for the local variable type attribute)
>> * the type can be resolved to its runtime counterpart in `j.l.r.Type` (not implemented in this PR), as explained below
>> 
>> Some parser changes were required to support this, so that we can serialize and deserialize the new types accordingly.
>> 
>> A new method has been added to `JavaType`, namely `JavaType::erasure`, which computes the erasure of a `JavaType`. This might come in handy when lowering the model into bytecode. Since supporting erasure is crucial, modelling of types has been carefully chosen as to facilitate that operation as much as possible: that is why, for example, `TypeVariableRef` contains the "principal" type-variable bound (so that we can define erasure for type-variables in a straightforward fashion, as the erasure of the primary bound).
>> 
>> #### Denotable projections
>> 
>> The code model type associated with an op result is computed by applying a modified version of `Types::upwards` - that is, the function that implements type projections as specified in [JLS 4.10.5](https://docs.oracle.com/javase/specs/jls/se22/html/jls-4.html#jls-4.10.5). The original projection algorithm is designed to leave intersection types in place - while this is handy, as it maximizes the applicability of the type inferred for local variables declared with `var`, for the code model use this is not suitable, as we'd like to get to a denotable type in the end (jshell has a similar problem, which was addressed in a more ad-hoc way).
>> 
>> It is generally possible to project an intersection type using only one of its bounds, e.g.
>> 
>> 
>> List<A & B>
>> ...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for type-variable owner

src/java.base/share/classes/java/lang/reflect/code/parser/impl/DescParser.java line 107:

> 105:         }
> 106: 
> 107:         if (l.token().kind == TokenKind.COLCOL && isTypeVar) {

If we see `#Foo::Bar` we might be seeing two things:
* a type-variable `Bar` in class `Foo`
* a method type-variable in some method `Foo.Bar`

So, we need to disambiguate based on what follows. E.g. if after `Bar` we see `(`, then we know we're in the method case.

src/java.base/share/classes/java/lang/reflect/code/parser/impl/DescParser.java line 114:

> 112:             identifier.append(t.name());
> 113:             if (l.token().kind == TokenKind.LPAREN) {
> 114:                 FunctionType functionType = parseMethodType(l);

Note that here we parse, then we throw away, as the type definition only wants a string-based identifier, so we'll need to reparse the identifier string again in the type factory.

src/java.base/share/classes/java/lang/reflect/code/type/CoreTypeFactory.java line 128:

> 126:                     throw new IllegalArgumentException("Bad type-variable bounds: " + tree);
> 127:                 }
> 128:                 String[] parts = identifier.split("::");

And this is the duplicate parsing logic (although here we already know if it's a method or a class type-variable based on the number of `::`)

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

PR Review Comment: https://git.openjdk.org/babylon/pull/51#discussion_r1579238636
PR Review Comment: https://git.openjdk.org/babylon/pull/51#discussion_r1579239359
PR Review Comment: https://git.openjdk.org/babylon/pull/51#discussion_r1579240395