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

[Vicente Romero]

looks good to me too,
Vicente

On 09/11/2018 07:06 PM, 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/069c13f1/attachment.html>