This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 131816 - Variable Rename
Summary: Variable Rename
Status: RESOLVED FIXED
Alias: None
Product: javascript
Classification: Unclassified
Component: Editor (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Torbjorn Norbye
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-02 12:05 UTC by Martin Schovanek
Modified: 2009-02-27 14:26 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Schovanek 2008-04-02 12:05:14 UTC
[#20080402075347 continuous build, jdk1.5.0]

to reproduce:
-------------
1) type in a .js (| represents cursor):
var xx|x="Ahoy";
alert(xxx);

2) choose Refactor > Rename and rename the xxx to bbb
ERROR: the alert() xxx parameter is not renamed!

The result is:
var bbb="Ahoy";
alert(xxx);
Comment 1 Torbjorn Norbye 2008-04-02 18:54:09 UTC
Fixed by changeset 518d649511c9 .

Martin S, do you agree to including this in 6.1?
Martin A, can you review the diffs?

Explanation of the fix: When doing a rename of a local variable, I want to skip Token.NAME nodes that correspond to call
names, since these aren't variables, they just reflect the fact that a Token.NAME node is used both for variable
references and to name a call.   However, the problem was that I was only looking at the parent node to see if it was a
call. Only the -first- child of a call node names the call. Any subsequent children are actual function parameters - and
these can be local variable reads as is the case in this bug.

So, the fix simply tightens the call-check to also ensure that we're only skipping this node if it is the -first- child
of a call node.
Comment 2 martin_adamek 2008-04-02 19:39:32 UTC
Looks good to me.
Comment 3 Martin Schovanek 2008-04-03 08:23:12 UTC
Verified in a trunk build, please integrate into the 6.1.
Comment 4 Torbjorn Norbye 2008-04-03 15:39:40 UTC
Fixed in trunk and 6.1.
Comment 5 polan 2008-06-18 12:37:10 UTC
Verified.
Comment 6 Marian Mirilovic 2008-08-01 11:20:29 UTC
move back to consistent state RESOLVED/FIXED