[code-reflection] RFR: Support storing the code that builds the code model [v18]
Maurizio Cimadamore
mcimadamore at openjdk.org
Thu Mar 13 15:13:25 UTC 2025
On Thu, 13 Mar 2025 15:09:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
>> 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/29930c4b...966005ce
>
> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeModelToAST.java line 117:
>
>> 115: var restype = typeElementToType(invokeOp.resultType());
>> 116: var type = new Type.MethodType(paramTypes, restype, List.nil(), syms.methodClass);
>> 117: var methodSym = new Symbol.MethodSymbol(flags, name, type,
>
> Same as for field access (see below) -- we should not create a new method symbol from scratch but "resolve" a method in a given class symbol (using `Resolve::findInternalMethod`)
I suggest to add two helper methods -- one takes a FieldDescriptor and returns a VarSymbol (using `Resolve::findFieldInternal` -- the other takes a MethodDescriptor and returns a MethodSymbol (using `Resolve::findMethodIntenal`. Then you rewrite the code here (and in field access) to use these methods.
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/305#discussion_r1993745510
More information about the babylon-dev
mailing list