352609 - "Assertion failure: top < ss->printer->script->depth" trying to decompile a "let" expression for an "is not a function" message

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

js> [let (x = 3, y = 4) x].map(0)
Assertion failure: top < ss->printer->script->depth, at jsopcode.c:791

js> p = {}; (p.z = [let (x = 3, y = 4) x])()
Assertion failure: top < ss->printer->script->depth, at jsopcode.c:791

This is the same assertion as in bug 351795, which is now WFM.

In the first example, note bug 351503 -- it's trying to decompile the wrong thing.

Comment 1

[Jesse Ruderman]

With "prep patch for plan A" in bug 346642, the assertion is gone in both cases:

js> [let (x = 3, y = 4) x].map(0)
typein:25: TypeError: 0 is not a function

js> p = {}; (p.z = [let (x = 3, y = 4) x])()
typein:26: TypeError: p.z is not a function


Also, I noticed that js_ReportIsNotFunction will sometimes (uneval? toString?) an object instead of decompiling part of the source code:

js> p = {}; ([let (x = 3, y = 4) x*x])()
typein:28: TypeError: [9] is not a function

Comment 2

[Jesse Ruderman]

Trunk(ish):

js> p = {}; (p.z = let(x) x)()
typein:1: TypeError: p.z = (let (x) x) is not a function

With the "prep patch for plan A" for bug 346642:

js> p = {}; (p.z = let(x) x)()
typein:2: TypeError: p.z is not a function

Is this change intentional?  I was relying on the old behavior in order to test js_ReportIsNotFunction heavily in the fuzzer, but I can find other ways.

Comment 3

[Jesse Ruderman]

Fixed on trunk because "prep patch for plan A, v9d" in bug 346642 was checked in.

The change in comment 2 was reverted, so I once again get "TypeError: p.z = (let (x) x) is not a function" :)

Comment 4

[Brendan Eich [:brendan]]

(In reply to comment #3)
> Fixed on trunk because "prep patch for plan A, v9d" in bug 346642 was checked
> in.
> 
> The change in comment 2 was reverted, so I once again get "TypeError: p.z =
> (let (x) x) is not a function" :)

Just FYI: the change was not reverted, it was synthesized with the behavior you want here. Both are necessary, depending on where the error occurs and how much context can be recovered by js_DecompileValueGenerator.

/be

Comment 5

[Bob Clary [:bc] (inactive)]

Checking in regress-352609.js;
/cvsroot/mozilla/js/tests/js1_7/block/regress-352609.js,v  <--  regress-352609.js
initial revision: 1.1
done

Comment 6

[Bob Clary [:bc] (inactive)]

I am not sure the test is adequate as it passes on 1.8. Was this a trunk only regression?

verified fixed 1.9 20060919 windows/mac*/linux