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 'move ... to package ...'), 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 the file is located in the default package, however there is a package declaration in .java file that is 'package foo;' 2. Due to miss-matching package information, there should be a compilation error. Click on the quick fix and select: 'Move 'UndoBug2.java' to 'package foo''. This should create a package called foo, move this file inside that package and there should be no compilation error left in the project. 3. Undo the proposal (i.e., hit cmd -or control in windows- z) Expected: The file is again moved to default package and there is 'package foo;' declaration in the file. So, there is one error in the file as in the beginning. Actual: The file is moved to package foo, however the package declaration is deleted. Due to this reason there is no compilation errors in the project anymore. So undoing a proposal fixes compilation errors in the project.
Created attachment 190632 [details] Test case that can deterministically re-create 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 'move ... to ...' correction proposal.
(In reply to comment #0) > 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 > 'move ... to package ...'), 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 the file is located > in the default package, however there is a package declaration in .java file > that is 'package foo;' > 2. Due to miss-matching package information, there should be a compilation > error. Click on the quick fix and select: 'Move 'UndoBug2.java' to 'package > foo''. This should create a package called foo, move this file inside that > package and there should be no compilation error left in the project. > 3. Undo the proposal (i.e., hit cmd -or control in windows- z) > Expected: The file is again moved to default package and there is 'package > foo;' declaration in the file. So, there is one error in the file as in the > beginning. > Actual: The file is moved to package foo, however the package declaration is > deleted. Due to this reason there is no compilation errors in the project > anymore. So undoing a proposal fixes compilation errors in the project. Please note that, I don't believe that they are same, however this bug is very similar to bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=338983 I have submitted. However, since the effected classes were different, I filed a new bug report (thought that the fix would also be different).
It's the same underlying issue as found in bug 338983 comment 6, but this one is about ICompilationUnit#move(*), not rename.
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.
