[private] Re: RFR 8194932: no ambuguity error is emitted if classfile contains two identical methods with different return types

[Vicente Romero]

I just saw that there is a typo in the bug title ambuguity -> ambiguity, 
just in case you haven't pushed yet.

Vicente

On 01/12/2018 09:20 AM, Vicente Romero wrote:
> looks good,
> Vicente
>
> On 01/11/2018 01:20 PM, Maurizio Cimadamore wrote:
>> Hi,
>> this is a fix for an issue that has to do with compilation from 
>> classfile. While typically it is not possible for a Java source to 
>> contain two override equivalent method (as that would be flagged as 
>> method clash by javac), when a classfile contains two methods that 
>> have the same signature but different return types (which is possible 
>> at the classfile level), javac doesn't generate an ambiguity error 
>> when such method is called. Instead, javac non-deterministically 
>> resolves the call to the first method being declared in the classfile.
>>
>> The solution is to omit a part of the override check that is run in 
>> Resolve::mostSpecific (**). That is, this part should be disabled if 
>> the owner of both potentially ambiguous methods is the same. Extra 
>> code was added to handle the case of statically imported methods, in 
>> which case javac clones the imported method symbols and replaces 
>> their owner to make sure that the bytecode comes out in a certain 
>> way. So, if javac detects that the 'base' symbol of both methods is 
>> indeed the same - it means that the same symol was imported (and 
>> cloned) twice, so we can just return either. At this point, we should 
>> never have a case where we have two maximally specific concrete 
>> methods with same owner (unless we are in the classfile case).
>>
>> http://cr.openjdk.java.net/~mcimadamore/8194932/
>>
>> (**) the override check performed by javac is outside the spec, but 
>> necessary because javac doesn't filter overload candidates by 
>> accessibility - that is, overridden methods are played through the 
>> javac overload resoluytion machinery, and javac prefers the 
>> overridden version of a method; this is an unfortunate, but 
>> historical, javac design choice.
>>
>> Cheers
>> Maurizio
>>
>