Community
Participate
Working Groups
R3.2 and latest 3.3 build. I needed to find all references to a method and the result was lots wrong results. Here's a test case: 1. open org.eclipse.jdt.internal.compiler.batch.ClasspathJar 2. select toString() in the Outline (or anywhere in the UI) 3. References > Workspace ==> it finds 414 references in my workspace of which most are wrong Same problem if I use Ctrl+H and the Java search page and only search in sources. Lots of wrong positives. If would expect to only find matches where the receiver is a ClasspathJar instance or a subclass. If other matches are reported as well then only as potential matches.
Created attachment 49618 [details] Simple test case which shows current issues.
Import small test case in a project. Select Test1.toString() method and search for all references in project. You get 3 matches in Test.foo() method: bar().toString(); test.toString(); test1.toString(); The last match "test1.toString()" is obviously correct, nothing else to say about it. The match "test.toString()" is also correct. Even if test is an Object, it can be a Test1 object (see constructor) and so, Search Engine has to return this match. This what we call polymorphic search for method references. In some cases this is really annoying (and it seems to be the case here as you opened the bug as major...), but there's nothing we can do for now without adding a specific option telling Search Engine not to return this kind of match (or perhaps add a new flavor in returned SearchMatch...). This issue is handled by bug 73401 (note that this occurs since 3.0...) The first match "bar().toString()" is obviously NOT correct. Search Engine wrongly does not filter this one as it looks for method declaring class. In this case, this is the interface I which does not implement toString() method, so declaring class is Object... Which is considered as a correct match by Search Engine due to polymorphic search. This wrong behavior should be fixed...
An option to filter the polimorphic Object.toString() cases would be nice but I got many many matches that were just plain wrong i.e. wrong type.
In fact these wrong matches are on messages which declaring class does not implements the searched method. Here's a new version of Test which highlight this: public class Test { void noMatch(Test2 t2) { t2.toString(); } void wrongMatches(I i) { toString(); i.toString(); } void validMatches(Test1 t1) { t1.toString(); } void polymorphicMatches(Object o) { o.toString(); } } Search match "toString()" is also incorrect and is not a message sent to an interface. The receiver type does not implement the method, only its supertype (Object in this case). This is always true for interface but only sometimes true for classes... I verified with your setup that after having fixed this problem and filtered polymorphic matches, I don't get any match for ClasspathJar.toString() references.
Created attachment 49627 [details] Proposed patch
(In reply to comment #4) I'm not sure i.toString() should really be a wrong match. If I have a class Test1Sub extends Test1 implements I , then calls to i.toString() can result in a polymorphic invocation of Test1#toString(), can't they?
(In reply to comment #6) > I'm not sure i.toString() should really be a wrong match. If I have a > class Test1Sub extends Test1 implements I > , then calls to i.toString() can result in a polymorphic invocation of > Test1#toString(), can't they? > You're right, they can... However, Search Engine cannot know this kind of polymorphic match without looking at type hierarchy underneath method class declaration. Doing this would have some performance impact and so should not be activated by default but only by setting a specific option... Another simpler solution would be to return these matches but flag them first as potential and when bug 73401 will be fixed, also flag them as polymorphic.
> Another simpler solution would be to return these matches but flag them first > as potential and when bug 73401 will be fixed, also flag them as polymorphic. That's the way to go, I think. Class Test1Sub could also be implemented outside of the current workspace, and I think an open world assumption is more appropriate here.
Created attachment 50034 [details] New proposed patch This patch put back matches like i.toString() but flag them as potential. Note that this patch also include fix for bug 73401 as it was more efficient to fix both bugs at the same time (see MethodReferenceMatch which has a polymorphic flag/getter/setter...)
Created attachment 50172 [details] Last proposed patch This patch also include fix for bug 73401 (same as one posted on that bug).
Patch released for 3.3 M2 in HEAD stream
Verified for 3.3 M2 using build I20060918-0010.
*** Bug 181987 has been marked as a duplicate of this bug. ***
