Skip to content
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

Eliminate (ts as any).SyntaxKind (and similar) in favor of Debug.format functions #49485

Merged
merged 1 commit into from
Jun 10, 2022

Conversation

jakebailey
Copy link
Member

This is a change pulled off of my module transform branch; these uses of ts are often the only uses of ts in a file, so it's advantageous to remove them.

But it also has the benefit of not duplicating logic to get the name of a SyntaxKind or similar; you can see in the baselines that there are nodes that are incorrectly printed as "FirstNode". The harness code previously duplicated its own SyntaxKind printer and hardcoded a couple of markers, but formatSyntaxKind is smart enough to do that on its own.

@typescript-bot typescript-bot added Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Jun 10, 2022
@@ -379,8 +379,9 @@ namespace ts {
JSDocFunctionType,
JSDocVariadicType,
JSDocNamepathType, // https://jsdoc.app/about-namepaths.html
JSDoc,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've moved this up here because our debug helpers choose the earliest name as the printed name. It was previously defined with the markers, which meant we printed out the deprecated form instead.

Comment on lines -179 to -188
if (k === (ts as any).SyntaxKind.FirstJSDocNode ||
k === (ts as any).SyntaxKind.LastJSDocNode ||
k === (ts as any).SyntaxKind.FirstJSDocTagNode ||
k === (ts as any).SyntaxKind.LastJSDocTagNode) {
for (const kindName in (ts as any).SyntaxKind) {
if ((ts as any).SyntaxKind[kindName] === k) {
return kindName;
}
}
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using ts.Debug.formatSyntaxKind is slower because it does a lot more work than these 4 hardcoded things. To regain the perf, I have another PR that will make formatSyntaxKind faster.

I still think it's better to not write the same enum-member-to-string code more than once, but it's annoying that a perf fix is required to do it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#49487 recovers the performance; it's 25% of the test run :(

@jakebailey jakebailey merged commit e9ba547 into microsoft:main Jun 10, 2022
@jakebailey jakebailey deleted the ts-as-any-syntaxkind branch June 10, 2022 23:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants