RFR: 8203679: AssertionError in DeferredAttr with parenthesized method reference

[Liam Miller-Cushon]

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/

On Mon, Jun 11, 2018 at 3:55 AM Maurizio Cimadamore <
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/
>
> 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/20180611/6edec0d9/attachment.html>