Bugzilla – Full Text Bug Listing
| Summary: | [refactoring] Rename / Change method signature doesn't change all sources | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Marco Hofstetter <mr.tacker> | ||||
| Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | jarthana, manoj.palat, markus.kell.r, mr.tacker, srikanth_sankaran | ||||
| Version: | 4.3.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
Manoj, please take a look. Not able to reproduce this issue. All the references get changed when Refactor->rename (Alt-Shift-R) used. [change method signature does not apply to the interface (BaseInterface2) - did you mean something else here?] Let me know if there are any further steps required to reproduce the issue Sorry, i forgot to mention that the error occurs when i apply the refactoring to the method "setTest" in the interface "BaseInterface2". Changing the name of the method or add a new parameter. Jay: could you verify the Java Model part? I think the first call to a jdt.core API that returns a wrong value can be seen when you add a conditional breakpoint to org.eclipse.jdt.internal.corext.refactoring.rename.RippleMethodFinder2#uniteWithSupertypes(..) with condition:
"B_Class".equals(type.getElementName())
The call to fHierarchy.getSupertypes(type) only returns Object, but misses B_Interface.
I can reproduce this. The issue seems to be this: When we are building the package fragment cache for project 'base', one of the depending projects is left out, usually as per the alphabetic order. You can verify this by renaming project 'a' to 'c'. We are keeping the depending project and constructing the cache through DeltaProcessor#RootInfo#project, which unfortunately supports only one project and the last one to the party is left out. It remains to be seen what we can do in Luna time frame. I will investigate. (In reply to Jayaprakash Arthanareeswaran from comment #6) > I can reproduce this. The issue seems to be this: When we are building the > package fragment cache for project 'base', one of the depending projects is > left out, usually as per the alphabetic order. You can verify this by > renaming project 'a' to 'c'. We are keeping the depending project and > constructing the cache through DeltaProcessor#RootInfo#project, which > unfortunately supports only one project and the last one to the party is > left out. Looks like it's been this way for quite some time. I can reproduce this behavior as far back as 3.7. It might be too risky to touch the delta processor at this time. Will see if I can come up with a workaround. (In reply to Jayaprakash Arthanareeswaran from comment #7) > I can reproduce this behavior as far back as 3.7. Then it's totally fine to move it out of 4.4. I gave a quick try, but looks like it won't be a safe fix at this stage. Will revisit early in 4.5. No progress on this. Moving out to 4.6. No progress yet and unlikely to get time during 4.6. Moving out. Bulk move out of 4.8 This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Created attachment 241157 [details] Demo Projects Changing the signature ("rename" or "change method signature") of the interface "BaseInterface2" in the attached projects doesn't change the source of all implementations in the interface-typehierarchy. The problem occurs in the attached demo-setup with the following diamond-project-structure. TOP / \ / \ A B \ / \ / BASE The problem seems to lay in the RegionBasedTypeHierarchy / TypeHierarchy which will be built during the refactoring. Assigning the javaproject of the first element as the context-project of the TypeHierarchy seems to be problematically (In the constructor of RegionBasedTypeHierarchy). Changing the member "project" of the "RegionBasedTypeHierarchy" to the project "top" during debugging refactors all occurances.