Constructor call of nested class not found by neither call hierarchy nor find references

[mauromol]

Consider the following Java class:

package test42;

import java.util.Set;

public class MyService {

	public static class MyBean {

		public final boolean foo;
		public final Set<String> bar;
		public final Set<Integer> foobar;

		public MyBean() {
			this(false, null, null);
		}

		public MyBean(final boolean foo, final Set<String> bar,
				final Set<Integer> foobar) {
			this.foo = foo;
			this.bar = bar;
			this.foobar = foobar;
		}
	}
}

and the following Groovy class:

package test42

import test42.MyService.MyBean

class Test42 {

	void doSomething() {
		def b = new MyBean(true, null, null)
	}		
}

Either from the Groovy class or from the Java class select the test42.MyService.MyBean.MyBean(boolean, Set<String>, Set<Integer>) constructor and invoke Ctrl+Alt+H (Call Hierarchy) or Ctrl+Shift+G (Find References): in both cases, the call from Test42 is not found, only that from test42.MyService.MyBean.MyBean() is.

[eric-milles]

This applies to methods with overloads as well. Search is only finding the first method specified in the source. Groovy's named arguments, spread arguments, runtime method resolution, etc. make it more difficult to be sure exactly what method is associated with a given method or constructor call.

[mauromol]

If MyBean is not a nested class, the problem is different. The call to the constructor is matched in that case (by both the Call Hierarchy and the Search for References). The problem in that case is that if you invoke Call Hierarchy or the Search for References on the no-arg constructor, the call from Test42 is matched again, while it should match only when searching from the three args overload.

So, when MyBean is top-level you have false positives, while when MyBean is nested you have false negatives. As a first step, I think false negatives are more important to fix.

[eric-milles]

Constructor calls for inner classes should show up in Call Hierarchy and Search for References now. Not matching in the case of overloads will need to be handled as a separate issue. The constructor reference search component is missing parameter checks that the method reference search component has.

[mauromol]

The use case described in my original report is fixed now in 3.2.0.xx-201811202025-e48, thank you! 👍