Bugzilla – Full Text Bug Listing
| Summary: | [1.5][search] Search for declarations in hierarchy reports too many matches | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Dirk Baeumer <dirk_baeumer> | ||||||||||||
| Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | ||||||||||||||
| Version: | 3.1 | ||||||||||||||
| Target Milestone: | 3.1.1 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Windows XP | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 23641 [details]
Patch to fix this issue
While looking for possible overridden method in pattern hierarchy, we still
need to verify that matching ones have same parameters than pattern.
In bug test case, method foo(String) was a method which may override but
parameters do not match pattern and must be filtered...
Fix not trivial (but not too complicated) and very localized.
It will not have too much impact on existing search behavior.
As this is not critical, I think it's a good candidate for 3.1.1
Dirk - do you agree it can wait until 3.1.1 ? Created attachment 24462 [details] Complete patch to fix this issue Previous patch was not enough to fix the problem entirely. In fact there was a mixed in initial implementation (bug 79990, bug 96761 and bug 96763) between method which overrides possible match and this which must match pattern. So, previous implementation (including previous proposed patch) was too permissive. This new patch fixes definitely the problem. New algorithm is: 1) If compiler is in 1.5 mode, store method declaration which parameters types do no match pattern and set them as possible match 2) Before report match, for stored method declarations only: 2.1) Look in method declaring class hierarchy to see if there are overridden methods in parameterized super classes or super interfaces. Report match if one of these overridden methods has its original method which equals the pattern. 2.2) If method declaration declaring class is in pattern super types hierarchy then look in pattern declaring class hierarchy to see if there are overridden method in parameterized super classes or super interfaces. Report match if one of these overridden methods has its original method which equals the method declaration. Basic sample is: class X<T> { void foo(T t) {} void foo(Class c) {} } class Y extends Y<String> { void foo(String s) {} void foo(Exception e) {} } Search for declaration in hierarchy for X.foo(T t) should return 2 matches: X.foo(T t) and Y.foo(String s) X.foo(T t) matches pattern, so no problem, but Y.foo(String s) does not! With implemented algorithm, 1) make all "foo" methods possibles matches. - X.foo(Class c) and Y.foo(Exception e) will be not be reported because they fail 2.1) and 2.2). - Y.foo(String s) will be reported because it passes 2.1). Search for declaration in hierarchy for Y.foo(String) should also return 2 matches: X.foo(T t) and Y.foo(String s) Y.foo(String s) matches pattern, so no problem, but X.foo(T t) does not! With implemented algorithm, 1) make all "foo" methods possibles matches. - X.foo(T t) will be reported because it passes 2.2). - X.foo(Class c) and Y.foo(Exception e) will be not be reported because they fail 2.1) and 2.2). Search for declaration in hierarchy for Y.foo(Exception) (e.g. comment 0 test case) should return a single match: Y.foo(Exception e) Only Y.foo(Exception e) matches pattern, but with new algorithm, 1) make all "foo" methods possibles matches. - X.foo(T t) and X.foo(Class c) will be not be reported because they fail 2.1) and 2.2): neither pattern nor possible matches override any method in hierarchy... Note that this patch also includes fix for bug 100695... Created attachment 24463 [details] Test cases added to JavaSearchBugsTests This patch also includes test cases for bug 100695 Fixed and released in R3_1_maintenance. Created attachment 24476 [details]
Additional changes which fix other issues
Clear locator caches was done too early and made following test case fail:
I.java
interface I<T> {
void foo(T t);
}
X.java
class X<T> {
void foo(T t) {}
}
class Y extends X<String> {
void foo(String s) {}
void foo(Exception s) {}
}
While searching for Y.foo(String) declaration in project (and not in hierarchy)
then Y.foo(Exception) was found!
Another test case was failing and is also fixed with this patch:
A.java
class <T> {
void foo(T t);
}
class B extends A<String> {
void foo(String s) {}
}
X.java
class X<T> {
void foo(T t) {}
}
class Y extends X<String> {
void foo(String s) {}
}
Search for declaration of B.foo(String) in project reported only A.foo(T t),
B.foo(String s) and Y.foo(String s) matches.
However, search for declaration of A.foo(T) in project correctly reported
A.foo(T t), B.foo(String s), X.foo(T t) and Y.foo(String s).
With this additional patch, search for declaration of B.foo(String) in project
reports same matches (ie. 4) than search for declaration of A.foo(T)...
Created attachment 24477 [details]
Addtional test cases on JavaSearchBugsTests
Patches of additional changes released in R3_1_maintenance. Backported to HEAD stream. Reopen. From comment 6, void foo(Exception s) is still reported as a match. Fixed and released in HEAD stream. No change done in R3_1_maintenance stream. Problem occurred during the backport to HEAD stream => back to FIXED status Verified using I20050920-0010 for 3.2M2 Verified for 3.1.1 using build M20050923-1430. |
RC3 public class A<T> { public void foo(T t) { } } class B extends A<String> { public void foo(String s) { } public void foo(Integer i) { } } - search for declaration in hierarchy on foo(Integer i) using the context menu. observe that foo(String s) is reported as a match as well. Please note that search declaration in hierarchy specifies the two flags IJavaSearchConstants.IGNORE_DECLARING_TYPE | IJavaSearchConstants.IGNORE_RETURN_TYPE. However, using the search dialog (Ctrl+H) which uses the Java element without any flags and search for declarations in workspace reports foo(String s) as well. If B doesn't extend A<String> foo(String s) isn't found.