Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 339181

Summary:

[reorg][quick fix] Undoing 'move ... to package ...' proposal changes the initial file contents

Product:

[Eclipse Project] JDT

Reporter:

Kivanc Muslu <kivancmuslu>

Component:

Assignee:

JDT-UI-Inbox <jdt-ui-inbox>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

markus.kell.r

Version:

3.7

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

stalebug

Attachments:

Description	Flags
Test case that can deterministically re-create the bug.	none

Description Kivanc Muslu

2011-03-08 04:20:46 EST

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.

Comment 1 Kivanc Muslu

2011-03-08 04:22:05 EST

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.

Comment 2 Kivanc Muslu

2011-03-08 04:23:48 EST

(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).

Comment 3 Markus Keller

2011-03-09 11:56:20 EST

It's the same underlying issue as found in bug 338983 comment 6, but this one is about ICompilationUnit#move(*), not rename.

Comment 4 Eclipse Genie

2020-04-09 14:04:59 EDT

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.