Bug 81084 - [1.5][search]Rename field fails on field based on parameterized type with member type parameter
Summary: [1.5][search]Rename field fails on field based on parameterized type with mem...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.1 M5   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-15 05:45 EST by Tom Hofmann CLA
Modified: 2005-02-14 11:32 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Hofmann CLA 2004-12-15 05:45:08 EST
M4 test pass (I20041214-2000-gtk)

- Have the class below
- Rename fList to fElements

Expected: the field and the reference in the ctor are renamed
Actual: only the field is renamed; no warning in preview

Note: the same operation succeeds when not a nested type is used as parameter
(e.g. String).

--------- snip -----------

package com.example.m4testing;

import java.util.List;


public class Test {
	static class Element{
	}
	
	static class Inner {
		private final List<Element> fList;
		
		public Inner(List<Element> list) {
			fList= list;
		}
	}
}
Comment 1 Tobias Widmer CLA 2004-12-15 08:53:52 EST
*** Bug 81085 has been marked as a duplicate of this bug. ***
Comment 2 Dirk Baeumer CLA 2004-12-15 09:03:06 EST
Works if fList is declared as List. 

However searching for fList in the given test cases correctly reports a match.
So it seems to be a refactoring problem, not a search problem. 

Not critical for M4.
Comment 3 Markus Keller CLA 2004-12-16 05:39:58 EST
Moving to JDT/Core for comments. In RenameFieldProcessor#getReferences(..), we
search for references to fList without giving a matchRule.

I would expect that the matchRule has no effect on field searches, but without
giving a matchRule, the reference is not found.

When I supply match Rule R_EXACT_MATCH | R_CASE_SENSITIVE | R_ERASURE_MATCH, the
field reference is found. See also bug 81376.
Comment 4 Frederic Fusier CLA 2004-12-16 06:05:21 EST
Markus,
Searching for reference with default match rule (ie. calling
createPattern(IJavaElement element, int limitTo) should find field references.
You don't need to precise R_ERASURE_MATCH to find them.

The problem here comes from the fact that type argument is a member type.
There's a bug in name comparison which does not take into account enclosing
type(s) and that's why the exact match fails.

So, this bug does not change the fact that R_ERASURE_MATCH match rule is only
meaningful for types, not for fields search. I will precise this point in
Javadocs while fixing bug 81376).
Comment 5 Frederic Fusier CLA 2004-12-16 06:08:45 EST
You can see that modifying initial test case as follow:
package com.example.m4testing;

import java.util.List;


public class Test {
	static class Element{
	}
	
	static class Inner {
		private final List<Test.Element> fList;
		
		public Inner(List<Element> list) {
			fList= list;
		}
	}
}
...and then refactor will work properly.
Comment 6 Frederic Fusier CLA 2004-12-25 08:17:56 EST
Fixed.

Now search engine finds references to this field even if R_ERASURE_MATCH is not set.

[jdt-core-internal]
Change done in PatternLocator.resolveLevelForType (char[], char[], char[][][],
int, TypeBinding).
Test cases added in JavaSearchBugsTests
Comment 7 David Audel CLA 2005-02-14 11:32:32 EST
Verified for 3.1M5