| Summary: | [search] for declarations finds overloaded method => wrong Rename refactoring | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Core | Assignee: | Markus Keller <markus.kell.r> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | jarthana, loskutov, manoj.palat |
| Version: | 4.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| See Also: | https://git.eclipse.org/r/53912 | ||
| Whiteboard: | stalebug | ||
New Gerrit change created: https://git.eclipse.org/r/53912 When running RunModelTests locally, I get one failure in org.eclipse.jdt.core.tests.model.JavaSearchBugsTests2.testBug395348(). However, that test just passed by chance, and not because of a correct implementation.
If you change the test slightly, then it also fails in master without my proposed fix (because it just assumes all homonyms in the supertype should match, even if they're not actually overridden by the search target):
"public class X {\n"+
" static void f() {\n" +
" new Y<Integer, C2>() {\n"+
" public int compare(C2 o1) {\n" +
" return 0;\n" +
" }\n" +
" };\n"+
" }\n" +
"}\n" +
"abstract class Y<S extends Number, T> {\n" +
" public abstract int compare(T o1);\n" +
" public void compare(S shouldNotMatch) {}\n" +
"}\n" +
"class C2 {}\n"
The fix for bug 395348 was just about suppressing the NPE, not about fixing the actual problem.
Bulk move out of 4.8 This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. Can't reproduce in 4.24 M1 |
master - Have these two classes: package jface; public abstract class ViewerFilter { public abstract boolean selekt(String viewer, Object parentElement); } package jdt; public abstract class AbstractInformationControl { protected class NamePatternFilter extends jface.ViewerFilter { void foo() { selekt("", new Object()); } @Override public boolean selekt(String viewer, Object parentElement) { return selekt(viewer, new Integer(1)); } // rename this method: public boolean selekt(String viewer, Integer parentPath) { return false; } } } - try to use Refactor > Rename to rename the indicated method => expected: only the invocation in NamePatternFilter#selekt(String, Object) should be renamed. => was: more occurrences of identifier "selekt" are updated, including the method declaration ViewerFilter.selekt(String, Object), which should not be touched. I can't reproduce the problem when I move the nested class NamePatternFilter into a top-level class. And when I move the two top-level types into the same package, all "selekt" identifiers are renamed. At the end of org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2#findAllDeclarations(IProgressMonitor, WorkingCopyOwner), we call the SearchEngine with a pattern that should never find the homonym in ViewerFilter. Looks like the bug is in MethodLocator#newDeclarationMatch(...).