js> this.u.v = 1 typein:1: TypeError: (void 0) is undefined Expected: TypeError: this.u is undefined

Regression from Firefox 2 / JS1.7: $ ../srcmoz18/Darwin_DBG.OBJ/js js> this.u.v = 1 typein:1: TypeError: this.u has no properties js> $ ./Darwin_DBG.OBJ/js js> this.u.v = 1 typein:1: TypeError: (void 0) is undefined js> Regression from patch for bug 363536. /be

See comments in jsopcode.c (the changes to that file are to comments only). /be

I think this might be worth blocking on -- the degraded quality of the error message seems likely to cause confusion. Also, we have a testcase and a (hopefully soon-to-be-reviewed) patch, and this is a regression.

We wouldn't block on it, but we'd take it. Chop chop! :)

Note that this is a one-line (12 char ;-) fix to jsopcode.tbl. The other two file patches contain comment-only changes. The only explicit use of JOF_VARPROP is in Decompile where the comments changed in jsopcode.c. The only effect of changing JSOP_GETTHISPROP's mode from 0 to JOF_VARPROP is to bypass the js_GetSrcNote-must-not-return-null requirement in DecompileExpression (under js_DecompileValueGenerator), since JSOP_GETTHISPROP depends on no "base" expression that was compiled into left-context bytecode that would need a source note whose offset gives the displacement of that base from the faulting op. This opcode stands alone and can start a left-context for later "srcnote-based" ops. So this truly is a low-risk change, and I believe it is a complete fix to the regression. But I crave Igor's review. /be

Comment on attachment 317567 [details] [diff] [review] forgot JOF_VARPROP for JSOP_GETTHISPROP a1.9+=damons

Fixed: js/src/jsopcode.c 3.312 js/src/jsopcode.h 3.66 js/src/jsopcode.tbl 3.115 /be

/cvsroot/mozilla/js/tests/js1_5/Regress/regress-420919.js,v <-- regress-420919.js initial revision: 1.1

v 1.9.0