Call Hierarchy identifies incompatible methods with same signature

[trancexpress]

Call Hierarchy identifies incompatible methods with same signature

[iloveeclipse]

This os one I hate most. Especially on methods named run(), getName() etc call hierarchy usually shows too many false matches.

[trancexpress]

Checking with simplified snippet:

public class CallHiearchyTest {
    public static interface Action1 {
        public void doit();
    }

    public static interface Action2 {
    	public void doit();
    }

    public static void action1( Action1 action ) {
        action.doit();
    }

    public static void action2( Action2 action ) {
        action.doit();
    }

    public static void test22() {
        action2( new Action2() {
            public void doit() { // call hierarchy here
                System.out.println( "Bar" );
            }
        } );
    }
}

Call hierarchyt on Action2.doit() shows only test22(). So the call hierarchy doesn't seem to concern itself with the case of calling action1(Action1) with an instance of e.g. Sub implements Action1, Action2. Also replacing interface with abstract class results in the same unexpected contents under callers.

The accurate matches for calls which should not be on the call hierarchy are computed with this stack trace:

"Worker-35: Fetching children of doit" #384 prio=5 os_prio=0 cpu=319.35ms elapsed=2748.66s tid=0x00007f30dc068790 nid=0x49b5 runnable  [0x00007f30c7cfd000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.jdt.internal.core.search.matching.PatternLocator.resolveLevelForType(PatternLocator.java:830)
        at org.eclipse.jdt.internal.core.search.matching.PatternLocator.resolveLevelForType(PatternLocator.java:754)
        at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevelAsSubtype(MethodLocator.java:871)
        at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevel(MethodLocator.java:800)
        at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevel(MethodLocator.java:718)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.reportMatching(MatchLocator.java:2807)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:2046)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1362)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1399)
        at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1541)
        at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:135)
        at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:251)
        at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:602)
        at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:670)
        at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:155)
        at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:266)
        at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:197)
        at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:88)
        at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:70)
        at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:78)
        at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:219)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Here fullyQualifiedName is eclipse.CallHiearchyTest.Action1 and qualifiedPattern is eclipse.CallHiearchyTest.* (and so there is an accurate match). The pattern is coming from here:

"Worker-39: Fetching children of doit" #399 prio=5 os_prio=0 cpu=4.20ms elapsed=333.90s tid=0x00007f30c02fbdb0 nid=0x6213 runnable  [0x00007f30c72fe000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.jdt.core.search.SearchPattern.createPattern(SearchPattern.java:2156)
        at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:144)
        at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:266)
        at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:197)
        at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:88)
        at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:70)
        at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:78)
        at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:219)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Computed with this code:

char[][] enclosingNames = enclosingTypeNames(declaringClass);
if (enclosingNames.length > 0) {
    declaringQualification = CharOperation.concat(declaringQualification, CharOperation.concatWith(enclosingNames, '.'), '.');
}