Last Comment Bug 646820 - Function in destructuring assignment can't see up to other variables in the assignment
: Function in destructuring assignment can't see up to other variables in the a...
Status: RESOLVED FIXED
[fixed-in-tracemonkey]
: regression, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: P1 major (vote)
: ---
Assigned To: Jason Orendorff [:jorendorff]
:
:
Mentors:
Depends on: 496134 496682 510783 634959
Blocks: upvar2
  Show dependency treegraph
 
Reported: 2011-03-31 06:33 PDT by Jason Orendorff [:jorendorff]
Modified: 2011-04-26 15:11 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 (12.30 KB, patch)
2011-03-31 07:27 PDT, Jason Orendorff [:jorendorff]
brendan: review+
Details | Diff | Splinter Review

Description Jason Orendorff [:jorendorff] 2011-03-31 06:33:26 PDT
+++ This bug was initially created as a clone of Bug #496134 +++

We can still erroneously optimize some lambda-bindings into flat closure slots.

Case 1: The position of x is extended, but not far enough:

    (function () {
        var [x, y] = [1, function () x];
        assertEq(y(), 1);  // FAIL
    })()

Case 2: UndominateInitializers quits too soon if it sees a syntactic mismatch between the rhs and the lhs.

    (function () {
        var obj = {prop: 1};
        var [x, {prop: y}] = [function () y, obj];
        assertEq(y, 1);  // PASS
        assertEq(x(), 1);  // FAIL
    })();

A silly instance of case 2:

    (function () {
        var [x, y] = {"0": function () y, "1": 13};
        assertEq(x(), 13);  // FAIL
    })();

I think the fix is for UndominateInitializers to search the entire LHS regardless of whether it matches the RHS structurally, and extend the position of each declared variable to cover the entire RHS. This seems like a nice simplification. Taking.
Comment 1 Jason Orendorff [:jorendorff] 2011-03-31 07:27:52 PDT
Created attachment 523300 [details] [diff] [review]
v1

-175 lines net (not counting the tests I added)
Comment 2 Brendan Eich [:brendan] 2011-04-01 15:22:46 PDT
Comment on attachment 523300 [details] [diff] [review]
v1

Nice again! I wrote too much code back in the day, was a bit over-ambitious when destructuring went in. Learned my lesson,

/be
Comment 3 Jason Orendorff [:jorendorff] 2011-04-19 20:43:47 PDT
http://hg.mozilla.org/tracemonkey/rev/bc0e295346e7
Comment 4 Chris Leary [:cdleary] (not checking bugmail) 2011-04-26 15:11:42 PDT
http://hg.mozilla.org/mozilla-central/rev/bc0e295346e7

Note You need to log in before you can comment on or make changes to this bug.