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

[Paul Sandoz]

On Mon, 15 Dec 2025 11:53:42 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

Looks good. This should also allow for conversions. When building the enhanced for op it us up to code building to ensure the types line up.

At first i was questioning whether we should keep the enhanced for op or remove and model as a de-sugared for op, and provide a way to detect as if it were modeled from an enhanced for. But when patterns in the initializer come back the enhanced for op modelling (which anticipated use of patterns) will be clearer than that of the desugared for loop.

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

Marked as reviewed by psandoz (Lead).

PR Review: https://git.openjdk.org/babylon/pull/750#pullrequestreview-3580670512