Bug 97614

Summary: [1.5][search] Refactoring: renaming of field of a (complex) parametrized type does not replace all occurrences
Product: [Eclipse Project] JDT Reporter: Maxime Daniel <maxime_daniel>
Component: CoreAssignee: Frederic Fusier <frederic_fusier>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: dirk_baeumer, markus.kell.r
Version: 3.1   
Target Milestone: 3.1 RC3   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Patch to fix this issue
none
Test case added to JavaSearchBugsTests none

Description Maxime Daniel CLA 2005-05-31 13:47:25 EDT
Build I20050527-1300.
Test classes:
--- X
package p;
import java.io.Serializable;
public interface X<T extends X<T, U, V>, 
				   U extends X.XX<T, V>, 
				   V extends X.XY> {
	public interface XX<TT extends X<TT, ?, UU>, 
	                   UU extends X.XY> 
			extends	Serializable {
	}
	public interface XY extends Serializable {
	}
}
--- Y
package p;
public class Y<T extends X<T, U, V>, U extends X.XX<T, V>, V extends X.XY> {
}
--- W
package p;
import java.util.*;
import p.X.*;
public class W {
	private final Map<String, Y<?, ? extends XX<?, ?>, ? >> 
		m1 = null;     // (a)
	public void getStore(final Object o) {
		m1.get(o);     // (b)
	}
}

Scenario: 
- select W.m1 on line (a);
- launch refactor/rename;
- enter m2 as new name;
- Finish.
The expected result would be that m1 occurrences on lines (a) and (b) get
changed to m2. Only the one of line (a) gets changed.

Note that deleting the import p.X.* clause and using the fully qualified X.XX
type in the bound of m1 declaration suppresses the problem.

This might be related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=97547,
which is also related to member types imports.
Comment 1 Dirk Baeumer CLA 2005-06-01 05:42:29 EDT
Markus, can you please investigate.
Comment 2 Markus Keller CLA 2005-06-06 08:22:53 EDT
Moving to JDT/Core for comments.

The RenameFieldProcessor searches for
SearchPattern.createPattern(fField, IJavaSearchConstants.REFERENCES), but the
search engine does not report the reference (b).

When I add rule SearchPattern.R_ERASURE_MATCH to the pattern, then the search
engine also reports (b). However, R_ERASURE_MATCH's javadoc says that it has no
effect on field searches. 
Comment 3 Frederic Fusier CLA 2005-06-13 08:36:19 EDT
Created attachment 22912 [details]
Patch to fix this issue

Currently field declaring type is resolved using parameterized type. Need to
use erausre instead to avoid that field search will be dependent on
R_ERASURE_MATCH pattern rule.
Comment 4 Frederic Fusier CLA 2005-06-13 08:36:57 EDT
Created attachment 22913 [details]
Test case added to JavaSearchBugsTests
Comment 5 Philipe Mulet CLA 2005-06-13 12:07:11 EDT
+1 for RC3

Dirk - pls vote for this one. See impact on refactoring
Comment 6 Frederic Fusier CLA 2005-06-13 12:10:28 EDT
I've run JDT-UI tests (refactoring & automated) and they all pass...
Comment 7 Philipe Mulet CLA 2005-06-14 05:04:56 EDT
Forgot to CC Dirk to obtain vote
Comment 8 Dirk Baeumer CLA 2005-06-14 05:34:27 EDT
+1.
Comment 9 Frederic Fusier CLA 2005-06-14 12:35:38 EDT
Fixed and released in HEAD.
Comment 10 Maxime Daniel CLA 2005-06-16 11:25:01 EDT
Verified using build N20050616-0010 + JDT Core HEAD.