Skip to content

Fixed false positive circular errors for await expressions with simple non-generic calls in CFA loops - #51126

Merged
Ron Buckton (rbuckton) merged 4 commits into
microsoft:mainfrom
Andarist:fix/51115
Jan 9, 2023
Merged

Ron Buckton (rbuckton) merged 4 commits into
microsoft:mainfrom
Andarist:fix/51115

Conversation

@Andarist

Copy link
Copy Markdown
Contributor

@typescript-bot TypeScript Bot (typescript-bot) added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Oct 10, 2022
Comment thread src/compiler/checker.ts Outdated
Comment on lines +35351 to +35354
if (isAwaitExpression(expr)) {
const type = getQuickTypeOfExpression(expr.expression);
return type ? getAwaitedType(type) : undefined;
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

this is the core of the fix

Comment thread src/compiler/checker.ts Outdated
Comment on lines -35356 to -35358
if (type) {
return type;
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

just removed a somewhat redundant lines, replaced that with direct return in the statement above this

Comment thread src/compiler/checker.ts Outdated
}
else if (node.kind === SyntaxKind.NumericLiteral || node.kind === SyntaxKind.StringLiteral ||
node.kind === SyntaxKind.TrueKeyword || node.kind === SyntaxKind.FalseKeyword) {
else if (isLiteralExpression(node)) {

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

a bonus optimization~ (?), we now handle here all literal expressions - instead of just a subset of them

@@ -0,0 +1,137 @@
// @strict: true

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I basically just copy-pasted existing controlFlowIterationErrors test case and I converted all of the functions to be async.

In reality, only the last two cases changed behavior with this PR so maybe I should limit what had been added to this test case? Either way, happy to clean up if needed - for now I've left those alone.

}
}

// repro #51115

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Here, we have the new test cases - based on the reported issues. They are very same-ish, but I've figured out that it still might be worthwhile to commit all of them.

function foo(x: A): string { return "abc"; }

class C {
// Error expected

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

this was outdated, no error is being reported here (and no error has to be reported here)

@DanielRosenwasser

Copy link
Copy Markdown
Member

@typescript-bot

TypeScript Bot (typescript-bot) commented Oct 13, 2022 •

Copy link
Copy Markdown
Contributor

Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the extended test suite on this PR at d234453. You can monitor the build here.

@typescript-bot

TypeScript Bot (typescript-bot) commented Oct 13, 2022 •

Copy link
Copy Markdown
Contributor

Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the tarball bundle task on this PR at d234453. You can monitor the build here.

@typescript-bot

TypeScript Bot (typescript-bot) commented Oct 13, 2022 •

Copy link
Copy Markdown
Contributor

Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the diff-based top-repos suite on this PR at d234453. You can monitor the build here.

Update: The results are in!

@typescript-bot

TypeScript Bot (typescript-bot) commented Oct 13, 2022 •

Copy link
Copy Markdown
Contributor

Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the abridged perf test suite on this PR at d234453. You can monitor the build here.

Update: The results are in!

@typescript-bot

TypeScript Bot (typescript-bot) commented Oct 13, 2022 •

Copy link
Copy Markdown
Contributor

Heya Daniel Rosenwasser (@DanielRosenwasser), I've started to run the diff-based user code test suite on this PR at d234453. You can monitor the build here.

Update: The results are in!

@typescript-bot

TypeScript Bot (typescript-bot) commented Oct 13, 2022 •

Copy link
Copy Markdown
Contributor

Hey Daniel Rosenwasser (@DanielRosenwasser), 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/136430/artifacts?artifactName=tgz&fileId=9B3006D275F0EA09F638A393790CE87BC74B4B76EAC17118457E41CC6CB425F902&fileName=/typescript-4.9.0-insiders.20221013.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@4.9.0-pr-51126-6".;

@typescript-bot

Copy link
Copy Markdown
Contributor

Daniel Rosenwasser (@DanielRosenwasser) Here are the results of running the user test suite comparing main and refs/pull/51126/merge:

Everything looks good!

@typescript-bot

Copy link
Copy Markdown
Contributor

Daniel Rosenwasser (@DanielRosenwasser)
The results of the perf run you requested are in!

Here they are:

Comparison Report - main..51126

Metric main 51126 Delta Best Worst
Angular - node (v16.17.1, x64)
Memory used 352,408k (± 0.02%) 352,359k (± 0.02%) -49k (- 0.01%) 352,210k 352,447k
Parse Time 1.89s (± 0.93%) 1.89s (± 0.68%) +0.00s (+ 0.05%) 1.86s 1.92s
Bind Time 0.75s (± 0.50%) 0.74s (± 0.50%) -0.00s (- 0.00%) 0.74s 0.75s
Check Time 5.69s (± 0.66%) 5.67s (± 0.64%) -0.03s (- 0.46%) 5.61s 5.78s
Emit Time 6.11s (± 0.89%) 6.10s (± 0.79%) -0.01s (- 0.18%) 5.99s 6.21s
Total Time 14.44s (± 0.62%) 14.40s (± 0.55%) -0.04s (- 0.27%) 14.25s 14.59s
Compiler-Unions - node (v16.17.1, x64)
Memory used 198,083k (± 0.48%) 197,742k (± 0.36%) -341k (- 0.17%) 197,347k 200,627k
Parse Time 0.78s (± 0.95%) 0.79s (± 1.12%) +0.00s (+ 0.51%) 0.78s 0.82s
Bind Time 0.46s (± 1.27%) 0.46s (± 0.74%) 0.00s ( 0.00%) 0.45s 0.46s
Check Time 6.47s (± 0.54%) 6.48s (± 0.78%) +0.01s (+ 0.12%) 6.35s 6.59s
Emit Time 2.30s (± 0.77%) 2.31s (± 0.65%) +0.01s (+ 0.61%) 2.27s 2.34s
Total Time 10.01s (± 0.43%) 10.03s (± 0.70%) +0.02s (+ 0.19%) 9.84s 10.19s
Monaco - node (v16.17.1, x64)
Memory used 331,133k (± 0.01%) 331,106k (± 0.01%) -27k (- 0.01%) 331,016k 331,231k
Parse Time 1.44s (± 0.81%) 1.43s (± 0.74%) -0.01s (- 0.35%) 1.42s 1.46s
Bind Time 0.69s (± 0.83%) 0.69s (± 0.68%) 0.00s ( 0.00%) 0.68s 0.70s
Check Time 5.45s (± 0.26%) 5.49s (± 0.40%) +0.04s (+ 0.72%) 5.46s 5.54s
Emit Time 3.25s (± 0.67%) 3.25s (± 0.62%) +0.00s (+ 0.03%) 3.21s 3.31s
Total Time 10.83s (± 0.36%) 10.86s (± 0.31%) +0.03s (+ 0.31%) 10.79s 10.94s
TFS - node (v16.17.1, x64)
Memory used 294,059k (± 0.02%) 294,099k (± 0.01%) +40k (+ 0.01%) 294,043k 294,152k
Parse Time 1.24s (± 1.63%) 1.22s (± 1.67%) -0.02s (- 1.21%) 1.17s 1.26s
Bind Time 0.64s (± 1.09%) 0.65s (± 1.05%) +0.01s (+ 0.78%) 0.63s 0.66s
Check Time 5.12s (± 0.38%) 5.12s (± 0.57%) 0.00s ( 0.00%) 5.06s 5.21s
Emit Time 3.49s (± 0.52%) 3.47s (± 0.72%) -0.02s (- 0.52%) 3.43s 3.55s
Total Time 10.49s (± 0.38%) 10.46s (± 0.55%) -0.03s (- 0.25%) 10.32s 10.55s
material-ui - node (v16.17.1, x64)
Memory used 438,335k (± 0.00%) 438,357k (± 0.01%) +22k (+ 0.00%) 438,329k 438,448k
Parse Time 1.72s (± 0.84%) 1.75s (± 1.04%) +0.03s (+ 1.63%) 1.71s 1.78s
Bind Time 0.54s (± 0.96%) 0.54s (± 0.88%) +0.00s (+ 0.74%) 0.53s 0.55s
Check Time 12.59s (± 0.82%) 12.52s (± 0.53%) -0.07s (- 0.54%) 12.38s 12.71s
Emit Time 0.00s (± 0.00%) 0.00s (± 0.00%) 0.00s ( NaN%) 0.00s 0.00s
Total Time 14.85s (± 0.65%) 14.81s (± 0.45%) -0.04s (- 0.27%) 14.67s 15.00s
xstate - node (v16.17.1, x64)
Memory used 554,486k (± 0.02%) 554,369k (± 0.01%) -118k (- 0.02%) 554,251k 554,557k
Parse Time 2.31s (± 0.39%) 2.32s (± 0.46%) +0.01s (+ 0.39%) 2.30s 2.34s
Bind Time 0.89s (± 2.20%) 0.89s (± 1.69%) -0.00s (- 0.34%) 0.88s 0.95s
Check Time 1.43s (± 0.58%) 1.43s (± 0.58%) +0.01s (+ 0.63%) 1.41s 1.45s
Emit Time 0.07s (± 0.00%) 0.07s (± 0.00%) 0.00s ( 0.00%) 0.07s 0.07s
Total Time 4.69s (± 0.28%) 4.71s (± 0.37%) +0.01s (+ 0.30%) 4.67s 4.75s
System
Machine Namets-ci-ubuntu
Platformlinux 5.4.0-126-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 51126 10
Baseline main 10

Developer Information:

Download Benchmark

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Without knowing much about this code path, I think this is reasonable. The only risk is the call to getAwaitedType which I think has re-entrance issues - but that issue is open at #42948.

With another sign-off, I would be okay with merging for 4.9, as it feels like a bug-fix.

@typescript-bot

Copy link
Copy Markdown
Contributor

Daniel Rosenwasser (@DanielRosenwasser) Here are the results of running the top-repos suite comparing main and refs/pull/51126/merge:

Everything looks good!

@Andarist

Copy link
Copy Markdown
Contributor Author

Daniel Rosenwasser (@DanielRosenwasser) huh, luckily... I've fixed that particular issue a couple of months ago in this PR :) I've created a PR with an extra test case that will close that issue: #51167

@DanielRosenwasser Daniel Rosenwasser (DanielRosenwasser) added the Merge/Review for Next Release This PR should be re-reviewed and merged ASAP for the next release. label Oct 28, 2022
@sandersn

Copy link
Copy Markdown
Member

Daniel Rosenwasser (@DanielRosenwasser) is this ready to merge now? (Once it's up-to-date with main)

@DanielRosenwasser

Copy link
Copy Markdown
Member

You probably want to get Anders Hejlsberg (@ahejlsberg) to take a look at it in case I missed anything.

# Conflicts:
#	src/compiler/checker.ts
@Andarist

Copy link
Copy Markdown
Contributor Author

Nathan Shively-Sanders (@sandersn) it's up to date now :)

@Andarist

Copy link
Copy Markdown
Contributor Author

friendly 🏓 since this has been labeled with "Merge/Review for Next Release" and the 5.0 Beta is going to be published in 2 weeks

Comment thread src/compiler/checker.ts Outdated
}
else if (node.kind === SyntaxKind.NumericLiteral || node.kind === SyntaxKind.StringLiteral ||
node.kind === SyntaxKind.TrueKeyword || node.kind === SyntaxKind.FalseKeyword) {
else if (isLiteralExpression(node)) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why did this change? isLiteralExpression doesn't cover TrueKeyword/FalseKeyword so this isn't an equivalent change.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Sorry for this - I probably assumed that this already covers TrueKeyword/FalseKeyword. Tests pass without this else if branch - so this was probably an optimization or something (it's not an unused code).

I brought back the check for those keywords.

I don't exactly recall why I changed it in the first place - perhaps just to cover for all literal types as that seemed like the right thing to do at the time. If you want me to revert this change entirely, let me know.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If it's not relevant to the bug you're fixing, I'd revert the change. The fact that changing it didn't affect any tests makes me more reticent to take the change, since we don't know what we'd be breaking.

Comment thread src/compiler/checker.ts Outdated
@Andarist

Copy link
Copy Markdown
Contributor Author

Ron Buckton (@rbuckton) reverted those unrelated bits

@rbuckton
Ron Buckton (rbuckton) merged commit 2c1fda2 into microsoft:main Jan 9, 2023
@jeremy-rifkin

Copy link
Copy Markdown

Awesome to see this fixed and merged, thank you Mateusz Burzyński (@Andarist)!

@microsoft Microsoft (microsoft) locked as resolved and limited conversation to collaborators Oct 22, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

For Backlog Bug PRs that fix a backlog bug Merge/Review for Next Release This PR should be re-reviewed and merged ASAP for the next release.

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

Circular type false positive with async/await

7 participants