RFR 8210483: AssertionError in DeferredAttr at setOverloadKind caused by JDK-8203679

[Liam Miller-Cushon]

On Tue, Sep 11, 2018 at 12:51 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> What you did looks sensible - I'm not sure we've seen the end of it
> though; the issue is that there are clients that rely on this value:
>
>
> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java#l1308
>
> So if that value changes from OVERLOAD to ERROR, a method reference would
> (e.g. in this case) not considered as 'stuck'. That means that we would
> attempt to type-check it during overload resolution in Attr. This is not a
> big deal (Attr will simply end up with an erroneous type), but it kind of
> gives an idea of the hidden scope of the change here.
>
> At the very least I would try to also fix the Overload and
> CheckStuckPolicy in DeferredAttr to take the new enum constant into account
> so that en ERROR overload kind is effectively treated as OVERLOAD for the
> purpose of stuck analysis. That should minimize impact.
>
I might be missing something, but I tried to update all uses I found of the
enum. E.g. for the use you linked to in DeferredAttr:

- if (tree.getOverloadKind() == JCMemberReference.OverloadKind.OVERLOADED)
{
+ if (tree.getOverloadKind() !=
JCMemberReference.OverloadKind.UNOVERLOADED) {

(see:
http://cr.openjdk.java.net/~cushon/8210483/webrev.00/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/DeferredAttr.java.sdiff.html
)

So we should be treating method references as stuck unless they're
specifically UNOVERLOADED, which seems consistent with the previous
behaviour.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180911/ccd992a5/attachment.html>