Community
Participate
Working Groups
Build Identifier: M20100909-0800 As I user when I do something (in this case select a correction proposal) and undo that, I expect the file to be exactly the same state as the beginning of the change. However, with some of the proposals (here I give example over RenameCompilationUnitChange), this does not happen (i.e., initial state is changed after the undo). Reproducible: Always Steps to Reproduce: 1. Download the attached file (test case). Make sure that .java file (compilation unit) is named as UndoBug.java and class declaration (inside the compilation unit) is 'public class UndoBug2' so that you have a quick fix. 2. Select quick fix, select the proposal: 'Rename compilation unit to 'UndoBug2.java''. This should fix the compilation error. 3. Undo this change (i.e., hit cmd+z (or control+z)). Expected: This should take the file in its initial stage where the class is declared as 'public class UndoBug2' Actual: It takes the file into a stage where there is no compilation error at all (i.e., undo fixes the compilation error). Class is declared as 'public class UndoBug'
Created attachment 190459 [details] Test Case That Deterministically Shows The Bug The reproducing steps are given with respect to this file, however the logic is normally the same and can be applied to any RenameCompilationUnitChange proposal.
Comment on attachment 190459 [details] Test Case That Deterministically Shows The Bug >package edu.washington.cs.bug; > >public class UndoBug2 >{}
Created attachment 190460 [details] Test Case That Deterministically Shows The Bug
(In reply to comment #3) > Created attachment 190460 [details] > Test Case That Deterministically Shows The Bug Excuse me for attaching the wrong test file (which has no compilation errors or quick fixes at all) in the beginning. I made a new attachment that is correct.
Moving to JDT/UI.
Reproduced in HEAD. The same happens when I rename the CU in the Package Explorer and then perform Undo. The problem is that ICompilationUnit#rename(*) in RenameCompilationUnitChange#doRename(*) loses the original information, since the implementation in JDT/Core automatically renames the main type if it exists (Undo case), but it doesn't do anything if no main type is available (Do case). We can only fix this by not using ICompilationUnit#rename(*), but that's bad for other reasons (have to reimplement the refactoring; will probably result in different Java element change events if we use IResource#move(*)).
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.
