Bug 5821 - Refactor > Rename renames local variable instead of member in case of name clash
Summary: Refactor > Rename renames local variable instead of member in case of name clash
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 1.0   Edit
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: 2.0 M1   Edit
Assignee: Jerome Lanneluc CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-11-12 18:43 EST by Lars Pedersen CLA
Modified: 2002-01-11 09:22 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Pedersen CLA 2001-11-12 18:43:54 EST
Choosing refactor > rename of EclipseTest.test to
EclipseTest.test1 on the following code:

public class EclipseTest {
    public int test = 0;

    public static void main(String[] args) {
        EclipseTest test = new EclipseTest()

        test.test = 1;
    }
}
produces the following code:

public class EclipseTest {
    public int test1 = 0;

    public static void main(String[] args) {
        EclipseTest test = new EclipseTest()

        test1.test = 1;  // << Picks the wrong "test" here!
    }
}
Comment 1 Philipe Mulet CLA 2001-11-13 06:25:07 EST
With latest (2.0 stream) I am obtaining the following which is still wrong:

public class EclipseTest {
    public int test1 = 0;

    public static void main(String[] args) {
        EclipseTest test = new EclipseTest();

        test1.test1 = 1;
    }
}

This is a search bug. It finds 2 matches for 'test' in 'test.test', the first 
one being an inaccurate match. It should not be a match at all.

Comment 2 Jerome Lanneluc CLA 2001-11-13 11:01:48 EST
Internally there were 2 problems:
- first we transformed the local variable binding into null, which caused us to 
report an inaccurate match
- second the 2 algorithms that compute the source positions of references were 
mixed up together

Fixed the first problem by checking if the binding of the first token was not a 
local variable binding.
Fixed the second problem by separating the 2 algorithms.