known translation issues related to JEP 482

[Maurizio Cimadamore]

On 13/06/2024 15:31, Archie Cobbs wrote:
> Hi Maurizio,
>
> On Thu, Jun 13, 2024 at 5:50 AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     There's also a second, more subtle, implementation issue, which
>     I'm in the process of evaluating as we speak. It seems to me that
>     the ordering of the compiler steps Lower and LambdaToMethod is
>     backwards.
>
>
> Ah! That helps clarify things for me. Thanks for your analysis.
>
> -Archie
>
> -- 
> Archie L. Cobbs

Here's a first draft of the work to move LambdaToMethod after Lower:

https://github.com/mcimadamore/jdk/pull/new/cleanup_capture

Things went considerably smooth, given the depth of the surgery. Some 
notable facts:

1. now LambdaToMethod deals with separate classes, not a single toplevel 
one (as it now occurs _after_ lowering)
2. Lower needs a to override `visitLambda`, so that it can properly 
lower the lambda return expressions
3. The code to "desugars" complex method references into lambdas has 
been moved from LambdaToMethod to Lower (so that we can fixup references 
to inner classes etc.)
4. The method reference receiver of desugared lambda expression is now 
stashed into the JCLambda AST (as LambdaToMethod will need that later)
5. the lambda deserialization method generated by LambdaToMethod 
contains string in switch, and implicitly requires boxing, so we need to 
explictly lower that
6. some code generated by Lower is not stable, so lambda deduplication 
fails in new ways

The nice thing about this cleanup is that a ton of questionable stuff 
just disappears:

* no need to have a "lambdaTranslationMap" in Lower. This was only 
needed when a lambda expression anticipated capture later required from 
Lower but that did not appear in the source code (yet)
* no need to have "typesUnderConstruction" (and associated visitors) in 
LambdaToMethod. As now lambda translation occurs _after_ inner class 
translation, LambdaToMethod can expect that references to enclosing 
instances have already been figured out by Lower
* no more need to "guess" captured values for local classes inside a 
lambda - the required captured values are now made explicit in the AST. 
This means we don't need to run a modified FreeVarCollector inside 
LambdaToMethod

All this means is that stuff like this:

https://bugs.openjdk.org/browse/JDK-8334037

Just works. And, if we make improvements in Lower to fix the issues with 
local and anonymous classes and inaccessible enclosing instances, then 
LambdaToMethod will work w/o any manual adjustment required.

Of course, this is a biggie piece of work, so I don't think we should do 
it for 23, as we're already past RDP1. More testing is also needed. But, 
a promising start.

Cheers
Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240613/c767d9aa/attachment.htm>