| Summary: | [rename] Rename class leads to compilation error when conflicting type is *-imported | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Gustavo Soares <gsoares> | ||||||
| Component: | UI | Assignee: | Markus Keller <markus.kell.r> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | deepakazad, markus.kell.r | ||||||
| Version: | 3.8 | ||||||||
| Target Milestone: | 3.8 M2 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
The problem is that a type with the same simple name "C" is *-imported in class p1.B (which extends p2.C). After the rename refactoring, p1.C shadows p2.C in p1.B. The problem does not occur if 'import p2.*;' is replaced by 'import p2.C;'. RenameTypeProcessor#checkConflictingTypes(IProgressMonitor) already finds the reference in p1.B, but to decide whether we really have a problem, we would have to check the imports. Created attachment 202768 [details]
Fix & test
The complete fix would be quite expensive, but it's bad that we don't detect the potentially dangerous situation. The patch adds a check that may show an error too often, but it's cheap, and it's better to show an error too much rather than failing silently.
Fixed in HEAD. *** Bug 356678 has been marked as a duplicate of this bug. *** *** Bug 356679 has been marked as a duplicate of this bug. *** Created attachment 202795 [details]
Fix 2
The first fix was too aggressive in reporting errors. We only have a problem if the type is actually *-imported. Other *-imports in the CU don't matter.
Fixed in HEAD.
Verified in 4.2 (I20110912-0200). |
Build Identifier: 20110615-0604 Renaming a class may change the hierarchy leading to compilation error: The hierarchy of the type is inconsistent Reproducible: Always Steps to Reproduce: 1. Create the classes package p1; public class A extends B{ } package p1; import p2.*; public class B extends C { } package p2; public class C { } 2. Apply the rename class refactoring to rename A to C. package p1; public class C extends B{ } package p1; import p2.*; public class B extends C { } package p2; public class C { } 3. The resulting code does not compile: The hierarchy of the type is inconsistent