-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove oldest ES6 feature switches #6
Comments
+1 with an exclamation point I’d argue for getting rid of switches that enable any feature that is not experimental in Chakra and is well-baked in the language – meaning that we’re not going to find ourselves in a world without feature x, even if there are kinks to work out in the spec. So, for instance, I’d get rid of ES6StringTemplate, too. Maybe everything on the list. This goes double for switches that enable syntax, because without the switch you can’t run a test that has the syntax in it, anyway, so such a switch is almost always useless noise. |
Re issue chakra-core#6 Also add ThreadConfigFlagsList.h to the VS solution.
Re issue chakra-core#6 Removes -ES6Math -ES6Number -ES6Object and -ES6String API extension feature switches. Also removed unused ScriptContext function SupportsES3.
Re issue chakra-core#6 Also fixed up initialization of Array.prototype.values function.
Re issue chakra-core#6 Also add ThreadConfigFlagsList.h to the VS solution.
Re issue chakra-core#6 Also fixed up initialization of Array.prototype.values function.
Merge pull request #86 from ianwjhalliday:rmfeatureswitches Addresses #6. Though there are a few more switches remain that I believe would be good to remove. Removes the following switches: - `LetConst` - `Map` - `Set` - `WeakMap` - `ES6WeakSet` - `DefineGetterSetter` - `__proto__` - `ES6Iterators` - `ES6Lambda` - `ES6NumericLiteral` - `ES6StringTemplate` - `ES6Symbol` - `TDZ` With the removal of `-LetConst` a couple of predicates become always true and have been removed. They are: - `BindDeferredPidRefs()` - `IsBlockScopeEnabled()` Parser binding had specific logic to handle catch scopes in non-block scope mode to support legacy ES5 behavior. This has also been removed. Finally `Parser::CheckStrictModeFncDeclNotSourceElement()` no longer did anything so it has also been removed.
Re issue chakra-core#6 Removes -ES6Math -ES6Number -ES6Object and -ES6String API extension feature switches. Also removed unused ScriptContext function SupportsES3.
This suggestion is something we will gradually make progress on regardless of whether there is an open issue and will never be, in spirit, "done" because there will always be more feature flags. Therefore, I'm closing this issue. /cc @kfarnung @agarwal-sandeep |
…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 ( (chakra-core#1.5), chakra-core#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 ( (chakra-core#1.5), chakra-core#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 ```
…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 ```
Here's my reasoning:
Switches that I believe are reasonable to remove with no risk at this time:
Switches that I think are reasonable to remove but there might still be low risk in the feature having bugs or causing issues:
The text was updated successfully, but these errors were encountered: