Community
Participate
Working Groups
The call hierarchy sometimes shows too many callers. In the following code snippet method A.foo() is not called from B.bar(), although the call hierarchy tries to make us believe so. Eclipse SDK Version: 3.3.0 Build id: I20060922-0010 public class Test { class A { void foo() { } } class B extends A { @Override void foo() { } void bar() { foo(); } } }
This is a SearchEngine issue, you get same suspicious match while searching for A.foo() method references...
Fixing this behavior would break refactoring... Martin, what's your mind on this?
Markus, can you answer?
> Fixing this behavior would break refactoring... Frederic, do you have a patch with this fix that shows how refactoring is broken by this change? I think the Rename Method refactoring should not be affected by this change, since it always does a search for references to all related methods. I think the call in B#bar() should not be considered a reference to A#bar(). Unlike bug 157814, there's no possibility of a polymorphic call here.
(In reply to comment #4) > > Frederic, do you have a patch with this fix that shows how refactoring is > broken by this change? I think the Rename Method refactoring should not be > affected by this change, since it always does a search for references to all > related methods. > Sorry, I spoke too early... It seems I had a bug in my first implementation of the fix. Changing the implementation both fixes the problem and has no consequence on refactoring: renaming A.foo() shows correct preview.... > I think the call in B#bar() should not be considered a reference to A#bar(). > Unlike bug 157814, there's no possibility of a polymorphic call here. > Right
Created attachment 53642 [details] Proposed patch
Released for 3.3 M4 in HEAD stream.
Verified for 3.3M4 with I20061212-0010.