[code-reflection] RFR: Support storing the code that builds the code model [v18]

[Maurizio Cimadamore]

On Wed, 12 Mar 2025 18:00:05 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> In this PR we allow the user to decide how to store the code model. The first option is `TEXT`, if this is selected, we store the textual representation of the code model. The second option is `CODE_BUILDR`, if this is selected, we store the code that builds the code model. All work done here is around the second option, because the first option is already supported.
>
> Mourad Abbay has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Merge branch 'code-reflection' into code-model-storage-option
>  - Load OpFactory and TypeElementFactory before invocation of opMethod only if the opMethod has there params.
>  - Fix the remaining compiler tests failures
>  - Fix some of the test failures (3 remains)
>  - Fix the remaining test failures of SwitchExpressionTest2
>  - Fix almost all test failures of SwitchExpressionTest2 (one remaining)
>  - Pass arrayType instead of eleType in OpBuilder.buildArray
>  - Ensure that block params are inserted in the correct order
>  - Add missing imports
>  - Merge branch 'code-reflection' into code-model-storage-option
>  - ... and 10 more: https://git.openjdk.org/babylon/compare/8b5654da...966005ce

src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeModelToAST.java line 151:

> 149:                     yield na;
> 150:                 }
> 151:                 var ownerType = typeElementToType(newOp.constructorType().returnType());

There is a strange asymmetry in the model between constructors and methods. Methods have a descriptor, constructors do not. Also, for methods you know from the op if it is varargs, but for constructors this info is not available. My feeling is that (at least coming at this from javac), trying to lump array and class creation under one op is probably why these asymmetries crop up.

This has nothing to do with this PR of course -- but I suspect that if you had a varargs constructor call this code would not work.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/305#discussion_r1993672762