Closed
Bug 396584
Opened 18 years ago
Closed 18 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•18 years ago
|
Keywords: regression,
testcase
| Reporter | ||
Comment 1•18 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•18 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•18 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•18 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•18 years ago
|
||
| Reporter | ||
Comment 6•18 years ago
|
||
(In reply to comment #4)
>
> Bob, could you please test this hard?
can do today.
Updated•18 years ago
|
Attachment #292644 -
Flags: review?(igor) → review+
| Assignee | ||
Updated•18 years ago
|
Attachment #292644 -
Flags: approval1.9+
| Assignee | ||
Comment 7•18 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: 18 years ago
Resolution: --- → FIXED
| Reporter | ||
Comment 9•18 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•18 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
•