Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[MERGE #5914 @boingoing] Class members which capture super via dot (s…
…uper.constructor) end up getting the wrong value Merge pull request #5914 from boingoing:super_capture_ts Class members which capture super via dot (super.constructor) end up getting the wrong value We were using the wrong bytecode register when emitting LdHomeObjProto in the case of a lambda capturing super via a dot reference. Consider this Javascript: ```javascript class A { } class B extends A { foo() { const _s = () => super.constructor; console.log(_s().name); } } ``` The member function foo correctly stashes this and super but the lambda needs to load them from the environment and it was loading them into the same register. Here's the incorrect bytecode: ``` Function _s ( (#1.5), #6) (In0) (size: 8 [8]) 5 locals (2 temps from R3), 1 inline cache Constant Table: ======== ===== R1 LdRoot Line 13: super.constructor Col 26: ^ 0000 ProfiledLdEnvSlot R3 = [1][2] <0> 0006 ProfiledLdEnvSlot R3 = [1][3] <1> 000c LdHomeObjProto R4 R3 0011 ProfiledLdSuperFld R0 = R4(this=R3). #0 <0> 0019 Br x:001e ( 2) 001c LdUndef R0 ``` With the fix in this PR, here's the bytecode we get for _s: ``` Function _s ( (#1.5), #6) (In0) (size: 8 [8]) 6 locals (3 temps from R3), 1 inline cache Constant Table: ======== ===== R1 LdRoot Line 56: super.constructor Col 26: ^ 0000 ProfiledLdEnvSlot R3 = [1][2] <0> 0006 ProfiledLdEnvSlot R4 = [1][3] <1> 000c LdHomeObjProto R5 R3 0011 ProfiledLdSuperFld R0 = R5(this=R4). #0 <0> 0019 Br x:001e ( 2) 001c LdUndef R0 ```
- Loading branch information