known translation issues related to JEP 482

[Vicente Romero]

really nice piece of work and badly needed, this area has been a source 
of nasty bugs for a while now. This will be a great move to reduce them 
and will add a solid base to fix future bugs in this area,

Vicente

On 6/13/24 13:05, Maurizio Cimadamore wrote:
>
>
> 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/d65ff8bd/attachment-0001.htm>