Community
Participate
Working Groups
Steps to reproduce: 1. Create the following class: public class Main { public void close() { } } 2. Search for references to close (CTRL+SHIFT+G) 3. Observe as the search view provides results which are outright lies :) There are certainly ways in the search dialog to scope to particular locations. But this is very unintuitive as far as java search goes. As one of the very basic features of any IDE, search is something that should work out of the box for the very simple cases.
Created attachment 169615 [details] a picture of the search view providing useless results.
If you expand those search results, you could see that they are listed as "potential match". If a reference couldn't be completely resolved, it is reported as a "potential match". However, some "potential match" reports seem to be spurious - I will investigate.
Interesting. I wonder why the potential match is turned on by default. Are there cases where the JDT cannot resolve certain kinds of things ? Would it help to turn off potential matches by default since IMHO they are more confusing than useful. Given a great AST, I find it hard to understand what 'potential matches' means to searching the AST!
(In reply to comment #3) > Interesting. I wonder why the potential match is turned on by default. Are > there cases where the JDT cannot resolve certain kinds of things ? Would it > help to turn off potential matches by default since IMHO they are more > confusing than useful. > > Given a great AST, I find it hard to understand what 'potential matches' means > to searching the AST! The most common cases where potential matches are interesting is when you have compiler errors in your code... Typically if you have had a sample like: public class Test { public void foo() { close() } } Then the Search engine would still have been able to found this reference to the close() method even if your syntax was incorrect. But as it could not be 100% sure that it was a real reference, it would have flagged this match as potential. This is really interesting when doing complex refactoring in several steps... :-) Saying that, you can also hide the potential matches by checking the menu item 'Potential matches' in the View Menu of the Search View... (In reply to comment #0) > Steps to reproduce: > > 1. Create the following class: > public class Main { > public void close() { > } > } > > 2. Search for references to close (CTRL+SHIFT+G) > 3. Observe as the search view provides results which are outright lies :) > I could not get any potential matches using your so simple test case put in a simple plug-in (depending from org.eclipse.core.runtime) in a fresh workspace... I even cannot reproduce putting this simple test case in my development workspace. Hence, IMO, Search is working well. You surely should have something in your project configuration which makes Search looking at other plugins where potential matches may be present. Could it be possible to attach the .classpath of your project to this bug? Could you reproduce in your workspace when you put Main in a brand new plugin project? What is your exact build ID?
I could see some potential matches in presence of some plugins in the workspace. In this cases, search is not be able to resolve the close method successfully and hence it is reporting them as potential matches. Hence closing this as WONTFIX.
Verified for 3.7M1.
