Closed Bug 1287340 Opened 8 years ago Closed 8 years ago

Subclassing bound functions is wrong

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox51 --- fixed

People

(Reporter: evilpie, Assigned: efaust)

References

Details

Attachments

(4 files)

At least this is was https://github.com/tc39/test262/pull/720 claims.
I'll take a look. Thanks for finding this.
Assignee: nobody → efaustbmo
This is noisy, but simple. We just have a lot of arms that are split out to avoid function call overhead. The test tries to exercise every case.
Attachment #8777993 - Flags: review?(till)
Comment on attachment 8777991 [details] [diff] [review]
Part 1: Add constructContentFunction to allow self-hosted code to pass new.target directly without calling Reflect.construct

Review of attachment 8777991 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. Except for the browser_contextmenu.js changes, which don't seem to belong here.
Attachment #8777991 - Flags: review?(till) → review+
Comment on attachment 8777993 [details] [diff] [review]
Part 2: Fix Function.prototype.bind to correctly pass new.target through to bound functions.

Review of attachment 8777993 [details] [diff] [review]:
-----------------------------------------------------------------

Given that _IsConstructing isn't used anymore - and doesn't have any potential uses - r=me on ripping that out.

Also, it'd be really good to do at least some cursory benchmark testing of this. Jandem and I invested too much work in making this fast to now go and accidentally slow it down.

::: js/src/builtin/Function.js
@@ +306,4 @@
>        default:
>          assert(a.length !== 0,
>                 "bound function construction without args should be handled by caller");
> +        return _ConstructFunction(fun, newTarget, a);

I think this intrinsic should be renamed now. _VariadicConstructFunction, perhaps?

::: js/src/tests/ecma_6/Class/boundFunctionSubclassing.js
@@ +16,5 @@
> +// Check that we actually pass the proper new.target when calling super()
> +function toBind() { }
> +
> +var boundArgs = [];
> +for (let i = 0; i < 5; i++) {

Perhaps let this go to something like 50? We might increase the amount of unrolling we do at some point in the future, and we might mess it up.
Attachment #8777993 - Flags: review?(till) → review+
Can this land?
Make the most common use cases take fewer branches.
Attachment #8783586 - Flags: review?(hv1989)
These last two changes fix the perf problems I was seeing locally for the non-constructing case. The constructing case is still slightly slower, but it's just doing more work.
Comment on attachment 8783587 [details] [diff] [review]
Part 4: Isolate extra branches in the constructing case to the constructing case for perf reasons

Review of attachment 8783587 [details] [diff] [review]:
-----------------------------------------------------------------

r=me
Attachment #8783587 - Flags: review?(till) → review+
Attachment #8783586 - Flags: review?(hv1989) → review+
Pushed by efaustbmo@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/764d9165ede6
Part 1: Implement constructContentFunction for self-hosted code. (r=till)
https://hg.mozilla.org/integration/mozilla-inbound/rev/c8e8e8603716
Part 2: Improve new.target jit performance. (r=h4writer)
https://hg.mozilla.org/integration/mozilla-inbound/rev/56b2e554763a
Part 3: Properly forward new.target in bound function subclassing. (r=till)
Part 2 and 4 landed together as part 3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: