Default parameters: wrong Call Hiearchy results found for method call

[mauromol]

Consider this:

package test42

class GBean {

	GBean() {}
	
	GBean(String foo, String bar = 'hello') {}
	
	void doSomething() {}
	
	void doSomething(String foo, String bar = 'bar') {}
}

And this:

package test42;

class Test43 {

	void test() {
		def b2 = new GBean('foo')
		
		b2.doSomething()
		b2.doSomething('foo')
		b2.doSomething('foo', 'bar')
	}
}

Put the cursor over test42.GBean.doSomething() and hit Ctrl+Alt+H: it finds both b2.doSomething() and b2.doSomething('foo'), while it should find only the former.

Please note that b2.doSomething('foo') is (correctly) found also when requesting Call Hiearchy for test42.GBean.doSomething(String, String).

[eric-milles]

This is implemented in org.eclipse.jdt.groovy.search.MethodReferenceSearchRequestor. When testing a potential match in acceptASTNode, there is an algorithm for matching the call arguments to the parameter types of the method overloads. At this time, methods generated by default params are redirected to the method that generated them. This was a fix for GRECLIPSE-1233.

If this is switched to exact matching, there will still need to be something that accounts for inexact matches. Like if you have "doIt()" and "doIt(int)" and the call expr is "doIt(1, 2, 3)".

[eric-milles]

I am testing a possible solution now. And I need to work out a conflict with #373, since it was fixed in the call argument matching branch and it now goes down the parameter matching branch.

Some known limitations: The searching for multiple method signatures happens only for the Groovy-specific path. So if your Test43 was a Java class, only one reference would be found when searching any of the 3 method calls. Also, if GBean were a binary reference, there would be no link between doSomething(String) and doSomething(String,String) so the search would find only one reference.

[eric-milles]

Ready to test

[mauromol]

This case works fine in 3.3.0.xx-201901152207-e49 and I also verified that there's no regression for #373.

I will open another ticket to investigate solutions for the case in which Test43 is Java code.