Closed Bug 1287340 Opened 9 years ago Closed 9 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: evilpies, Assigned: efaust)

References

Details

Attachments

(4 files)

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: