RFR 8188144: regression in method reference type-checking

[Maurizio Cimadamore]

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)

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/dfca3379/attachment.html>