RFR: JDK-8203338: Unboxing in return from lambda miscompiled to throw ClassCastException

[Maurizio Cimadamore]

I was not 100% sure that removing all coerce logic from LambdaToMethod 
is gonna work - LambdaToMethod is actively rewriting method reference 
expression as lambdas - and these synthetic lambdas are not seen by 
TransTypes - see here:

http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l903

But luckily, it seems L2M already handles these from inside the 
MemberReferenceToLambda class:

http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java#l1051

So that should be ok? But I'd be more comfortable if the tests included 
a case that stressed the method reference path - e.g. an example of a 
method reference that requires a synthetic cast to be compliant with the 
target type - just to make sure.

Maurizio



On 19/06/18 19:31, B. Blaser wrote:
> On 18 June 2018 at 23:09, B. Blaser <bsrbnd at gmail.com> wrote:
>> On 18 June 2018 at 22:12, Maurizio Cimadamore
>> <maurizio.cimadamore at oracle.com> wrote:
>>> I think that we should use the (erased) return type of the functional
>>> descriptor as the target of the translation. In both the
>>> expression/statement case.
>>>
>>> For statement, why not assigning currentMethod to the full method descriptor
>>> type? Or, if we really use currentMethod just for visitReturn, maybe just
>>> storing the expected return (as Vicente suggests) is ok?
>>>
>>> Maurizio
>> I think this should probably work too but it might have more
>> side-effects than the fix I suggested.
>> I'll take a look and provide another patch with this variant if all goes well...
>>
>> Bernard
> I've attached the variant you both suggested.
> Any comment is welcome (langtools:tier1 is OK)!
>
> Bernard