[GROOVY-8059] STC overloaded generic method selection not using resolved types

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.4.8
• Fix Version/s: 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.0-rc-3
• Component/s: Static Type Checker
• Assignee: Daniel Sun
• Reporter: John Wagenleitner
• Created: 22/Jan/17 06:39
• Updated: 26/Jul/18 04:38
• Resolved: 11/May/18 06:47

Description

The fix for GROOVY-6804 only works for primitive arguments because the distance calc doesn't wrap and compare against reference param types. I believe it should wrap before doing the compare (which would fix GROOVY-8055) and believe the current test is only passing because of this anomaly with primitives.

The following test is the same from GROOVY-6804 but instead uses the wrapper type and fails to compile:

@groovy.transform.CompileStatic
class Base<K extends Serializable, V> {
    void delete(K key) {}
    void delete(V value) {}
}

@groovy.transform.CompileStatic
class Foo extends Base<String, Integer> {}

@groovy.transform.CompileStatic
public class Class1 {
    Class1() {
        Foo foo = new Foo()        
        foo.delete(Integer.valueOf(1))
    }
}
new Class1()

[Static type checking] - Cannot call Foo#delete(K) with arguments [java.lang.Integer] 

In the case of a primitive both K-Serializable and V-Object (as seen by the getDistance()) method have the same distance so both are promoted as possible choices. The generic type information is not evaluated until later and when generics are applied the correct method is chosen. However, in the case of the reference type K-Serializable is the only method because it has the lowest distance calc and generics are not evaluated.

It seems that the fix would be to resolve the types prior to making the distance calculation.

Issue Links

• is related to: GROOVY-6804 [Static type checking] - Reference to method is ambiguous. Cannot choose between