Bug 12590 - Returning the type when local var is selected breaks refactoring
Summary: Returning the type when local var is selected breaks refactoring
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows NT
: P3 normal (vote)
Target Milestone: 2.0 M5   Edit
Assignee: David Audel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 12528
  Show dependency tree
 
Reported: 2002-04-02 05:32 EST by Dani Megert CLA
Modified: 2002-04-16 07:48 EDT (History)
1 user (show)

See Also:

Attachments
CopyToClipboardAction.java (1.98 KB, text/plain)
2002-04-02 07:17 EST, Dani Megert CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dani Megert CLA 2002-04-02 05:32:47 EST 
There seems to be a code resolve change: it returns the type if a local var is
selected.

This breaks refactoring: before I could select a local var and then rename it
but now I get a "Rename Type" wizard. It is no longer possible to rename a local
variable.
Comment 1 Philipe Mulet CLA 2002-04-02 06:17:30 EST 
The fundamental behavior shouldn't have changed. Selecting a local variable has 
always answered its actual declared type, given there is no such thing as an 
element for a local variable.

Now it also does so for the variable declaration itself (where in the past it 
used to be doing nothing or misbehave in trying to lookup a type named like the 
variable).

Can you provide a concrete test case ?
Comment 2 Dani Megert CLA 2002-04-02 07:15:59 EST 
It does not happend for all local variables (but if it happens it does so in
both cases i.e. on the declaration and where used).

Test Case:
- ensure to have the newest code of
org.eclipse.search.internal.ui.CopyToClipboardAction.java from ZRH repository (I
changed it today and that's where I saw the problem)
   NOTE: I have attached the corresponding CU
- select "labelProvider" in run()
- Refactor -> Rename

Looking at Search which in all cases uses/gets the type it rather loooks like a
JDT UI refactoring bug.
BUT I think it is wrong to return the type if I do code resolve on a local
variable name. It might be handy for F3/F4 but definitely isn't for search. IMO
code resolve should not be smart (or should have two modes like strict and
smart). It is not clear/logic to me that F3 on a field goes to the field while
F3 on a local var is smart and goes to the declaring type (though this is rather
UI related than a code resovle problem).
Comment 3 Dani Megert CLA 2002-04-02 07:17:49 EST 
Created attachment 534 [details]
CopyToClipboardAction.java
Comment 4 David Audel CLA 2002-04-04 05:06:45 EST 
Selecting a local variable has always answered its type (except for declaration 
which answered nothing). How did it work before to rename local variable ?
Comment 5 Adam Kiezun CLA 2002-04-04 06:23:04 EST 
weird - it must've returned null before because 
what my rename action does is: try resolving - if succesful then rename the 
resolved symbol
if not succesful (null returned) - try, maybe it's a local variable
Comment 6 Adam Kiezun CLA 2002-04-04 06:26:58 EST 
i will experiment with the opposite approach - i.e. try local vars first, use 
code resolve as a fallback
and will let you know
Comment 7 Adam Kiezun CLA 2002-04-04 06:39:12 EST 
it worked
ok to close this report, i think
Comment 8 David Audel CLA 2002-04-04 07:45:55 EST 
closed.