Bug 160301 - [search] too many matches found for method references
Summary: [search] too many matches found for method references
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M4   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-10 09:03 EDT by Koen van Dijken CLA
Modified: 2006-12-12 05:34 EST (History)
2 users (show)

See Also:


Attachments
Proposed patch (15.28 KB, patch)
2006-11-10 12:48 EST, Frederic Fusier CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Koen van Dijken CLA 2006-10-10 09:03:46 EDT
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();
		}
	}
	
}
Comment 1 Frederic Fusier CLA 2006-10-12 04:24:51 EDT
This is a SearchEngine issue, you get same suspicious match while searching for A.foo() method references...
Comment 2 Frederic Fusier CLA 2006-10-12 05:06:01 EDT
Fixing this behavior would break refactoring... Martin, what's your mind on this?
Comment 3 Martin Aeschlimann CLA 2006-10-13 04:03:42 EDT
Markus, can you answer?
Comment 4 Markus Keller CLA 2006-10-25 10:49:38 EDT
> 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.
Comment 5 Frederic Fusier CLA 2006-10-25 12:19:23 EDT
(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
Comment 6 Frederic Fusier CLA 2006-11-10 12:48:39 EST
Created attachment 53642 [details]
Proposed patch
Comment 7 Frederic Fusier CLA 2006-11-10 12:49:55 EST
Released for 3.3 M4 in HEAD stream.
Comment 8 David Audel CLA 2006-12-12 05:34:50 EST
Verified for 3.3M4 with I20061212-0010.