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

[Maurizio Cimadamore]

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.

Thoughts?
Maurizio


On 11/09/18 02:05, Liam Miller-Cushon wrote:
> Hi,
>
> This change fixes a regression introduced by the fix for JDK-8203679.
>
> I left a comment on the bug with my diagnosis of the crash: 
> https://bugs.openjdk.java.net/browse/JDK-8210483?focusedCommentId=14209494&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14209494
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8210483
> webrev: http://cr.openjdk.java.net/~cushon/8210483/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ecushon/8210483/webrev.00/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180911/fa4c8050/attachment.html>