RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference

[Maurizio Cimadamore]

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/20180611/ec703272/attachment.html>