719750 - Assertion failure: [infer failure] Missing type pushed 0: int with destructuring assignment

Status: VERIFIED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following test asserts on mozilla-central revision e5e66f40c35b (options -n -m -a):


function f( )  {
  var [ [x], e ]  = ["*", "/", "%"];
    function h() {
      for (var i = 0; i < 5; ++i) {
        x = i * 2;
      }
    }
    h();
  assertEq(x, 8);
} 
f();


This bug strongly reminds me of bug 685321 which also had a destructuring assignment. S-s due to infer failure.

Comment 1

[Brian Hackett [Laid off!]]

Yeah, this looks almost identical to bug 685321.  The 'x' in f() is not marked as closed yet is overwritten within h().

Comment 2

[David Mandelin [:dmandelin]]

I would expect bug 685321 to take care of this. I just tested m-i rev 374975f24277 and it WFM.

Comment 3

[Christian Holler (:decoder)]

(In reply to David Mandelin from comment #2)
> I would expect bug 685321 to take care of this. I just tested m-i rev
> 374975f24277 and it WFM.

I thought bug 685321 was already fixed? I just re-tested this on m-i tip (0a116f325333) and still get the crash.

Comment 4

[Brian Hackett [Laid off!]]

Yeah, either this is a different underlying problem from bug 685321 (though the problem is still during parsing/emitting) or the bug 685321 fix was not complete.

Comment 5

[Johnny Stenback (:jst)]

Not going to push for this for 11.

Comment 6

[David Mandelin [:dmandelin]]

This depends on bug 708892, which is too complicated to fix in time for 12.

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to David Mandelin from comment #6)
> This depends on bug 708892, which is too complicated to fix in time for 12.

How will we get all the depends-on bugs backported to ESR once this does get fixed?

Comment 8

[David Mandelin [:dmandelin]]

(In reply to Daniel Veditz [:dveditz] from comment #7)
> (In reply to David Mandelin from comment #6)
> > This depends on bug 708892, which is too complicated to fix in time for 12.
> 
> How will we get all the depends-on bugs backported to ESR once this does get
> fixed?

Hmmm, not sure. Getting it fixed at is apparently difficult enough, so I'll worry about ESR once we get there.

Comment 9

[David Mandelin [:dmandelin]]

This WFM on trunk. I bet Luke's scope chain work fixed it. That was a huge chain of work and basically a new feature so backport is not realistic. Is there anything to do other than close WFM and mark branches wontfix?

Comment 10

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Luke, could you please add this to the testsuite as well?

Comment 11

[Christian Holler (:decoder)]

(In reply to Gary Kwong [:gkw, :nth10sd] from comment #10)
> Luke, could you please add this to the testsuite as well?

As far as I know, this affects ESR and I don't know if it was fixed because the original fix cannot be backported. If this is not fixed on ESR then adding the test now will make it much easier to detect this.

Comment 12

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Test landed on mozilla-inbound:

http://hg.mozilla.org/integration/mozilla-inbound/rev/bb2a5759abb4

Comment 13

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

> http://hg.mozilla.org/integration/mozilla-inbound/rev/bb2a5759abb4

http://hg.mozilla.org/integration/mozilla-inbound/rev/efb3a00b3aad removes the extraneous print statement I added.

Comment 14

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

http://hg.mozilla.org/mozilla-central/rev/bb2a5759abb4
http://hg.mozilla.org/mozilla-central/rev/efb3a00b3aad

Test landed, so marking VERIFIED.