Closed
Bug 385264
Opened 17 years ago
Closed 14 years ago
local function definition vs. function statement: statement loses
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: jorendorff, Unassigned)
Details
Attachments
(1 file)
447 bytes,
text/html
|
Details |
function f() {
function y() { return 4; }
if (1) {
function y() { return 3; }
}
return y();
}
f();
===> 4
It should return 3. The second "function y()" has no effect. Maybe there's a busted optimization somewhere, the first y is being unconditionally loaded. (This is what Brendan said, if I heard him right.)
Comment 1•17 years ago
|
||
It's that the first y is optimized to use a var (interpreter stack) slot, and the return y fetches from that slot, while the function statement in the if (1) emits a JSOP_CLOSURE that does not update that slot -- instead it binds a property in the Call object for f.
Someone feel free to grab this bug. It's not high priority but it could be fun and educational.
/be
Updated•17 years ago
|
Summary: function-definitions in statement context sometimes have no effect → local function definition vs. function statement: statement loses
Comment 2•17 years ago
|
||
I had a brief look into this bug a couple of weeks ago. As a first step I
decided to check existing behaviour on different platforms. I haven't really
moved beyond that point, but I thought it might be interesting to share my
results in any case. :-)
In my test code I defined a function f() in four places (at the top level,
within an if statement, etc). Each function simply returns a unique integer. I
then called the function in ten different places and stored the results in an
array. This allows us to see which version of the function was actually used
when called from various different places. An HTML version of the test is
attached.
Anyway, here were the results of the test on different platforms. It's
interesting how little consistency there is. It looks like the ECMA 4 reference
implementation is moving towards the behaviour of IE and Opera.
Firefox 2.0, Linux: 1,1,1,2,2,3,3,3,3,3
Firefox 1.5, Windows: 1,1,1,2,2,3,3,3,3,3
Opera 9, Windows: 2,2,2,2,2,4,4,4,4,4
IE 7.0, Windows: 2,2,2,2,2,4,4,4,4,4
Safari 3.0.2, Windows: 1,1,2,2,2,3,3,4,4,4
ECMA 4 ref impl M0: 2,2,2,2,2,4,4,4,4,4
Rhino 1.6R5: 1,1,1,2,2,3,3,3,4,4
Spidermonkey HEAD: 1,1,1,2,2,3,3,3,3,3
Does anyone know what the desired behaviour for Spidermonkey is? I thought
something like the following, because it makes behaviour within a function
consistent with the existing behaviour at the top level.
Desired behaviour?: 1,1,1,2,2,3,3,3,4,4
Updated•14 years ago
|
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•