75688 - JS should allow reference_returning()++ etc.

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Brendan Eich [:brendan]]

Spun off from bug 75560.  Shaver guilts me every time!

/be

Comment 1

[Brendan Eich [:brendan]]

Where did 0.9.1's time go?

/be

Comment 2

[Brendan Eich [:brendan]]

Shaver, I need more guilt!

/be

Comment 3

[Brendan Eich [:brendan]]

Attachment: proposed fix

Comment 4

[Brendan Eich [:brendan]]

Ready for r= and sr=.  The kludge in jsexn.c cures two problems: first, the old
code was suppressing js_GetClassPrototype failure, which is just bad; second, if
the global object has a lazy standard class resolve, as js.c and the DOM window
class do, then this "internal" js_GetClassPrototype might cause a new-resolve
call with JSRESOLVE_ASSIGNING wrongly imputed from the current JSOP_SETCALL or
similar bytecode (e.g., for it.foo('hi')++ where it.foo is undefined).

Obviously, the engine should have a better way to divine new-resolve flags, but
the hack and XXXbe comment will do for now.

The actually compiler changes for reference_returning()++, e.g. it.item('funny')
= 42; it.item('funny')++, were pretty tiny.  I'm happy.

/be

Comment 5

[Brendan Eich [:brendan]]

Attachment: better comment for the XXXbe kludge in jsexn.c

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

+        jsbytecode *pc;
+        JSBool ok;
+
+        fp = cx->fp;
+        pc = NULL;

I think we prefer initialization to declaration-then-inevitable-assignment,
generally.  Change to

+        jsbytecode *pc = NULL;

and sr=shaver.  (I ass-u-me you've run the test suite.)

Comment 7

[Brendan Eich [:brendan]]

Attachment: shaver's feedback incorporated, still need r=

Comment 8

[John Bandhauer]

r=jband (though I'm not as familiar with this code as I could be)

Comment 9

[Brendan Eich [:brendan]]

Fix is in.

/be

Comment 10

[Phil Schwartau]

Marking Verified -