[code-reflection] RFR: ModuleOp generation from LambdaOp and FuncOp [v8]

[Paul Sandoz]

On Tue, 9 Dec 2025 01:08:10 GMT, Ruby Chen <duke at openjdk.org> wrote:

>> Add support for generating a ModuleOp from either a LambdaOp or a FuncOp. The given LambdaOp will be converted into the root FuncOp, and the given FuncOp will be assigned as the root FuncOp.
>> 
>> For `CoreOp.ModuleOp.ofLambdaOp()`, a unique name for the new root FuncOp must be passed as a parameter.
>
> Ruby Chen 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 12 additional commits since the last revision:
> 
>  - fixes
>  - Merge branch 'openjdk:code-reflection' into module-op-support
>  - fixed tests
>  - Merge branch 'openjdk:code-reflection' into module-op-support
>  - Add tests
>  - Merge branch 'openjdk:code-reflection' into module-op-support
>  - removing commented code
>  - Suggested changes
>  - Merge branch 'openjdk:code-reflection' into module-op-support
>  - Merge branch 'openjdk:code-reflection' into module-op-support
>  - ... and 2 more: https://git.openjdk.org/babylon/compare/c18d7cec...e70019bf

src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/core/CoreOp.java line 370:

> 368:                                 temp.add(funcOp);
> 369:                                 Op.Result result = blockBuilder.op(CoreOp.funcCall(
> 370:                                         iop.invokeDescriptor().name(),

The name of the func to call differs from the transformed func's name, so the model you create is incorrect. You need to test more robustly e.g., run through the interpreter or compare text output.

src/jdk.incubator.code/share/classes/jdk/incubator/code/dialect/java/JavaOp.java line 337:

> 335:          * Such a lambda operation is one with the following constraints:
> 336:          * <ol>
> 337:          *     <li>Zero or one captured value (assuming correspondence to the {@code this} variable).

That is too restrictive. For method references they may or may not capture `this`, but for a direct invocation there will be captures e.g., the optimization pattern in HAT is a lambda expression that makes a direct call to another method, capturing variables and passing then on as arguments to the method. So you need to test out those cases with mixture of lambda parameters and captured variables.

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

PR Review Comment: https://git.openjdk.org/babylon/pull/691#discussion_r2604662572
PR Review Comment: https://git.openjdk.org/babylon/pull/691#discussion_r2604579846