<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    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,<br>
    <br>
    Vicente<br>
    <br>
    <div class="moz-cite-prefix">On 6/13/24 13:05, Maurizio Cimadamore
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:c99a9eb1-78a1-4b55-b07a-f74a63e62bb7@oracle.com">
      
      <p><br>
      </p>
      <div class="moz-cite-prefix">On 13/06/2024 15:31, Archie Cobbs
        wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:CANSoFxuNwYO93KnEB_Jqnb7qiuPjwH3GLiVd2q3wZMfY1kM=8Q@mail.gmail.com">
        <div dir="ltr">
          <div>Hi Maurizio,</div>
          <div><br>
          </div>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Thu, Jun 13, 2024 at
              5:50 AM Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
              <div>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.</div>
            </blockquote>
          </div>
          <div><br>
          </div>
          <div>Ah! That helps clarify things for me. Thanks for your
            analysis.</div>
          <div><br>
          </div>
          <div>-Archie<br>
          </div>
          <div><br>
          </div>
          <span class="gmail_signature_prefix">-- </span><br>
          <div dir="ltr" class="gmail_signature">Archie L. Cobbs<br>
          </div>
        </div>
      </blockquote>
      <p>Here's a first draft of the work to move LambdaToMethod after
        Lower:</p>
      <p><a class="moz-txt-link-freetext" href="https://github.com/mcimadamore/jdk/pull/new/cleanup_capture" moz-do-not-send="true">https://github.com/mcimadamore/jdk/pull/new/cleanup_capture</a></p>
      <p>Things went considerably smooth, given the depth of the
        surgery. Some notable facts:<br>
        <br>
        1. now LambdaToMethod deals with separate classes, not a single
        toplevel one (as it now occurs _after_ lowering)<br>
        2. Lower needs a to override `visitLambda`, so that it can
        properly lower the lambda return expressions<br>
        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.)<br>
        4. The method reference receiver of desugared lambda expression
        is now stashed into the JCLambda AST (as LambdaToMethod will
        need that later)<br>
        5. the lambda deserialization method generated by LambdaToMethod
        contains string in switch, and implicitly requires boxing, so we
        need to explictly lower that<br>
        6. some code generated by Lower is not stable, so lambda
        deduplication fails in new ways</p>
      <p>The nice thing about this cleanup is that a ton of questionable
        stuff just disappears:</p>
      <p>* 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)<br>
        * 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<br>
        * 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</p>
      <p>All this means is that stuff like this:</p>
      <p><a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8334037" moz-do-not-send="true">https://bugs.openjdk.org/browse/JDK-8334037</a></p>
      <p>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.</p>
      <p>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.</p>
      <p>Cheers<br>
        Maurizio<br>
      </p>
      <p><br>
      </p>
    </blockquote>
    <br>
  </body>
</html>