Closed
Bug 396584
Opened 17 years ago
Closed 17 years ago
ecma_3/Function/arguments-002.js FAIL
Categories
(Core :: JavaScript Engine, defect, P1)
Core
JavaScript Engine
Tracking
()
VERIFIED
FIXED
mozilla1.9beta3
People
(Reporter: bc, Assigned: brendan)
References
Details
(Keywords: regression, testcase)
Attachments
(2 files)
2.05 KB,
patch
|
igor
:
review+
brendan
:
approval1.9+
|
Details | Diff | Splinter Review |
1.44 KB,
patch
|
Details | Diff | Splinter Review |
Caused by attachment 268559 [details] [diff] [review] in bug 383269 comment 44 Expected value '33,42:33', Actual value '33,[object Object]:33'
Flags: in-testsuite+
Reporter | ||
Updated•17 years ago
|
Keywords: regression,
testcase
Reporter | ||
Comment 1•17 years ago
|
||
I hate regressions but since finding them and getting them fixed gives my life meaning, nominating for 1.9.
Flags: blocking1.9?
Assignee | ||
Comment 2•17 years ago
|
||
Either call_resolve must resolve arguments whether or not JOF_ASSIGNING (aka JOF_SET) is set for JSOP_BINDNAME, or JSOP_BINDNAME should not have that flag in its opcode format. Independently, we should reduce redundant JOF_SET|...JOF_ASSIGNING to JOF_SET in jsopcode.tbl. /be
Assignee: general → brendan
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.9 M11
Assignee | ||
Comment 3•17 years ago
|
||
When a property becomes lazily bound *without JSPROP_SHARED* in a prototype via a class resolve hook, and that property has a setter (whether specialized or class setProperty hook, doesn't matter) that must run even when the property is being set in a delegating object (which normally shadows the proto-property, making its setter uninteresting), then resolve must not filter on JSRESOLVE_ASSIGNING. So I am going to attempt a minimal change to call_resolve and leave jsopcode.tbl alone until bug 407954 (someone please grab that, it's trivial but nice to have). /be
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•17 years ago
|
||
diff -w version next. Bob, could you please test this hard? I haven't got a good baseline and have other commitments, so could use a proof that this doesn't regress any fixed bugs. /be
Attachment #292644 -
Flags: review?(igor)
Assignee | ||
Comment 5•17 years ago
|
||
Reporter | ||
Comment 6•17 years ago
|
||
(In reply to comment #4) > > Bob, could you please test this hard? can do today.
Updated•17 years ago
|
Attachment #292644 -
Flags: review?(igor) → review+
Assignee | ||
Updated•17 years ago
|
Attachment #292644 -
Flags: approval1.9+
Assignee | ||
Comment 7•17 years ago
|
||
Fixed, optimizing for the case where the patch does indeed cause no regressions: js/src/jsfun.c 3.240 Please file a followup bug if there is an apparent regression. Thanks, /be
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 9•17 years ago
|
||
Looks good on the test tinderboxen for shell linux, macppc. I'll verify when I do better os coverage and have browser results.
Reporter | ||
Comment 10•17 years ago
|
||
verified fixed 1.9.0 Checking in public-failures.txt; /cvsroot/mozilla/js/tests/public-failures.txt,v <-- public-failures.txt new revision: 1.10; previous revision: 1.9 done
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•