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: | Core | Assignee: | 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
Maxime Daniel
2005-05-31 13:47:25 EDT
Markus, can you please investigate. 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. 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.
Created attachment 22913 [details]
Test case added to JavaSearchBugsTests
+1 for RC3 Dirk - pls vote for this one. See impact on refactoring I've run JDT-UI tests (refactoring & automated) and they all pass... Forgot to CC Dirk to obtain vote +1. Fixed and released in HEAD. Verified using build N20050616-0010 + JDT Core HEAD. |