[foreign-memaccess] [Rev 01] RFR: 8245459: Add support for complex filter value var handle adaptation

[Paul Sandoz]

Doh, missed that `MethodHandles.collectReturnValue` was package private!

As such I think is good to go.

Paul.

> On May 21, 2020, at 2:02 PM, Maurizio Cimadamore <mcimadamore at openjdk.java.net> wrote:
> 
> On Thu, 21 May 2020 19:45:22 GMT, Paul Sandoz <psandoz at openjdk.org <mailto:psandoz at openjdk.org>> wrote:
> 
>>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>>> 
>>>  Add more comments on LambdaFormEditor
>> 
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5496:
>> 
>>> 5495:      */
>>> 5496:     /* package */ static MethodHandle collectReturnValue(MethodHandle target, MethodHandle filter) {
>>> 5497:         MethodType targetType = target.type();
>> 
>> Do you need to check that the type of last parameter of the filter function is equal to the return type of the target?
>> Filter parameters size constraints > 0
>> Can the filter return void?
> 
> yeah - ideally I'd need these checks - in reality the checks are performed on the VH side for now, and this is not
> exposed publicly, but I can add all required checks.
> 
> As for void, yes, for consistency with filterReturnValue we should eventually support that too - but it wasn't the goal
> of this patch to provide a full blown MH adapter; I have implemented what was necessary for the VH adaptation. I can
> add the other parts (but would prefer to deal with that separately).
> 
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 5478:
>> 
>>> 5477:     /**
>>> 5478:      * Filter the return value of a target method handle with a filter function. The filter function is
>>> 5479:      * applied to the return value of the original handle; if the filter specifies more than one parameters,
>> 
>> Suggested improvement to JavaDoc:
>> Adapts a target method handle by post-processing
>> its return value and additional arguments (if any) with a filter
>> (another method handle).
>> The result of the filter is returned from the adapter.
>> 
>> If the target returns a value, the filter must accept that value as
>> as the trailing argument, with the additional arguments proceeding that.
>> If the target returns void, the filter must accept only the additional arguments.
>> 
>> The return type of the filter
>> replaces the return type of the target
>> in the resulting adapted method handle.
>> 
>> The trailing argument type of the filter (if any) must be identical to the
>> return type of the target.
>> 
>> The additional argument types of the filter (if any) are appended (in order)
>> to the argument types of the target method handle and become the argument
>> types of the resulting adapted method handle.
>> 
>> Here is pseudocode for the resulting adapter. In the code,
>> {@code T}/{@code t} represent the result type and value of the
>> {@code target}; {@code V}, the result type of the {@code filter};
>> {@code A}/{@code a}, the types and values of the parameters and arguments
>> of the {@code target} as well as the resulting adapter.
>> {@code B}/{@code b}, the types and values of the additional parameters and arguments
>> of the {@code filter} as well as appended to the resulting adapter.
>> ...
> 
> Thanks - I'll see how much work it is to add support of the void case - hopefully it won't be too bad.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/panama-foreign/pull/179 <https://git.openjdk.java.net/panama-foreign/pull/179>