RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference

[Maurizio Cimadamore]

Looks good to me!

Thanks
Maurizio


On 11/06/18 22:16, Liam Miller-Cushon wrote:
> Thanks, done. (I went with 'previous' instead of 'kind' for the local 
> to disambiguate with the parameter, but I don't have a strong opinion 
> about it.)
>
> http://cr.openjdk.java.net/~cushon/8203679/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ecushon/8203679/webrev.01/>
>
> On Mon, Jun 11, 2018 at 3:55 AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>
>     Looks good - the fix allows recursion to take place and to follow
>     the links from copy to copy to fetch the right overload kind.
>
>     One minor nit is that we could avoid calling t.getOverloadKind
>     twice e.g. instead of:
>
>     if (t.getOverloadKind() == null) {
>         t.setOverloadKind(overloadKind);
>     } else {
>     Assert.check(overloadKind == t.getOverloadKind());
>     }
>
>
>     Do:
>
>     OverloadKind kind = t.getOverloadKind();
>     if (kind == null) {
>         t.setOverloadKind(overloadKind);
>     } else {
>     Assert.check(overloadKind == kind);
>     }
>
>
>     Maurizio
>
>     On 09/06/18 20:58, Liam Miller-Cushon wrote:
>>     Oops, thanks. There was an issue with the webrev: I generated the
>>     diff against the wrong base revision.
>>
>>     It's fixed now:
>>     http://cr.openjdk.java.net/~cushon/8203679/webrev.00/
>>     <http://cr.openjdk.java.net/%7Ecushon/8203679/webrev.00/>
>>
>>     On Sat, Jun 9, 2018 at 6:37 AM B. Blaser <bsrbnd at gmail.com
>>     <mailto:bsrbnd at gmail.com>> wrote:
>>
>>         Hi Liam,
>>
>>         At least 'make.at <http://make.at>()' looks good ;-)
>>         I already fixed it here:
>>
>>         https://bugs.openjdk.java.net/browse/JDK-8202372
>>         http://hg.openjdk.java.net/jdk/jdk/rev/cece972575ac
>>
>>         Bernard
>>
>>         On 9 June 2018 at 04:46, Liam Miller-Cushon
>>         <cushon at google.com <mailto:cushon at google.com>> wrote:
>>         > Hi,
>>         >
>>         > Please consider the following fix for JDK-8203679.
>>         >
>>         > I added some notes to the bug:
>>         >
>>         https://bugs.openjdk.java.net/browse/JDK-8203679?focusedCommentId=14186441&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14186441
>>         >
>>         > The proposed fix seems harmless assuming this
>>         implementation comment is
>>         > correct:
>>         >
>>         >> once the value for overloadKind is determined for a copy,
>>         it can be safely
>>         >> forwarded to
>>         >> the copied tree, we want to profit from that
>>         >
>>         > The current logic only propagates the overloadKind to the
>>         copied tree the
>>         > first time an overloadKind is set for any copy of that
>>         tree. If it was
>>         > possible to compute different overloadKinds for different
>>         copies, that
>>         > approach wouldn't work. I added an assertion that the
>>         computed overloadKind
>>         > is stable to make sure that assumption holds.
>>         >
>>         > bug: https://bugs.openjdk.java.net/browse/JDK-8203679
>>         > webrev:
>>         http://cr.openjdk.java.net/~cushon/8203679/webrev.00/
>>         <http://cr.openjdk.java.net/%7Ecushon/8203679/webrev.00/>
>>         >
>>         > Thanks,
>>         > Liam
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180612/68e979e9/attachment.html>