See bug 469625 comment 27. /be

covered by js1_8/regress/regress-469625-02.js

(In reply to comment #2) > Created an attachment (id=369342) [details] > fix This does not remove the code in EmitGroupAssignment that deals with holes in the right-hand-side. Any reason for keeping this deadwood?

(In reply to comment #3) > (In reply to comment #2) > > Created an attachment (id=369342) [details] [details] > > fix > > This does not remove the code in EmitGroupAssignment that deals with holes in > the right-hand-side. Any reason for keeping this deadwood? Nope, I was just reading that, while killing time at the TC39 meeting, then forgot to remove when I patched. /be

There is another pre-existing deadwood in EmitGroupAssignment. MaybeEmitGroupAssignment calls it only when lhs->pn_count <= rhs->pn_count. But the second loop over lhs does not use this condition and makes sure that extra undefs are placed on the stack to initialize elements from the left without the corresponding part on the right like in [a,b] = [1]. So either the condition MaybeEmitGroupAssignment or the push code in the EmitGroupAssignment loop can be removed.

Comment on attachment 369411 [details] [diff] [review] fix, v2 Note that the patch would need a merge with changes due to the bug 484769.

One more time, just to make sure. Jet-lag is hurting me... /be

Fixed: http://hg.mozilla.org/tracemonkey/rev/a4197febbf1d http://hg.mozilla.org/mozilla-central/rev/834e62999a36 /be

Looks like this burned the static analysis boxes

Ah, bsmedberg says on irc: sayrer: I'm bisecting the static analysis burnage... there was a treehydra commit around the same time which might have exposed a latent older SM issue

Yeah, I looked last night, but it wasn't me! ;-) /be

v 1.9.1, 1.9.2