-
Notifications
You must be signed in to change notification settings - Fork 13.2k
More reliable mechanism for _this/_super simplification
#56130
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
Conversation
|
@typescript-bot perf test |
|
Heya @rbuckton, I've started to run the regular perf test suite on this PR at 21a697d. You can monitor the build here. Update: The results are in! |
|
@rbuckton Here they are:
CompilerComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
StartupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| var D = /** @class */ (function (_super) { | ||
| __extends(D, _super); | ||
| function D() { | ||
| var _this = _super.call(this, 1, 2) || this; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it intentional to leave this unused variable behind? I guess it's harmless?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes and no. It's intentional in that the conditions for the simplification that elides var _this = isn't met. We could change the rules, in the future if necessary, but I don't want to spend too much time processing these simplifications during emit, which are primarily only to improve readability when debugging unmapped outputs, so I've generally opted for more coarse-grained rules.
|
I'm going to make a small update to make |
|
Looks like you're introducing a change to the public API surface area. If this includes breaking changes, please document them on our wiki's API Breaking Changes page. Also, please make sure @DanielRosenwasser and @RyanCavanaugh are aware of the changes, just as a heads up. |
… from other 'updateX' methods
This changes the somewhat fragile way we handled the simplification of constructor body statements when transforming
super()that became even more fragile in TS 5.2. These simplifications were intended to slim down transformed constructor bodies when a temporary variable like_thismay not be necessary:However, when
usingwas introduced in TS 5.2, the simplification mechanism became more complicated as thesuper()statements we would normally look for would be moved inside of atry..catch..finallyblock if the constructor contained ausingdeclaration.Rather than try to handle specific
super()simplifications when initially visiting the constructor body, this PR instead performs these simplifications in a second pass after the initial transformation completes. This results in a mechanism that is more reliable than the prior approach as it only performs these simplifications with complete knowledge of the transformed result..Fixes #55646
Fixes #55637