7

Under Window > Preferences > General > Search, there is the option Ignore potential matches

What does it do? Whether I activate it or not, I never see a difference.

Is it an option that only makes sense for Java development (which I never do, but I do develop in C, Python and PHP using Eclipse)?

parvus
  • 5,706
  • 6
  • 36
  • 62
  • I was about to [point to the manual](http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-search.htm) but that only says "Select this option if you only want to see exact matches." which isn't exactly helpful ;-) – Aaron Digulla Aug 09 '12 at 08:17
  • That single option has been a mystery for me for years! I already searched many times using google, the built-in help (which, I believe, is the same as http://help.eclipse.org), and never found anything remotely useful. – parvus Aug 09 '12 at 08:27
  • Just added an example of problematic "potential match", as well as a reference to a bug report explaining why different parameter number isn't a criteria for "potential match". – VonC Aug 09 '12 at 09:10

2 Answers2

6

See bug 127442 for examples: depending on what you are searching (a class, a method, ...), the Search engine can find instances which could match (but it cannot say for certain).

Those instances are marked "POTENTIAL_MATCH":

A method with different number of parameters is not a potential match.

(see bug 97322 )

A potential match is a match where the resolution failed (e.g. the method binding is null).
If the user searches for "foo(String)" (without qualifying String), then "foo(java.lang.String)" and "foo(p.String)" are both exact matches.

For the .class file case, I think we can only have potential matches in the case of the missing type case (see bug 196200), i.e if the .class file was compiled and some types it references were missing.

A current example of potential match misbehavior is found in bug 382778:

I have a public static void method printIt(String name).
When I open its call hierarchy, some callers are missing.

I am guessing the callers are missing because java search marks them as potential instead of exact matches for the printIt(String) reference.
The following code is sometimes marked as potential, and sometimes exact:

// Listing 1
PublicInterface2 impl2 = new Impl2("Name Broken");
Static.printIt(impl2.getName());

When the search result is marked potential, the caller is missing from the printIt() call hierarchy.

PublicInterface2 is an empty public interface which extends PackageInterface2Getters.
PackageInterface2Getters is an empty default-scoped interface which extends PackageInterface1Getters.
PackageInterface1Getters is a default-scoped interface which declares String getName().

So impl2.getName() above returns a String.

There are some problems reported which I guess make the matches be marked as potential:

...
Filename : \D:\workspace\eclipse\_runtimes\jdt\call-hierarchy-bug\src\main\PublicInterface2.java
COMPILED type(s)    
2 PROBLEM(s) detected 
     - Pb(2) PackageInterface1Getters cannot be resolved to a type
     - Pb(327) The hierarchy of the type PublicInterface2 is inconsistent

Turns out that:

The compiler asks the "NameEnvironment" to get the type information of any dependent type.
Search has it's own NameEnvironment implementation in JavaSearchNameEnvironment and it is not looking for secondary types.
This is bad and it is surprising that we haven't run into this problem until now.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I think I see where this is heading. I've been searching for `getName()` of an interface and was getting matches in the Spring framework in classes which were completely unrelated. – Aaron Digulla Aug 09 '12 at 08:35
  • Voted up and marked as 'the answer'. But really, you are overwhelming me! The blurb of knowledge poured out here is waaay too much for me to handle. I'm totally awed by the speed and easiness by which you wrote that down. What I will remember from it, after reading some of the bug reports you referred to, is that - yes, it's a java thing - no, in its current state, one normally does not want it to be enabled. Thanks a lot! – parvus Aug 09 '12 at 19:46
1

In Eclipse Luna (Service Release 1 (4.4.1)) I searched just for references to this Java method:

merge(DashboardConfigurationModel template, DashboardModel custom)

It returns two references. One of these calls to the merge() method passes in a DashboardConfigurationModel and a DashboardModel, as befits the method signature. This is a match all right!

The other reference to a merge() method passes in a String and a Map. It is marked in Eclipse as a "potential match" but in my mind, since the argument types don't match, this has zero potential to be a match.

I then checked Ignore potential matches, did the search again, and this noise went away.

Roger
  • 577
  • 6
  • 9