Concepto de 'Ignorar posibles coincidencias'

Question

Bajo Ventana> Preferencias> General> Buscar, existe la opción Ignorar posibles coincidencias

¿Qué hacer? Ya sea que lo active o no, nunca veo una diferencia.

¿Es una opción que solo tiene sentido para el desarrollo de Java (que nunca hago, pero sí desarrollo en C, Python y PHP usando Eclipse)?

Answer 1

Ver bug 127442 de ejemplos: en función de lo que está buscando (una clase, un método, ...), el motor de búsqueda puede encontrar ejemplos que podrían partido (pero no puedo decir con certeza).

Esos casos están marcados "POTENTIAL_MATCH":

Un método con diferente número de parámetros no es una coincidencia potencial.

(ver bug 97322)

Un partido potencial es un partido en el que la resolución no (unión, por ejemplo, el método es null).
Si el usuario busca "foo(String)" (sin calificar String), entonces "foo(java.lang.String)" y "foo(p.String)" son coincidencias exactas.

Para el caso del archivo .class, creo que solo podemos tener posibles coincidencias en el caso del tipo de letra faltante (consulte bug 196200), es decir, si el archivo .class se compiló y faltan algunos tipos de referencias.

---

Un ejemplo actual de los posibles comportamientos indebidos partido se encuentra en bug 382778:

que tienen un método public static void printIt(String name).
Cuando abro la jerarquía de llamadas, faltan algunas personas.

Supongo que las personas que llaman están desaparecidas porque la búsqueda java las marca como potenciales en lugar de coincidencias exactas para la referencia printIt(String).
El código siguiente es veces marcados como potencial y veces exacta:

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

Cuando el resultado de la búsqueda está marcado potencial, la persona que llama no se encuentra en la jerarquía printIt() llamada.

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

Así impl2.getName() anterior devuelve un String.

hay algunos problemas reportados que supongo que los partidos se marque como potencial:

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

Resulta que:

El compilador le pide al "NameEnvironment" para obtener el tipo información de cualquier tipo dependiente.
La búsqueda tiene su propia implementación NameEnvironment en JavaSearchNameEnvironment y no está buscando tipos secundarios.
Esto es malo y es sorprendente que no nos hayamos encontrado con este problema hasta ahora.

Answer 2

En Eclipse de Luna (Service Release 1 (4.4.1)) busqué sólo por referencias a este método Java:

merge(DashboardConfigurationModel template, DashboardModel custom) 

Devuelve dos referencias. Una de estas llamadas al método merge() pasa en DashboardConfigurationModel y DashboardModel, como corresponde a la firma del método. Este es un partido bien!

La otra referencia a un método merge() pasa en String y Map. Está marcado en Eclipse como una "coincidencia potencial", pero en mi opinión, dado que los tipos de argumento no coinciden, tiene cero posibilidades de ser una coincidencia.

Luego verifiqué Ignore posibles coincidencias, hice la búsqueda de nuevo, y este ruido desapareció.