If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

ecma_3/Function/arguments-002.js FAIL

VERIFIED FIXED in mozilla1.9beta3

Status

()

Core
JavaScript Engine
P1
normal
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: bc, Assigned: brendan)

Tracking

({regression, testcase})

Trunk
mozilla1.9beta3
regression, testcase
Points:
---
Bug Flags:
blocking1.9 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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

10 years ago
Keywords: regression, testcase
(Reporter)

Comment 1

10 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

10 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

10 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

10 years ago
Created attachment 292644 [details] [diff] [review]
minimal fix

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

10 years ago
Created attachment 292645 [details] [diff] [review]
diff -w version of last attachment
(Reporter)

Comment 6

10 years ago
(In reply to comment #4)
> 
> Bob, could you please test this hard?

can do today.

Updated

10 years ago
Attachment #292644 - Flags: review?(igor) → review+
(Assignee)

Updated

10 years ago
Attachment #292644 - Flags: approval1.9+
(Assignee)

Comment 7

10 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
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Updated

10 years ago
Duplicate of this bug: 384851
(Reporter)

Comment 9

10 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

10 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.