[code-reflection] RFR: Extensible types in the code model

[Maurizio Cimadamore]

On Mon, 12 Feb 2024 20:41:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Prior to this PR types in the code model were modeled as general "type descriptors" and therefore did not differentiate between kinds of type.  This lack of differentiation is confusing and limiting. The code model defines type descriptions for modeling variables, tuples, and Java types, but they all look the same at runtime and we cannot easily differentiate between them - former two confusingly suggests they are like the latter.
> 
> We enhance the modeling of types and make types extensible in the code model.
> 
> A value has an instance of `TypeElement`, an unsealed interface from which one can extend to model any kind of type. The interface `JavaType` extends from  `TypeElement` and symbolically models Java types. The types `VarType` and `TupleType` are general code model types that model variables and tuples, they are not Java types but they may contain Java types, or any other type elements (including themselves).
> 
> The Triton PoC example has also been updated. The types that were defined to model tensors and pointers can be embedded directly into code models.
> 
> The relationship between Java descriptors (method, method type, field, and record) are now a clearer.
> 
> In subsequent PRs we will iterate to further improve this area:
> 1. Replace the use of `MethodTypeDesc` in the core API with `FunctionType`, that models a function type (or arrow type).  
> 2. Improve boundary between `TypeElement` and the parser. Currently we are reusing the original `TypeDesc` class for this as a temporary solution.
> 3. Devise a richer modeling of Java types. Currently `JavaType` is mostly a clone of `TypeDesc`. But we can do much better perhaps providing similar fidelity as the `javax.lang.model.type.TypeMirror` API.

I like this. Modelling-wise this seems to provide a much cleaner separation between dialect-specific types, which is good. It also opens the door to `javac` using its own internal type as a custom impl of `JavaType` which is very welcome. Looking at the patch, the main difficulties seem to be around parsing - where we need to somehow first parse all the relevant syntax into a TypeDefinition, then turn this TypeDefinition into a concrete type. As you point out in the PR comment, this seems a bit ad-hoc, in the sense that `TypeDefinition` has more or less the same information which we know is required to create a new `JavaType`.

This is similar to what we do for `OpDefinition`, but in that case the model is very clear on what is allowed (e.g. the structure of an op is well-defined and understood). In the case of types, the structure is probably not as clear, but we had some offline discussions on how to make that structure clearer, by doubling down on the notion of "type application", which can then be used to describe arrays, tuples, generic types, functions, and other more ad-hoc Java source types. (this might come at the expense of source-like type syntax though).

While looking at this I wonder if `JavaType` should have a `resolve` method, or if it should have a method which maps it to a `ClassDesc` (which then has the resolve method). And/or (esp. if we move torwards modelling more Java source types like type-variables) whether we should expose another "mapper" towards TypeMirror. Probably both forms are useful, in different cases - the former when interpreting, the latter when analyzing an IR using e.g. an annotation processor.

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

PR Comment: https://git.openjdk.org/babylon/pull/18#issuecomment-1941418195