Closed
Bug 94631
Opened 24 years ago
Closed 24 years ago
JSRESOLVE_ASSIGNING broken in JSNewResolveOp
Categories
(Core :: JavaScript Engine, defect, P3)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla0.9.4
People
(Reporter: brendan, Assigned: brendan)
Details
(Keywords: js1.5)
Attachments
(1 file)
|
732 bytes,
patch
|
Details | Diff | Splinter Review |
This busted a while ago (long while), when JSOP_BINDNAME/JSOP_SETNAME split out
of the old JSOP_SETNAME for ECMA purity. Trivial patch coming up.
/be
|
Assignee | |
Updated•24 years ago
|
Status: NEW → ASSIGNED
Keywords: js1.5,
mozilla0.9.4
Priority: -- → P3
Target Milestone: --- → mozilla0.9.4
|
|
Assignee | |
Comment 1•24 years ago
|
||
|
|
Assignee | |
Comment 2•24 years ago
|
||
The case that broke is when JSRESOLVE_QUALIFIED is not set, i.e., when assigning
to an unqualified name ('x = 42').
ECMA-262 requires that 'x' be found on the scope chain before the right-hand
side of = is evaluated, in case the rhs has side effects. JSOP_BINDNAME
therefore causes 'x' to be resolved, but unless the JSOP_BINDNAME opcode has the
JOF_SET opcode format flag set, the JSNewResolve case won't compute
JSRESOLVE_ASSIGNING into flags.
r= and sr= please? Another softball.
/be
|
||
Comment 3•24 years ago
|
||
r=shaver.
|
|
||
Comment 4•24 years ago
|
||
sr=jband
|
|
Assignee | |
Comment 5•24 years ago
|
||
Fix is in, thanks.
/be
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•