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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Sep 12 09:12:50 UTC 2018

Ok - for some reason I did miss these changes in DeferredAttr. What you 
have looks good.


On 12/09/18 00:06, Liam Miller-Cushon wrote:
> On Tue, Sep 11, 2018 at 12:51 AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto: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 
> <http://cr.openjdk.java.net/%7Ecushon/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/20180912/d508f48c/attachment.html>

More information about the compiler-dev mailing list