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

Bug 495348

Summary: [quick assist] rename breaks the Java code
Product: [Eclipse Project] JDT Reporter: Gabor <marotig>
Component: UIAssignee: JDT-UI-Inbox <jdt-ui-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: stephan.herrmann
Version: 4.5.2   
Target Milestone: ---   
Hardware: PC   
OS: All   
Whiteboard: stalebug

Description Gabor CLA 2016-06-02 18:18:58 EDT
Quick-assist-rename fails in the following case.

Full working example:
   class Foo {           // (1)
       private int _bar; // (2) <-- this variable is to be renamed
       Foo( int bar ) {  // (3)
          _bar = bar;    // (4) <-- problem should appear here
       }                 // (5)
   }                     // (6)

Action:
  - Use quick-assist-rename (Ctrl+2 R) on "_bar" in line (2), change it to
    "bar".

Expected outcome:
  - Complaint that the assignment in line (4) will cause problems.

Actual outcome:
  - In line (4), the assignment "_bar = bar" is turned to "bar = bar".
  - The left-hand side of the assignment changes its meaning: suddenly, it
    starts referring to the local variable that is declared in line (3).

Described behaviour found in:
  - Eclipse-4.5.2 on Fedora Linux
  - Eclipse-4.4 on Windows 7

Remarks
  - Workspace-wide rename (Alt+Shift+R) works perfectly, it does give a warning.
  - Several easy tricks would prevent the problem, e.g., the use of the "this"
    qualifier in line (4).  Still, renaming shouldn't punish the untidy hacker
    in such a harsh way.
Comment 1 Stephan Herrmann CLA 2016-06-03 18:32:28 EDT
Moving to JDT/UI, though I think this may be a WONTFIX, because:


(1) This operation is not a full refactoring, it comes with no guarantee of creating correct code.
Here's another simple way of creating garbage using Rename in file:
//---
class Foo {
   int zork;
   int bar;
}
//---
Select "bar" and rename it to "zork". Boom.


(2) There *is* a warning
The case in comment 0 is flagged by a the following warning after rename:

          bar = bar;    // (4) <-- problem should appear here
          ^^^^^^^^^
The assignment to variable bar has no effect


Ergo: to get some guarantees about semantically valid changes, always use the true refactoring. That's what it is for.
Comment 2 Eclipse Genie CLA 2020-04-12 15:42:54 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.