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

Maurizio Cimadamore mcimadamore at openjdk.org
Tue Dec 16 10:02:41 UTC 2025


> 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:

  Add test on implicit primitive widening in for each

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/750/files
  - new: https://git.openjdk.org/babylon/pull/750/files/7e220e1b..e19a0930

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=750&range=02
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=750&range=01-02

  Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/babylon/pull/750.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/750/head:pull/750

PR: https://git.openjdk.org/babylon/pull/750


More information about the babylon-dev mailing list