RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference

[Liam Miller-Cushon]

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/

On Sat, Jun 9, 2018 at 6:37 AM B. Blaser <bsrbnd at gmail.com> wrote:

> Hi Liam,
>
> At least '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> 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/
> >
> > Thanks,
> > Liam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180609/7e317c99/attachment.html>