eclipse - 'Ignore potential matches' 的含义

Question

在“窗口”>“首选项”>“常规”>“搜索”下，有“忽略潜在匹配项”选项

它有什么作用？无论我是否激活它，我都看不出有什么区别。

它是一个仅对 Java 开发有意义的选项(我从不这样做，但我确实使用 Eclipse 用 C、Python 和 PHP 进行开发)？

Answer 1

见 bug 127442例如:根据您要搜索的内容(类、方法等)，搜索引擎可以找到可以匹配的实例(但不能确定)。

这些实例被标记为“ POTENTIAL_MATCH ”:

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

(见 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.

潜在匹配不当行为的当前示例可在 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

结果是:

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.