RFR: JDK-8207320: Wrong type order for intersection lambdas with multiple abstract methods
maurizio.cimadamore at oracle.com
Wed Aug 15 20:33:12 UTC 2018
This looks good!
I wonder if we can get to a similar issue with intersection types
inferred for a captured var from a lambda. This is possible e.g. if the
variable being captured is declared with 'var', I think. Then, I believe
we will end up in a very similar case - where the signature of the indy
says one thing, and the static type of the dynamic argument being passed
to it has an incompatible type.
But maybe that can't happen - as the type of the captured arguments is
inferred from the argument expressions themselves. So perhaps there
can't be a mismatch (here the problem was that the method handle had a
receiver of type R1 and the receiver expression turned out with a
different receiver type R2).
I'll keep thinking about this case for a while, to see if something pops
up, but in the meantime this fix looks good to go.
If I recall correctly, the coerce method does not generate a cast unless
On 15/08/18 20:35, Vicente Romero wrote:
> Hi Maurizio,
> Thanks for your comments. I have uploaded another iteration . I
> also added another regression test. All Tier1 tests passed.
>  http://cr.openjdk.java.net/~vromero/8207320/webrev.01/jdk.dev.patch
> On 08/15/2018 11:44 AM, Maurizio Cimadamore wrote:
>> 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
>> 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