Community
Participate
Working Groups
I20050922 The search engine should optionaly return the local variable when searching for reference to a type. This should be an option (flag on SearchEngine#search(...) ?) and the local variable should be returned using a new API (SearchMatch#getReferingElement() ?), SearchMatch#getElement() should still return the enclosing method.
*** Bug 111215 has been marked as a duplicate of this bug. ***
Note that bug 111225 wants type parameters as enclosing elements as well.
Type parameters are currently not a requirement, but I think it would be more consistent if those would be resolved as well.
We should try to deliver this soon, so UI can leverage this within M4.
Created attachment 30295 [details] Patch to implement this functionality Note that this is a workspace patch which contains 2 projects: - org.eclipse.jdt.core - org.eclipse.jdt.core.tests.model
I just tried the patch and it works fine for temporaries and variables in for loops, but it seems getLocalElement() returns null for method parameters and exception variables: public class Foo extends Exception { <-- search for references to "Foo" void foo(Foo foo) { // <- no local element Foo foo2; // <- local element try { throw new Foo(); } catch (Foo foo4) { // <- no local element } for(Foo foo3;;) {} // <- local element } }
Created attachment 30493 [details] New version to implement this functionality New version after a loooong discussion with Markus... ;-) Main changes are: 1) SearchRequestor is unchanged. That means that search engine *always* reports local element (and other elements, see below...). Note that this behavior may change if performance tests (not written yet) show that it's too much time consuming... 2) localElement is now implemented only on TypeReferenceMatch instead of SearchMatch. This change has been done to avoid pollution of existing other kind of matches as currently only type reference matches need it. 3) Add otherElements on TypeReferenceMatch to address multiple fields declaration. Search engine reported only one match for type reference on multiple fields declaration which was problematic for this refactoring functionality. Markus, note that I didn't create subclasses as we talked about. While implementing it sounds that other elements may also be implemented at this level as they can also be considered as specific information of a type reference match. 4) I fixed problems with method parameters and catch exception declaration.
If I see that right, getOtherElements() will return either IFields (additional elements) or ILocalVariables (additional localElements). This should be documented, e.g.: /** * Returns other enclosing elements of this search match. * * If {@link #getLocalElement()} is not <code>null</code>, these may be other * local elements such as additional local variables of a multiple local * variables declaration. Otherwise, these may be other elements such as * additional fields of a multiple fields declaration. * * @return the other elements of the search match, or <code>null</code> if none */
Thanks! One more thing: Local variables inside initializers are not yet reported (local element is null).
Created attachment 30567 [details] Final patch which fixes issues described in comment 8 and comment 9
Patch released in HEAD. Test cases are in JavaSearchBugsTests
.
Verified for 3.2 M4 using build I20051213-0010. (new APIs still need @since 3.2 tag)
