Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 356677 - [rename] Rename class leads to compilation error when conflicting type is *-imported
Summary: [rename] Rename class leads to compilation error when conflicting type is *-i...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.8   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.8 M2   Edit
Assignee: Markus Keller CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 356678 356679 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-09-04 11:03 EDT by Gustavo Soares CLA
Modified: 2011-09-13 04:27 EDT (History)
2 users (show)

See Also:

Attachments
Fix & test (5.13 KB, patch)
2011-09-05 12:09 EDT, Markus Keller CLA 		no flags Details | Diff
Fix 2 (6.37 KB, patch)
2011-09-06 06:42 EDT, Markus Keller CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Gustavo Soares CLA 2011-09-04 11:03:59 EDT 
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
Comment 1 Markus Keller CLA 2011-09-05 12:06:51 EDT 
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.
Comment 2 Markus Keller CLA 2011-09-05 12:09:47 EDT 
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.
Comment 3 Markus Keller CLA 2011-09-05 12:10:22 EDT 
Fixed in HEAD.
Comment 4 Markus Keller CLA 2011-09-05 12:14:36 EDT 
*** Bug 356678 has been marked as a duplicate of this bug. ***
Comment 5 Markus Keller CLA 2011-09-05 12:16:54 EDT 
*** Bug 356679 has been marked as a duplicate of this bug. ***
Comment 6 Markus Keller CLA 2011-09-06 06:42:11 EDT 
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.
Comment 7 Deepak Azad CLA 2011-09-13 04:26:50 EDT 
Verified in 4.2 (I20110912-0200).