JDK-8221373 (?) Missing checkcast in void-returning lambda

[B. Blaser]

Hi Maurizio,

Thanks for the confirmation, your analysis is similar to my past JBS comment.
Should I then close this issues as "won't fix"?

Ciao,
Bernard

On Tue, 3 Dec 2019 at 16:46, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
>
> Hi,
> sorry for the delay. I've checked JDK-8221373 and, honestly, I'm not
> sure there's anything to fix. Synthetic casts are only emitted when
> there's a target. If you rewrite the example, dropping the lambda
> expression:
>
> abstract class Test {
>
> interface I<X> {
>      X d();
> }
>
> abstract <X> I<X> c();
>
>    void f() {
>       this.<Long>c().d(); //1
>    }
> }
>
> The callsite in (1) is translated as follows:
>
>           0: aload_0
>           1: invokevirtual #2                  // Method c:()LTest$I;
>           4: invokeinterface #3,  1            // InterfaceMethod
> Test$I.d:()Ljava/lang/Object;
>           9: pop
>          10: return
>
> Again, no checkcast here. So I'd say that the fix we did back than
> brought consistency between these two cases, which is IMHO, a good thing.
>
> Maurizio
>
> On 30/10/2019 12:40, B. Blaser wrote:
> > Hi,
> >
> > Looking a bit at JDK-8221373, I'd like to make sure we are going in
> > the right direction before posting a RFR.
> >
> > Going back to JDK-8203338, we decided in [1] to take the functional
> > descriptor's erased return type as translation target which might
> > cause some side-effects like in Liam's void-returning lambda where no
> > 'checkcast' are emitted anymore.
> > So my question is rather simple, should we put in place something
> > closer to the initial fix I suggested in [2] to preserve the original
> > erased expression typing?
> >
> > Thanks,
> > Bernard
> >
> > [1] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012086.html
> > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2018-June/012076.html