Testcase: ```js var called = null class B { constructor() { called = 'B' } } class C extends B {} B.prototype.constructor = function F() { called = 'F' } new C called // should be 'B', is 'F' ``` It seems to me that JSC follows an old drafted semantics of `super()`, when it was equivalent to `super.constructor()`. For reference, see the runtime semantics of `SuperCall : super Arguments` in the final spec: http://www.ecma-international.org/ecma-262/6.0/#sec-super-keyword-runtime-semantics-evaluation and pay attention to the definition of GetSuperConstructor(): http://www.ecma-international.org/ecma-262/6.0/#sec-getsuperconstructor
Created attachment 262857 [details] Patch
Created attachment 262858 [details] Patch
Comment on attachment 262858 [details] Patch r=me Does the latest spec change the "emitSuperBaseForCallee" static function in BytecodeGenerator?
(In reply to comment #3) > Comment on attachment 262858 [details] > Patch > > r=me > Does the latest spec change the "emitSuperBaseForCallee" static function in > BytecodeGenerator? Yup. emitSuperBaseForCallee is correct in the latest spec :) http://ecma-international.org/ecma-262/6.0/#sec-getsuperbase
Comment on attachment 262858 [details] Patch Clearing flags on attachment: 262858 Committed r190847: <http://trac.webkit.org/changeset/190847>
All reviewed patches have been landed. Closing bug.