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

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

Merged
merged 4 commits into from Jan 9, 2023

Conversation

Andarist
Copy link
Contributor

@typescript-bot typescript-bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Oct 10, 2022
Comment on lines 35351 to 35354
if (isAwaitExpression(expr)) {
const type = getQuickTypeOfExpression(expr.expression);
return type ? getAwaitedType(type) : undefined;
}
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 is the core of the fix

Comment on lines 35356 to 35358
if (type) {
return type;
}
Copy link
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

}
else if (isAssertionExpression(expr) && !isConstTypeReference(expr.type)) {
return getTypeFromTypeNode((expr as TypeAssertion).type);
}
else if (node.kind === SyntaxKind.NumericLiteral || node.kind === SyntaxKind.StringLiteral ||
node.kind === SyntaxKind.TrueKeyword || node.kind === SyntaxKind.FalseKeyword) {
else if (isLiteralExpression(node)) {
Copy link
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
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
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.

@@ -39,7 +39,6 @@ interface A {
function foo(x: A): string { return "abc"; }

class C {
// Error expected
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 was outdated, no error is being reported here (and no error has to be reported here)

@DanielRosenwasser
Copy link
Member

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

@typescript-bot
Copy link
Collaborator

typescript-bot commented Oct 13, 2022

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

@typescript-bot
Copy link
Collaborator

typescript-bot commented Oct 13, 2022

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

@typescript-bot
Copy link
Collaborator

typescript-bot commented Oct 13, 2022

Heya @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
Copy link
Collaborator

typescript-bot commented Oct 13, 2022

Heya @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
Copy link
Collaborator

typescript-bot commented Oct 13, 2022

Heya @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
Copy link
Collaborator

typescript-bot commented Oct 13, 2022

Hey @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
Collaborator

@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
Collaborator

@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

@typescript-bot typescript-bot added For Backlog Bug PRs that fix a backlog bug and removed For Uncommitted Bug PR for untriaged, rejected, closed or missing bug labels Oct 13, 2022
Copy link
Member

@DanielRosenwasser DanielRosenwasser left a comment

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
Collaborator

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

Everything looks good!

@Andarist
Copy link
Contributor Author

@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

@sandersn sandersn added this to Not started in PR Backlog Oct 18, 2022
@DanielRosenwasser 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
Member

sandersn commented Dec 9, 2022

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

@sandersn sandersn moved this from Not started to Needs merge in PR Backlog Dec 9, 2022
@DanielRosenwasser
Copy link
Member

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

# Conflicts:
#	src/compiler/checker.ts
@Andarist
Copy link
Contributor Author

Andarist commented Dec 9, 2022

@sandersn it's up to date now :)

@sandersn sandersn moved this from Needs merge to Waiting on reviewers in PR Backlog Dec 10, 2022
@Andarist
Copy link
Contributor Author

Andarist commented Jan 8, 2023

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

}
else if (isAssertionExpression(expr) && !isConstTypeReference(expr.type)) {
return getTypeFromTypeNode((expr as TypeAssertion).type);
}
else if (node.kind === SyntaxKind.NumericLiteral || node.kind === SyntaxKind.StringLiteral ||
node.kind === SyntaxKind.TrueKeyword || node.kind === SyntaxKind.FalseKeyword) {
else if (isLiteralExpression(node)) {
Copy link
Member

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
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
Member

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.

src/compiler/checker.ts Show resolved Hide resolved
PR Backlog automation moved this from Waiting on reviewers to Waiting on author Jan 9, 2023
@Andarist Andarist requested review from rbuckton and removed request for andrewbranch and ahejlsberg January 9, 2023 14:22
@Andarist
Copy link
Contributor Author

Andarist commented Jan 9, 2023

@rbuckton reverted those unrelated bits

PR Backlog automation moved this from Waiting on author to Needs merge Jan 9, 2023
@rbuckton rbuckton merged commit 2c1fda2 into microsoft:main Jan 9, 2023
PR Backlog automation moved this from Needs merge to Done Jan 9, 2023
@Andarist Andarist deleted the fix/51115 branch January 9, 2023 19:34
@jeremy-rifkin
Copy link

Awesome to see this fixed and merged, thank you @Andarist!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
PR Backlog
  
Done
Development

Successfully merging this pull request may close these issues.

Circular type false positive with async/await
7 participants