Pojęcie „Ignoruj ​​potencjalnych zapałek”

Question

Under Okno> Preferencje> Ogólne> Wyszukiwanie istnieje opcja ignorować potencjalnych mecze

Co on robi? Bez względu na to, czy go aktywuję, czy nie, nigdy nie widzę różnicy.

Czy jest to opcja, która ma sens tylko dla rozwoju Java (czego nigdy nie robię, ale rozwijam się w C, Pythonie i PHP za pomocą Eclipse)?

Answer 1

Zobacz bug 127442 przykłady: w zależności od tego, czego szukasz (klasy, metody, ...) wyszukiwarkę można znaleźć przypadki, które mogłybymecz (ale nie mogę powiedzieć na pewno).

Te przypadki są oznaczone jako „POTENTIAL_MATCH”:

metodę z różnej liczby parametrów nie jest potencjalnym dopasowanie.

(patrz bug 97322)

Ewentualny odpowiednika jest dopasowana w którym to przypadku nie udało (wiązanie przykład metoda jest zerowa).
Jeśli użytkownik wyszuka hasło "foo(String)" (bez kwalifikacji String), wówczas "foo(java.lang.String)" i "" są dokładnie zgodne.

Dla przypadku plików z numerem , możemy mieć tylko potencjalne dopasowania w przypadku brakującego przypadku (patrz bug 196200), tzn. Jeśli plik .class został skompilowany, a niektóre typy nie zawierały referencji.

---

Aktualnym przykładem potencjalnego meczu wybryków znajduje się w bug 382778:

mam public static void metoda printIt(String name).
Po otwarciu hierarchii połączeń brakuje niektórych osób dzwoniących.

Zgaduję, że dzwoniący brakuje, ponieważ wyszukiwanie w java oznacza je jako potencjalne zamiast dokładnych dopasowań dla odniesienia printIt(String).
Poniższy kod jest czasami oznaczone jako potencjału, a czasamidokładny:

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

Jeżeli wynik wyszukiwania jest oznaczony potencjał, wywołujący brakuje hierarchii printIt() połączeń.

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

Więc impl2.getName() powyżej zwraca String.

Są pewne problemy zgłaszane co chyba zrobić zapałki być oznaczone jako potencjał:

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

Okazuje się, że:

Kompilator prosi „NameEnvironment”, aby uzyskać typ informacje o dowolnym rodzaju zależnym.
Wyszukaj ma własną implementację NameEnvironment w JavaSearchNameEnvironment i nie szuka typów drugorzędnych.
To jest złe i zaskakujące, że do tej pory nie napotkaliśmy tego problemu.

Answer 2

w Eclipse Luna (Service Release 1 (4.4.1)) Szukałem tylko dla odniesienia do tej metody Java:

merge(DashboardConfigurationModel template, DashboardModel custom) 

Zwraca dwie referencje. Jedno z tych wywołań do metody merge() przechodzi w DashboardConfigurationModel i DashboardModel, jak przystało na sygnaturę metody. To wszystko pasuje!

Inne odniesienie do metody merge() przechodzi w String i Map. Jest on oznaczony w Eclipse jako "potencjalny mecz", ale moim zdaniem, ponieważ typy argumentów nie pasują, nie ma możliwości, aby być dopasowanym.

Sprawdziłem następnie Zignorowałem potencjalne dopasowania, przeszukano ponownie i ten hałas zniknął.