-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Improve uncalled function checks #41599
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
Conversation
Fixes #41586 Fixes #41588 1. For binary expressions, if the immediate parent is an IfStatement, then check the body of the if statement. I didn't walk upward to find an IfStatement because in my experimentation I found that binary expression uncalled-function errors are only issued when the expression is on the left of the top-most binary expression. 2. For property accesses with interspersed calls, I added a CallExpression case. In fact, any expression could appear here, but I only want to fix calls for now since that's all we've observed in Definitely Typed, and we didn't see anything else in the user tests or RWC tests. I also didn't examine parameters of the intermediate call expressions, but I don't think it's needed since the intent is to avoid false positives.
@a-tarasyuk thanks for your help on this so far. If you can think of a test case that would require walking up multiple nodes to look for an IfStatement, please let me know. |
} | ||
// ok | ||
if (chrome.platformKeys.subtleCrypto().exportKey) { | ||
chrome.platformKeys.subtleCrypto().exportKey |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I need more coffee; why is this ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it's "used" in the body of the if
, even if it's not called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You just need a usage in the body. It doesn't actually have to call it.
@typescript-bot pack this |
Heya @DanielRosenwasser, I've started to run the perf test suite on this PR at 7265f49. You can monitor the build here. Update: The results are in! |
Heya @DanielRosenwasser, I've started to run the parallelized Definitely Typed test suite on this PR at 7265f49. You can monitor the build here. |
Heya @DanielRosenwasser, I've started to run the extended test suite on this PR at 7265f49. You can monitor the build here. |
Heya @DanielRosenwasser, I've started to run the parallelized community code test suite on this PR at 7265f49. You can monitor the build here. |
Heya @DanielRosenwasser, I've started to run the tarball bundle task on this PR at 7265f49. You can monitor the build here. |
@DanielRosenwasser Here they are:Comparison Report - master..41599
System
Hosts
Scenarios
|
The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master. |
Fixes #41586
Fixes #41588
For binary expressions, if the immediate parent is an IfStatement, then check the body of the if statement. I didn't walk upward to find an IfStatement because in my experimentation I found that binary expression uncalled-function errors are only issued when the expression is on the left of the top-most binary expression.
For property accesses with interspersed calls, I added a CallExpression case. In fact, any expression could appear here, but I only want to fix calls for now since that's all we've observed in Definitely Typed, and we didn't see anything else in the user tests or RWC tests. I also didn't examine parameters of the intermediate call expressions, but I don't think it's needed since the intent is to avoid false positives.