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

Use symbols of type aliases when emitting declarations #56087

Merged

Conversation

Andarist
Copy link
Contributor

fixes #49171

@typescript-bot typescript-bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Oct 12, 2023
@@ -5665,6 +5665,12 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
if (getSymbolIfSameReference(exported, symbol)) {
return exported;
}
if (symbol.flags & SymbolFlags.TypeAlias && exported.declarations?.find(isTypeAlias)) {
Copy link
Member

Choose a reason for hiding this comment

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

I think we canonically use our own find helper here to avoid the this penalty; might be important if this is hot code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have literally copied this bit from getDeclaredTypeOfTypeAlias :P
https://github.dev/microsoft/TypeScript/blob/cf8763b6c3193deefd095c86ce79921f23de307b/src/compiler/checker.ts#L12436

Should I switch both call sites to ur custom find?

Copy link
Member

Choose a reason for hiding this comment

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

Hah, then nevermind.

Copy link
Member

@sandersn sandersn Nov 3, 2023

Choose a reason for hiding this comment

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

to avoid the this penalty

The original reason was that find wasn't defined in old runtimes. What is the this penalty? Maybe that's a good replacement reason.

Copy link
Member

Choose a reason for hiding this comment

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

IIRC functions passed to find and other helpers like it are bound such that this in them points to the array.

@@ -5665,6 +5665,12 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
if (getSymbolIfSameReference(exported, symbol)) {
return exported;
}
if (symbol.flags & SymbolFlags.TypeAlias && exported.declarations?.find(isTypeAlias)) {
const aliasSymbol = getDeclaredTypeOfTypeAlias(exported).aliasSymbol;
if (aliasSymbol && getSymbolIfSameReference(aliasSymbol, symbol)) {
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be a change in the logic of getSymbolIfSameReference instead? To make a type alias that points directly at another type count as a "same reference" of that type? It's been reused in one or two other places, but it basically only exists to answer "should we consider these two symbols as ultimately referring to the same thing", and mostly just for the usages here, in this function. In particular, only doing this check here means 1. the fastpath lookup will fail for type aliases that pass this check, so they always hit the slow path and 2. an export ='d type alias will never be considered equal to the target symbol.

@Andarist Andarist requested a review from weswigham November 7, 2023 08:35
@@ -5672,6 +5672,12 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
* Checks if two symbols, through aliasing and/or merging, refer to the same thing
*/
function getSymbolIfSameReference(s1: Symbol, s2: Symbol) {
if (s1.flags & SymbolFlags.TypeAlias && s2.declarations?.find(isTypeAlias)) {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe extract this into another helper function? Seems a bit repetitive.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This checks both s1 and s2 and I don't have any good name for a helper function that would accept both as arguments or other ideas on how to improve this. Everything I have tried locally felt clunky to me.

@Andarist Andarist requested a review from weswigham December 28, 2023 23:26
@weswigham
Copy link
Member

@typescript-bot test this
@typescript-bot run dt
@typescript-bot test top100
@typescript-bot perf test public

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jan 9, 2024

Heya @weswigham, I've started to run the diff-based top-repos suite on this PR at 862603b. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jan 9, 2024

Heya @weswigham, I've started to run the parallelized Definitely Typed test suite on this PR at 862603b. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented Jan 9, 2024

Heya @weswigham, I've started to run the public perf test suite on this PR at 862603b. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

Hey @weswigham, the results of running the DT tests are ready.
Everything looks the same!
You can check the log here.

@typescript-bot
Copy link
Collaborator

@weswigham
The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr
Metric baseline pr Delta Best Worst p-value
self-build-src - node (v20.5.1, x64)
Memory used 2,739,302k (± 5.70%) 2,681,294k (± 5.15%) ~ 2,573,910k 2,922,103k p=0.810 n=6
Parse Time 5.03s (± 1.37%) 5.02s (± 0.82%) ~ 4.95s 5.07s p=0.687 n=6
Bind Time 1.99s (± 0.76%) 2.00s (± 0.88%) ~ 1.97s 2.02s p=0.250 n=6
Check Time 31.97s (± 0.51%) 31.97s (± 0.24%) ~ 31.87s 32.10s p=0.873 n=6
Emit Time 2.76s (± 4.13%) 2.85s (± 3.75%) ~ 2.71s 3.02s p=0.230 n=6
Total Time 41.77s (± 0.42%) 41.84s (± 0.37%) ~ 41.67s 42.08s p=0.575 n=6
self-compiler - node (v20.5.1, x64)
Memory used 418,834k (± 0.01%) 418,888k (± 0.01%) ~ 418,792k 418,937k p=0.093 n=6
Parse Time 2.89s (± 0.81%) 2.88s (± 0.38%) ~ 2.86s 2.89s p=0.934 n=6
Bind Time 1.13s (± 0.46%) 1.14s (± 0.96%) ~ 1.13s 1.16s p=0.247 n=6
Check Time 14.07s (± 0.37%) 14.13s (± 0.51%) ~ 14.07s 14.25s p=0.128 n=6
Emit Time 1.05s (± 1.53%) 1.05s (± 1.47%) ~ 1.04s 1.08s p=0.718 n=6
Total Time 19.14s (± 0.24%) 19.21s (± 0.42%) ~ 19.13s 19.34s p=0.170 n=6
vscode - node (v20.5.1, x64)
Memory used 2,828,077k (± 0.00%) 2,828,057k (± 0.00%) ~ 2,828,032k 2,828,106k p=0.128 n=6
Parse Time 10.73s (± 0.14%) 10.74s (± 0.21%) ~ 10.71s 10.77s p=0.292 n=6
Bind Time 3.43s (± 0.51%) 3.44s (± 0.80%) ~ 3.42s 3.48s p=0.618 n=6
Check Time 56.12s (± 0.50%) 56.12s (± 0.40%) ~ 55.86s 56.37s p=1.000 n=6
Emit Time 16.20s (± 0.34%) 16.18s (± 0.45%) ~ 16.10s 16.27s p=0.376 n=6
Total Time 86.48s (± 0.36%) 86.48s (± 0.28%) ~ 86.16s 86.78s p=0.873 n=6
System info unknown
Hosts
  • node (v20.5.1, x64)
Scenarios
  • self-build-src - node (v20.5.1, x64)
  • self-compiler - node (v20.5.1, x64)
  • vscode - node (v20.5.1, x64)
Benchmark Name Iterations
Current pr 6
Baseline baseline 6

Developer Information:

Download Benchmarks

@typescript-bot
Copy link
Collaborator

@weswigham Here are the results of running the top-repos suite comparing main and refs/pull/56087/merge:

Something interesting changed - please have a look.

Details

chakra-ui/chakra-ui

4 of 28 projects failed to build with the old tsc and were ignored

packages/components/tsconfig.build.json

  • error TS5056: Cannot write file '/mnt/ts_downloads/chakra-ui/packages/components/dist/types/menu/menu.stories.d.ts' because it would be overwritten by multiple input files.
    • Project Scope

@jakebailey
Copy link
Member

I've sent a revert for this in #57849; this PR caused two bugs and a perf regression, so I think it's safest to back it out as it was just to fix a bug that has existed seemingly forever.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
For Uncommitted Bug PR for untriaged, rejected, closed or missing bug
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Portability error issued when reachable source file is redirected to an unreachable target
5 participants