[code-reflection] RFR: Further cleanup of `CodeModelToAST` and regularize support for varargs instance creation expressions

Maurizio Cimadamore mcimadamore at openjdk.org
Fri Apr 11 17:24:41 UTC 2025


On Fri, 11 Apr 2025 16:32:38 GMT, Mourad Abbay <mabbay at openjdk.org> wrote:

>> This PR makes the code in `CodeModelToAST` that deal with instance creation expression (`NewOp`) a bit closer to the code that deals with method calls (`InvokeOp`). I've added a method, called `constructorTypeToSymbol` which takes the constructor type of a `NewOp` and looks up the constructor symbol with that type.
>> 
>> Then I moved the logic that sets `varargElements` on the created `JCMethodInvocation` nodes into a separate, reusable routine. This is now called also for varargs instance creation expression.
>> 
>> Of course, to do that I had to add support for a new varargs attribute in the `NewOp` class -- which closely follows the one used by `InvokeOp`. This means that in `ReflectMethod` we can now reify in the model as to whether a constructor call was varargs or not.
>> 
>> I've also added some arg count validation in `NewOp`, very similar to the one that appears in `InvokeOp`.
>
> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeModelToAST.java line 87:
> 
>> 85:             setVarargs(methodInvocation, invokeOp.invokeDescriptor().type());
>> 86:         }
>> 87:         if (invokeOp.result().uses().isEmpty()) {
> 
> This part was removed by a previous PR. Now it's going to be reintroduced.

good catch - seems like a merge issue

> src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/CodeModelToAST.java line 108:
> 
>> 106:             case CoreOp.ConstantOp constantOp -> treeMaker.Literal(constantOp.value());
>> 107:             case CoreOp.InvokeOp invokeOp -> invokeOpToJCMethodInvocation(invokeOp);
>> 108:             case CoreOp.NewOp newOp when newOp.resultType() instanceof ArrayType at -> {
> 
> Shouldn't we have a method like `boolean NewOp.isArrayCreation()` ?

Yeah - this will probably be helpful -- but I'd prefer that to be addressed separately

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

PR Review Comment: https://git.openjdk.org/babylon/pull/393#discussion_r2039970993
PR Review Comment: https://git.openjdk.org/babylon/pull/393#discussion_r2039971894


More information about the babylon-dev mailing list