Closed Bug 349602 Opened 18 years ago Closed 18 years ago

E4X literal in "let" expression is considered a syntax error

Categories

(Core :: JavaScript Engine, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.8.1

People

(Reporter: jruderman, Assigned: brendan)

References

Details

(Keywords: testcase, verified1.8.1)

Attachments

(1 file)

> function () { let(a=3) 1 ? <x/> : 2 } function () { let (a = 3) <x/>; } > function () { let (a = 3) <x/>; } SyntaxError on line 1: syntax error I think the bug is that the second is considered a syntax error.
Attached patch fix (deleted) — Splinter Review
TSF_OPERAND twiddling, plus cleanup in the TOK_LET: case of Statement's switch. /be
Assignee: general → brendan
Status: NEW → ASSIGNED
Attachment #234910 - Flags: review?(mrbkap)
Trivial fix to oversight in let implementation. /be
Blocks: js1.7let
Flags: blocking1.8.1?
OS: Mac OS X 10.4 → All
Priority: -- → P2
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.8.1
Flags: blocking1.8.1? → blocking1.8.1+
Attachment #234910 - Flags: review?(mrbkap) → review+
Comment on attachment 234910 [details] [diff] [review] fix Fixed on trunk: Checking in jsparse.c; /cvsroot/mozilla/js/src/jsparse.c,v <-- jsparse.c new revision: 3.205; previous revision: 3.204 done /be
Attachment #234910 - Flags: approval1.8.1?
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment on attachment 234910 [details] [diff] [review] fix a=schrep for drivers
Attachment #234910 - Flags: approval1.8.1? → approval1.8.1+
Fixed on the 1.8 branch using cvs up -j to auto-merge, cleanly. /be
Keywords: fixed1.8.1
Checking in regress-349602.js; /cvsroot/mozilla/js/tests/js1_7/expressions/regress-349602.js,v <-- regress-349602.js initial revision: 1.1
Flags: in-testsuite+
js1_7/expressions/regress-349602.js 1.8 20060824 winxp/linux/mactel JS_ASSERT(pn->pn_op == JSOP_LEAVEBLOCKEXPR); > js3250.dll!Statement(JSContext * cx=0x03d14a58, JSTokenStream * ts=0x048e66c0, JSTreeContext * tc=0x0012e60c) Line 2934 + 0x26 bytes C js3250.dll!Statements(JSContext * cx=0x03d14a58, JSTokenStream * ts=0x048e66c0, JSTreeContext * tc=0x0012e60c) Line 1138 + 0x11 bytes C js3250.dll!FunctionBody(JSContext * cx=0x03d14a58, JSTokenStream * ts=0x048e66c0, JSFunction * fun=0x0486c340, JSTreeContext * tc=0x0012e60c) Line 724 + 0x11 bytes C js3250.dll!FunctionDef(JSContext * cx=0x03d14a58, JSTokenStream * ts=0x048e66c0, JSTreeContext * tc=0x0012e808, int lambda=0) Line 1029 + 0x15 bytes C js3250.dll!FunctionStmt(JSContext * cx=0x03d14a58, JSTokenStream * ts=0x048e66c0, JSTreeContext * tc=0x0012e808) Line 1106 + 0x13 bytes C js3250.dll!Statement(JSContext * cx=0x03d14a58, JSTokenStream * ts=0x048e66c0, JSTreeContext * tc=0x0012e808) Line 2250 + 0x11 bytes C js3250.dll!Statements(JSContext * cx=0x03d14a58, JSTokenStream * ts=0x048e66c0, JSTreeContext * tc=0x0012e808) Line 1138 + 0x11 bytes C js3250.dll!js_CompileTokenStream(JSContext * cx=0x03d14a58, JSObject * chain=0x048cf9c0, JSTokenStream * ts=0x048e66c0, JSCodeGenerator * cg=0x0012e808) Line 501 + 0x11 bytes C js3250.dll!CompileTokenStream(JSContext * cx=0x03d14a58, JSObject * obj=0x048cf9c0, JSTokenStream * ts=0x048e66c0, void * tempMark=0x03d14aa0, int * eofp=0x00000000) Line 3843 + 0x1a bytes C js3250.dll!JS_CompileUCScriptForPrincipals(JSContext * cx=0x03d14a58, JSObject * obj=0x048cf9c0, JSPrincipals * principals=0x033333d4, const unsigned short * chars=0x048c13c0, unsigned int length=33, const char * filename=0x048c1651, unsigned int lineno=57) Line 3938 + 0x17 bytes C js3250.dll!obj_eval(JSContext * cx=0x03d14a58, JSObject * obj=0x048435a0, unsigned int argc=1, long * argv=0x048720e4, long * rval=0x0012eab0) Line 1331 + 0xd7 bytes C js3250.dll!js_Invoke(JSContext * cx=0x03d14a58, unsigned int argc=1, unsigned int flags=0) Line 1350 + 0x1a bytes C js3250.dll!js_Interpret(JSContext * cx=0x03d14a58, unsigned char * pc=0x048d7e5b, long * result=0x0012f5d8) Line 4055 + 0xf bytes C js3250.dll!js_Execute(JSContext * cx=0x03d14a58, JSObject * chain=0x048435a0, JSScript * script=0x048c17a8, JSStackFrame * down=0x00000000, unsigned int flags=0, long * result=0x0012f6e8) Line 1599 + 0x13 bytes C js3250.dll!JS_EvaluateUCScriptForPrincipals(JSContext * cx=0x03d14a58, JSObject * obj=0x048435a0, JSPrincipals * principals=0x033333d4, const unsigned short * chars=0x048d4c08, unsigned int length=2496, const char * filename=0x03471420, unsigned int lineno=1, long * rval=0x0012f6e8) Line 4365 + 0x19 bytes C gklayout.dll!nsJSContext::EvaluateString(const nsAString_internal & aScript={...}, void * aScopeObject=0x048435a0, nsIPrincipal * aPrincipal=0x033333d0, const char * aURL=0x03471420, unsigned int aLineNo=1, const char * aVersion=0x1010c434, nsAString_internal * aRetValue=0x00000000, int * aIsUndefined=0x0012f74c) Line 1098 + 0x43 bytes C++ verified fixed 1.9 20060824 windows/mac*/linux
Status: RESOLVED → VERIFIED
Whiteboard: [not-fixed1.8.1]
Works for me in my 1.8-branch-based js shell: $ ./Darwin_DBG.OBJ/js -f js1_7/shell.js -f js1_7/expressions/shell.js -f js1_7/expressions/regress-349602.js Starting program: /Users/brendaneich/Hacking/trunk/mozilla/js/srcmoz18/Darwin_DBG.OBJ/js -f js1_7/shell.js -f js1_7/expressions/shell.js -f js1_7/expressions/regress-349602.js Reading symbols for shared libraries .. done BUGNUMBER: 349602 STATUS: decompilation of let with e4x literal $ Bob, can you reproduce in a branch-based shell? /be
yep. I just updated and rebuilt js shell on winxp, mactel, macppc, linux and still get it.
I meant to ask if you are sure everything in your tree has been committed?
Yes, I don't get this with trunk or branch. If you get it in the js shell built from the tip of the 1.8 branch, can you debug a bit and print (JSOp)pn->pn_op? /be
(In reply to comment #11) pn->pn_op == 0 - pn 0x0042b570 {pn_type=??? pn_op=??? pn_arity=??? ...} JSParseNode * pn_type 2 unsigned short pn_op 0 unsigned char pn_arity 1 '&#9217;' char + pn_pos {begin=??? end"=??? } JSTokenPos pn_offset -623191334 int + pn_u {func=??? list=??? ternary=??? ...} __unnamed + pn_next 0x00000000 {pn_type=??? pn_op=??? pn_arity=??? ...} JSParseNode * + pn_ts 0x0042af50 {tokens=??? cursor=??? lookahead=??? ...} JSTokenStream *
(In reply to comment #12) still reproducible 1.8 20060827 all platforms
1.8 20060831 windows/mac*/linux: I still get the Assertion failure: pn->pn_op == JSOP_LEAVEBLOCKEXPR
(In reply to comment #14) > 1.8 20060831 windows/mac*/linux: I still get the Assertion failure: pn->pn_op > == JSOP_LEAVEBLOCKEXPR I get that too in my 1.8 branch js shell, but it's fixed on the trunk. By what checkin, for what bug? I can't recall off the top of my head. Anyone know? /be
Bug 349818, perhaps?
(In reply to comment #16) > Bug 349818, perhaps? Thanks! Fixed on 1.8 branch now. /be
verified fixed 1.8 20060901 windows/mac*/linux
Whiteboard: [not-fixed1.8.1]
update test to match (expr); behavior. Checking in regress-349602.js; /cvsroot/mozilla/js/tests/js1_7/expressions/regress-349602.js,v <-- regress-349602.js new revision: 1.3; previous revision: 1.2 done
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: