Wrong method redirect

[andreasdc]

When you have methods with the same name, but handles different objects in the argument it redirects you to wrong method when you click f3. However when you select the whole name, not just click on it, you are being redirected to the correct method.

[jjohnstn]

Using Eclipse 2023-06 I am unable to reproduce with the following simple source in the Java editor:

public class TestSelect {
	
	public void foo(String s) {
		
	}
	
	public void foo(Integer i) {
		
	}
	
	public void foo(Double d) {
		
	}
	
	public void foo2(Integer i) {
		foo(i);
	}

}

When I click on the foo(i) call, F3 takes me to the middle foo(Integer i) method. Are you able to recreate with this test case and if not is there a test you can post here?

[andreasdc]

It's the same, but even when I select whole method's name it redirects to the wrong method.

Double test = 1d; if (test instanceof Double test2) { TestSelect.foo(test2); }

`public class TestSelect {

public static void foo(String s) {
	
}

public static void foo(Integer i) {
	
}

public static void foo(Double d) {
	
}

public static void foo2(Integer i) {
	foo(i);
}

`
When you click f3 it redirects you to the method with string argument, probably just because it's the first one.

[jjohnstn]

Hi @andreasdc Thanks for the sample. I can now reproduce it. It also fails for source hover.

[jjohnstn]

Transferring to jdt.core. New test case:

public class TestSelect {

	public void foo(String s) {

	}

	public void foo(Integer i) {

	}

	public void foo(Double d) {

	}

	public void foo2(Integer i) {
		Object test = 1d;
		if (test instanceof Double test2) {
			foo(test2); // select foo and use F3
		}
	}

}

Selecting the foo call in foo2 above and hitting F3 ends up jumping to the foo(String) method. Hovering also shows the foo(String) method.

I followed the Open Action to the org.eclipse.jdt.internal.codeassist.SelectionEngine.select() method: line 1086 which calls parsedUnit.resolve(); and ends up throwing a SelectionNodeFoundException from org.eclipse.jdt.internal.codeassist.select.SelectionOnMessageSend.resolveType().

Looking at the parent org.eclipse.jdt.internal.compiler.ast.Block for the if block in the debugger, I see:

{
  <SelectOnMessageSend:foo(test2)>;
  Double test2;
}

I am unfamiliar with this code, but wonder why the Double test2; statement doesn't precede the SelectOnMessageSend in the block.

I tried the same test on Eclipse 2022-03 and the test works correctly (F3 goes to foo(Double)). It fails on 2022-06 so some regression between those two releases. The initial sample from @andreasdc had test declared as Double. On 2022-03 and 2022-06 that causes an error marker stating that expression type cannot be sub-type of Pattern type. This error does not get shown in latest M2.

[iloveeclipse]

See also #1288

[srikanth-sankaran]

The PR #1349 fixes this problem and includes a regression test from here. So I will close this as a duplicate

[srikanth-sankaran]

Duplicate of #1195

[andreasdc]

Are you sure it's a duplicate?

[srikanth-sankaran]

Are you sure it's a duplicate?

Yes, It is not a duplicate in the sense of the symptoms being the same, but the underlying problem being the same - that being incorrect recovery of the parse tree in the presence of pattern matching constructs.

As documented here: #1278 (comment), the recovered parse tree is

{
  <SelectOnMessageSend:foo(test2)>;
  Double test2;
}

which is wrong, the pattern binding variable's declaration should precede its use, not follow.

#1349 is a substantial reimplementation of pattern matching support in code selection engine and subsumes the fix for the current problem and includes a regression test from here.

So breathe easy :)