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

[Vicente Romero]

Hi Maurizio,

Thanks for your comments. I have uploaded another iteration [3]. I also 
added another regression test. All Tier1 tests passed.

Vicente

[3] http://cr.openjdk.java.net/~vromero/8207320/webrev.01/jdk.dev.patch

On 08/15/2018 11:44 AM, Maurizio Cimadamore wrote:
>
> 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/fcb198e3/attachment-0001.html>