RFR 8188144: regression in method reference type-checking

[Vicente Romero]

On 09/29/2017 04:29 PM, Maurizio Cimadamore wrote:
>
>
>
> On 29/09/17 18:54, Vicente Romero wrote:
>> looks good,
>>
>> nit: why static methods? not strong about this but we usually favor 
>> instance over static methods
> There are two static methods:
>
> * ReferenceLookupResult::error is a factory, and we use static methods 
> for factories elsewhere  (List.nil())
> * ReferenceLookupResult::staticKind, because otherwise the code would 
> not compile (can't call an instance method before delegating to other 
> constructor)

ok sounds good

>
> Maurizio
>>
>> Thanks,
>> Vicente
>>
>> On 09/29/2017 12:42 PM, Maurizio Cimadamore wrote:
>>>
>>> Hi,
>>> here's a patch for a regression in method reference type checking:
>>>
>>> http://cr.openjdk.java.net/~mcimadamore/8188144/
>>>
>>> JLS 15.13.1 defines the process for resolving a method reference - 
>>> this is a two step process, where two searches are performed. It is 
>>> sometimes possible for both searches to produce a result - when that 
>>> happens, there are a bunch of rules which tell us what search wins:
>>>
>>> " the first search produces a most specific method that is |static|, 
>>> and the set of applicable methods produced by the second search 
>>> contains no non-|static| methods, then the compile-time declaration 
>>> is the most specified method of the first search"
>>>
>>> And again:
>>>
>>> "Otherwise, if the set of applicable methods produced by the first 
>>> search contains no |static| methods, and the second search produces 
>>> a most specific method that is non-|static|, then the compile-time 
>>> declaration is the most specific method of the second search."
>>>
>>> Javac has been rectified to correctly implement this logic as part of:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8068995
>>>
>>> However, in the degenerate case where both searches return _the 
>>> same_ method, the rectified logic doesn't work. This is caused by 
>>> the fact that we use the resolved symbol to 'infer' which search 
>>> (first or second?) gave us the desired result. Note that it is 
>>> important for javac to know which search produced the result as that 
>>> will affect code generation (is this a bound or an unbound method 
>>> reference?).
>>>
>>> Since we already had all the desired information in the class called 
>>> ReferenceLookupResult - introduced as part of JDK-8068995, I have 
>>> tweaked the ReferenceChooser::result signature to return one of 
>>> those guys instead of a plain Symbol - this allows us to reconstruct 
>>> the correct picture before returning control to Attr.
>>>
>>> Cheers
>>> Maurizio
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20170929/dad56acf/attachment.html>