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

Return early on intrinsics in couldContainTypeVariables #54377

Closed
wants to merge 1 commit into from

Conversation

jakebailey
Copy link
Member

Fixes #54348

The problem in the issue is that both source and target are the wildcard type, and so this recurses forever.

But, one thing that fixes this is to just bail early on intrinsics, as those can't actually contain type vars (which then does prevent the inference loop).

I could send a more targeted fix but I think this might actually help perf.

Needs a test.

@typescript-bot typescript-bot added Author: Team For Milestone Bug PRs that fix a bug with a specific milestone labels May 24, 2023
@jakebailey
Copy link
Member Author

@typescript-bot test this
@typescript-bot test top100
@typescript-bot user test this
@typescript-bot run dt
@typescript-bot perf test this faster
@typescript-bot pack this

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 24, 2023

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

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 24, 2023

Heya @jakebailey, I've started to run the extended test suite on this PR at b9aec28. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 24, 2023

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

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 24, 2023

Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at b9aec28. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 24, 2023

Heya @jakebailey, I've started to run the abridged perf test suite on this PR at b9aec28. You can monitor the build here.

Update: The results are in!

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 24, 2023

Heya @jakebailey, I've started to run the tarball bundle task on this PR at b9aec28. You can monitor the build here.

@typescript-bot
Copy link
Collaborator

typescript-bot commented May 24, 2023

Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your package.json like so:

{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/154768/artifacts?artifactName=tgz&fileId=FDA1DBBE3E104BE4A8855C36123A62E2D06692464EB7D44A49F7841DBB25447602&fileName=/typescript-5.2.0-insiders.20230524.tgz"
    }
}

and then running npm install.


There is also a playground for this build and an npm module you can use via "typescript": "npm:@typescript-deploys/pr-build@5.2.0-pr-54377-7".;

@typescript-bot
Copy link
Collaborator

@jakebailey Here are the results of running the user test suite comparing main and refs/pull/54377/merge:

There were infrastructure failures potentially unrelated to your change:

  • 1 instance of "Unknown failure"
  • 1 instance of "Package install failed"

Otherwise...

Everything looks good!

@typescript-bot
Copy link
Collaborator

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

Here they are:

Comparison Report - main..54377

Metric main 54377 Delta Best Worst p-value
Angular - node (v16.17.1, x64)
Memory used 365,254k (± 0.02%) 365,178k (± 0.02%) ~ 365,096k 365,255k p=0.066 n=6
Parse Time 3.58s (± 0.38%) 3.56s (± 0.48%) -0.02s (- 0.65%) 3.53s 3.58s p=0.021 n=6
Bind Time 1.18s (± 0.46%) 1.18s (± 0.35%) ~ 1.17s 1.18s p=0.054 n=6
Check Time 9.62s (± 0.45%) 9.57s (± 0.30%) ~ 9.54s 9.62s p=0.065 n=6
Emit Time 7.99s (± 1.35%) 7.94s (± 0.77%) ~ 7.87s 8.02s p=0.469 n=6
Total Time 22.38s (± 0.60%) 22.24s (± 0.30%) ~ 22.17s 22.34s p=0.065 n=6
Compiler-Unions - node (v16.17.1, x64)
Memory used 193,481k (± 0.70%) 193,468k (± 0.70%) ~ 192,799k 196,242k p=0.521 n=6
Parse Time 1.61s (± 0.52%) 1.60s (± 1.96%) ~ 1.54s 1.62s p=0.196 n=6
Bind Time 0.83s (± 0.49%) 0.83s (± 0.62%) ~ 0.82s 0.83s p=0.595 n=6
Check Time 10.17s (± 0.48%) 10.19s (± 1.03%) ~ 10.07s 10.35s p=0.936 n=6
Emit Time 3.01s (± 0.45%) 3.00s (± 1.02%) ~ 2.96s 3.05s p=0.416 n=6
Total Time 15.61s (± 0.32%) 15.62s (± 0.68%) ~ 15.44s 15.74s p=0.688 n=6
Monaco - node (v16.17.1, x64)
Memory used 345,880k (± 0.00%) 345,882k (± 0.00%) ~ 345,865k 345,900k p=0.689 n=6
Parse Time 2.73s (± 0.68%) 2.73s (± 0.44%) ~ 2.71s 2.74s p=0.806 n=6
Bind Time 1.09s (± 1.07%) 1.09s (± 0.69%) ~ 1.08s 1.10s p=0.734 n=6
Check Time 7.83s (± 0.37%) 7.83s (± 0.65%) ~ 7.76s 7.89s p=0.936 n=6
Emit Time 4.45s (± 0.39%) 4.44s (± 0.93%) ~ 4.38s 4.49s p=0.808 n=6
Total Time 16.10s (± 0.08%) 16.08s (± 0.57%) ~ 15.98s 16.21s p=0.627 n=6
TFS - node (v16.17.1, x64)
Memory used 299,953k (± 0.00%) 299,945k (± 0.01%) ~ 299,918k 299,979k p=0.572 n=6
Parse Time 2.17s (± 0.69%) 2.15s (± 0.39%) ~ 2.15s 2.17s p=0.138 n=6
Bind Time 1.23s (± 0.51%) 1.23s (± 0.84%) ~ 1.22s 1.25s p=0.654 n=6
Check Time 7.28s (± 0.34%) 7.29s (± 0.51%) ~ 7.25s 7.34s p=0.418 n=6
Emit Time 4.36s (± 0.76%) 4.33s (± 1.02%) ~ 4.27s 4.39s p=0.199 n=6
Total Time 15.04s (± 0.37%) 15.01s (± 0.28%) ~ 14.96s 15.08s p=0.469 n=6
material-ui - node (v16.17.1, x64)
Memory used 480,972k (± 0.01%) 480,980k (± 0.00%) ~ 480,949k 481,007k p=0.575 n=6
Parse Time 3.26s (± 0.46%) 3.26s (± 0.25%) ~ 3.25s 3.27s p=1.000 n=6
Bind Time 0.95s (± 0.86%) 0.94s (± 0.55%) ~ 0.94s 0.95s p=0.523 n=6
Check Time 17.89s (± 0.97%) 17.95s (± 1.58%) ~ 17.69s 18.48s p=0.936 n=6
Emit Time 0.00s (± 0.00%) 0.00s (± 0.00%) ~ 0.00s 0.00s p=1.000 n=6
Total Time 22.09s (± 0.81%) 22.15s (± 1.27%) ~ 21.89s 22.67s p=0.936 n=6
xstate - node (v16.17.1, x64)
Memory used 560,641k (± 0.02%) 560,700k (± 0.03%) ~ 560,521k 560,971k p=0.689 n=6
Parse Time 4.02s (± 0.53%) 4.01s (± 0.34%) ~ 3.99s 4.03s p=0.369 n=6
Bind Time 1.77s (± 0.29%) 1.76s (± 0.46%) -0.01s (- 0.56%) 1.75s 1.77s p=0.039 n=6
Check Time 3.06s (± 0.70%) 3.07s (± 0.63%) ~ 3.05s 3.10s p=0.512 n=6
Emit Time 0.09s (± 0.00%) 0.09s (± 0.00%) ~ 0.09s 0.09s p=1.000 n=6
Total Time 8.94s (± 0.40%) 8.93s (± 0.28%) ~ 8.91s 8.97s p=0.870 n=6
System
Machine Namets-ci-ubuntu
Platformlinux 5.4.0-148-generic
Architecturex64
Available Memory16 GB
Available Memory15 GB
CPUs4 × Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
Hosts
  • node (v16.17.1, x64)
Scenarios
  • Angular - node (v16.17.1, x64)
  • Compiler-Unions - node (v16.17.1, x64)
  • Monaco - node (v16.17.1, x64)
  • TFS - node (v16.17.1, x64)
  • material-ui - node (v16.17.1, x64)
  • xstate - node (v16.17.1, x64)
Benchmark Name Iterations
Current 54377 6
Baseline main 6

Developer Information:

Download Benchmark

@typescript-bot
Copy link
Collaborator

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

Everything looks good!

@typescript-bot
Copy link
Collaborator

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

@@ -24004,6 +24004,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker {
// we perform type inference (i.e. a type parameter of a generic function). We cache
// results for union and intersection types for performance reasons.
function couldContainTypeVariables(type: Type): boolean {
if (type.flags & TypeFlags.Intrinsic) return false;
Copy link
Member

Choose a reason for hiding this comment

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

I'm not understanding how the function would previously return true for the wildcard type (which is a TypeFlags.Any)? What am I missing?

Copy link
Member Author

Choose a reason for hiding this comment

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

The place I was referring to was inferTypes, which starts with a wildcard check, but if both sides are a wildcard we loop forever.

But, it checks for "could contain type var" before the wildcard logic.

Copy link
Member

Choose a reason for hiding this comment

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

Right, but assuming both sides are wildcard types, how is it that we loop forever? That would require couldContainTypeVariables to return true for a TypeFlags.Any, and I'm not seeing how that happens.

Copy link
Member Author

Choose a reason for hiding this comment

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

You're totally right that couldContainTypeVariables should already be returning false for wildcardType, and yet, in my example it appeared to be returning true in the debugger!

But now, on main, my test doesn't fail... reverse bisecting says that it was "fixed" by changing lib.d.ts. So, I think there's some really odd corruption happening. Sounds like a fun debugging challenge.

This comment was marked as spam.

Copy link
Member Author

Choose a reason for hiding this comment

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

Just to note the scary thing I'm seeing:

image

Copy link
Member Author

Choose a reason for hiding this comment

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

Traced this down to the new code in #53246, but it's absolutely bizarre. The flag is clearly there that says that "could contain type vars" is computed, and yet it still proceeds to overwrite it for no reason.

Copy link
Member Author

Choose a reason for hiding this comment

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

Figured it out, see #54348 (comment)

@capaj
Copy link

capaj commented Jun 2, 2023

I have tested this on our codebase for @official-love-guru, where both 5.0.4 and 5.1.3 are crashing with

RangeError: Maximum call stack size exceeded
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63010:28)
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63017:9)
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63017:9)
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63017:9)
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63017:9)
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63017:9)
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63017:9)
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63017:9)
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63017:9)
    at inferFromTypes (/home/capaj/work-repos/redacted/node_modules/typescript/lib/tsc.js:63017:9)

and this PR fixes it!

Please merge this.

@jakebailey
Copy link
Member Author

The real fix for this problem is definitely not going to be this PR, per above conversation. I am looking into the actual problem.

@jakebailey jakebailey closed this Jun 2, 2023
@jakebailey jakebailey deleted the fix-54348 branch March 15, 2024 22:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Author: Team For Milestone Bug PRs that fix a bug with a specific milestone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TS 5.1.1-rc: RangeError: Maximum call stack size exceeded
5 participants