[code-reflection] RFR: 8373571: Code model of JavaOp.ForOp does not handle (un)boxing correctly [v2]

[Maurizio Cimadamore]

On Mon, 15 Dec 2025 11:50:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR addresses an issue in for-each loop model generation.
>> The for each op factory takes three bodies:
>> 1. the for each expression (e.g. either a collection, or an array)
>> 2. the for each initializer (the logic that receives an element from the expression, and turns it into the expected variable type in the source code)
>> 3. the for each body
>> 
>> The translation for (2) seems to contain a bug: javac erroneously assumes that the initializer body has type `(V)->V`, where `V` is the type of the induction variable declared in the source code.
>> 
>> This PR fixes that so that (2) has type `(ELEM)->V`, where `ELEM` is the static type of an element of the for-each expression, and `V` is the static type of the induction variable.
>> 
>> This translation allows uboxing operations to appear manifest in the generated model.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure logic for determining expression element type is same as in `Attr`
>   Add more tests

src/jdk.incubator.code/share/classes/jdk/incubator/code/internal/ReflectMethods.java line 1874:

> 1872:             // return the bound variables
> 1873:             Type exprType = types.cvarUpperBound(tree.expr.type);
> 1874:             Type elemtype = types.elemtype(exprType); // perhaps expr is an array?

The logic here is very similar with what `Attr` does -- as we really want to use the same expression element type

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

PR Review Comment: https://git.openjdk.org/babylon/pull/750#discussion_r2619091016