-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 a regression with reporting unused parameters in potential predicates #58514
Fixed a regression with reporting unused parameters in potential predicates #58514
Conversation
@typescript-bot test it |
Hey @jakebailey, the results of running the DT tests are ready. Everything looks the same! |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the user tests comparing Everything looks good! |
@jakebailey Here are the results of running the top 400 repos comparing Everything looks good! |
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.
@danvk guessed that the source of the problem was a speculative getTypeOfSymbol
. But this PR fixes resolution for all parameters. If it applies to all parameters, why wasn't this observed before Dan's change?
- Need tests of used/unused binding patterns. These probably exist already, but please double-check.
- If this implementation is correct, I think it would be easier to read in
isSelfReferenceLocation
, as long as that doesn't make performance worse (from adding a second parameter).
Edit: having looked at checkIfExpressionRefinesAnyParameter, Dan's specific guess doesn't make sense to me. My (fuzzier) guess is that we haven't tried to resolve a parameter name from itself before and never observed that it mistakenly caused the parameter to be marked as used. But I'm not sure what in the new code is causing that.
src/compiler/utilities.ts
Outdated
@@ -11360,18 +11360,23 @@ export function createNameResolver({ | |||
location = root.parent; | |||
} | |||
break; | |||
case SyntaxKind.Parameter: | |||
case SyntaxKind.Parameter: { | |||
const param = location as ParameterDeclaration; |
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.
style question: is there a reason for all the casts in this code? Maybe it's better to drop this alias and use location as ParameterDeclaration)
everywhere.
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.
No specific reason, I just prefer to have a single cast than multiple ones that are the same for the same variable. I can change this if you prefer the other style.
src/compiler/utilities.ts
Outdated
case SyntaxKind.Parameter: { | ||
const param = location as ParameterDeclaration; | ||
if (lastLocation === param.name) { | ||
lastSelfReferenceLocation = param; |
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'd almost prefer a new parameter and entry in isSelfReferenceLocation
like
function isSelfReferenceLocation(node: Node, lastLocation: Node): node is SelfReferenceLocation {
switch (node.kind) {
case SyntaxKind.Parameter: return lastLocation === (node as ParameterDeclaration).name
// ...
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 just pushed out the suggested change
src/compiler/utilities.ts
Outdated
case SyntaxKind.Parameter: | ||
case SyntaxKind.Parameter: { | ||
const param = location as ParameterDeclaration; | ||
if (lastLocation === param.name) { |
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.
what does this do when param.name is a BindingPattern? Do we have tests to make sure that they still correctly get marked unused (and used when used)?
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.
yeah, there are tests for that already and the changes to checkIfExpressionRefinesAnyParameter
that introduced this bug don't affect binding patterns
This is correct.
It's |
0dcf1c2
to
3d0b2b8
Compare
@typescript-bot test it |
Hey @jakebailey, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
Hey @jakebailey, the results of running the DT tests are ready. Everything looks the same! |
@jakebailey Here are the results of running the user tests with tsc comparing Everything looks good! |
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the top 400 repos with tsc comparing Everything looks good! |
@typescript-bot cherry-pick this to release-5.5 |
Hey, @jakebailey! I've created #58841 for you. |
…e-5.5 (#58841) Co-authored-by: Mateusz Burzyński <mateuszburzynski@gmail.com>
fixes #58493