RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple abstract methods
maurizio.cimadamore at oracle.com
Wed Aug 15 15:44:19 UTC 2018
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.
On 15/08/18 16:04, Vicente Romero wrote:
> Please review the fix for  at . 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,
>  https://bugs.openjdk.java.net/browse/JDK-8207320
>  http://cr.openjdk.java.net/~vromero/8207320/webrev.00/jdk.dev.patch
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the compiler-dev