RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple abstract methods

[Maurizio Cimadamore]

Hi,
I agree that there's a bug somewhere in javac's code generation - but I 
believe this fix is too wide, as it touches how erasure of all cast 
expression is performed. I think this issue has only to do with the 
synthetic receiver parameter of a method reference, which seems to be 
captured incorrectly. That is, the lambda translation machinery knows 
well that the receiver ought to be AB (in fact that's what ends up in 
the metafactory protocol), but when the receiver argument is captured, 
no cast is emitted.

I think this could be just matter of generating the right checkcast at 
the right time.

More specifically, in LambdaToMethod, I see this (method visitReference):

             case BOUND:             /** Expr :: instMethod */
                 init = tree.getQualifierExpression();

Now, since this will simply get the (erased) qualifier expression and 
pass it to the indy as its dynamic argument, we have to handle cases 
where there's a disconnect between the erased type of the qualifier 
expression and the expected receiver type (tree.sym.owner.type). I think 
you need a call to transTypes.coerce (as done in other places) at that 
point, to ensure the receiver arg conforms with what the MH expects.

Maurizio


On 15/08/18 16:04, Vicente Romero wrote:
> Please review the fix for [1] at [2]. The fix is modifying the way 
> intersection types are erased. Javac erases an intersection type to 
> its first component, but it is not always the right choice. This patch 
> fixes that issue. As an additional information please check Dan's 
> comments in the bug entry,
>
> Thanks,
> Vicente
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8207320
> [2] http://cr.openjdk.java.net/~vromero/8207320/webrev.00/jdk.dev.patch

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