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

Bug 338983

Summary:

[rename][quick fix] Undoing RenameCompilationUnitChange 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:

amj87.iitr, markus.kell.r

Version:

3.7

Target Milestone:

---

Hardware:

Macintosh

OS:

Mac OS X - Carbon (unsup.)

Whiteboard:

stalebug

Attachments:

Description	Flags
Test Case That Deterministically Shows The Bug	none
Test Case That Deterministically Shows The Bug	none

Description Kivanc Muslu

2011-03-04 18:49:40 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 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'

Comment 1 Kivanc Muslu

2011-03-04 18:52:07 EST

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 2 Kivanc Muslu

2011-03-04 18:53:04 EST

Comment on attachment 190459 [details]
Test Case That Deterministically Shows The Bug

>package edu.washington.cs.bug;
>
>public class UndoBug2
>{}

Comment 3 Kivanc Muslu

2011-03-04 18:55:13 EST

Created attachment 190460 [details]
Test Case That Deterministically Shows The Bug

Comment 4 Kivanc Muslu

2011-03-04 18:56:33 EST

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

Comment 5 Ayushman Jain

2011-03-07 01:42:23 EST

Moving to JDT/UI.

Comment 6 Markus Keller

2011-03-07 11:16:01 EST

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

Comment 7 Eclipse Genie

2020-01-25 15:27:12 EST

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.