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

[Maurizio Cimadamore]

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