-
Notifications
You must be signed in to change notification settings - Fork 12.8k
fix(47383): Destructuring of unknown catch variable is not an error #47442
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
tests/baselines/reference/useUnknownInCatchVariables02(strict=false).errors.txt
Outdated
Show resolved
Hide resolved
This PR does pass tests, but I'm a bit confused as to why it doesn't work when I run the build via tsserver locally in VS Code; do these sorts of checks need to be somewhere else, maybe? Some missing case in another function? |
Hm, apparently |
Yeah, I think |
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.
Marking as needing changes (meant to do this with my last comment), as this doesn't seem to work in VS Code (and probably other editors), so we'll need to make sure that check call is added. Not entirely certain how to ensure the tests actually walk that; maybe they already check the opposite?
18988f3
to
40964a3
Compare
@jakebailey Thanks for the review and sorry for the delay in response. I've added changes that cover the following cases // @strict: true
// @useUnknownInCatchVariables: true
try {
// ...
}
catch ({ name }) {
^^^^ Property 'name' does not exist on type 'unknown'
// { name } has 'unknown' type because @useUnknownInCatchVariables: true
name;
}
try {
// ...
}
catch ({ name } : unknown) {
^^^^ Property 'name' does not exist on type 'unknown'
// { name } has explicit type 'unknown'
name;
} // @strict: true
// @useUnknownInCatchVariables: false
try {
// ...
}
catch ({ name }) {
// Ok
// { name } has 'any' type because @useUnknownInCatchVariables: false
name;
}
try {
// ...
}
catch ({ name } : unknown) {
^^^^ Property 'name' does not exist on type 'unknown'
// { name } has explicit type 'unknown'
name;
} // @strict: false
// @useUnknownInCatchVariables: true
try {
// ...
}
catch ({ name }) {
^^^^ Property 'name' does not exist on type '{}'
// { name } has '{}' type because @useUnknownInCatchVariables: true
// `unknown` is represented as `{}` with disabled `strict: false` check
name;
}
try {
// ...
}
catch ({ name } : unknown) {
^^^^ Property 'name' does not exist on type `{}`
// { name } has explicit type 'unknown'
name;
} // @strict: false
// @useUnknownInCatchVariables: true
try {
// ...
}
catch ({ name }) {
// Ok
// { name } has 'any' type because @useUnknownInCatchVariables: false
name;
}
try {
// ...
}
catch ({ name } : unknown) {
^^^^ Property 'name' does not exist on type `{}`
// { name } has explicit type 'unknown'
name;
} Is this the expected behavior? Or do we need to cover other cases? |
Unless I'm mistaken, all of the examples above should have It looks like things are still not quite right in the editor, though. If you use your test case but don't reference the variable in question, it still doesn't show an error. Compare the three cases here, each with the destructured variable left referenced. const { xyz }: unknown = {};
function foo({ name }: unknown) {
// ...
}
try {
// ...
}
catch ({ name }: unknown) {
// ...
} I'm not sure what you've changed to get further is correct, though; it still feels to me like there's something missing during the checker walk, and these errors are only functioning due to the side effect of evaluating the variable later. |
tests/baselines/reference/catchClauseWithTypeAnnotation.errors.txt
Outdated
Show resolved
Hide resolved
474027f
to
5599944
Compare
tests/baselines/reference/redeclareParameterInCatchBlock.symbols
Outdated
Show resolved
Hide resolved
aaacfbe
to
ba55fcf
Compare
I'm confused about the state of this PR. Why is it marked draft? If a team member signs off, is it OK to merge? If so, I guess that means it needs another review? |
@sandersn I'm really sorry for the confusion with the state of the PR. I've closed it to make this issue open to PR acceptance. |
Fixes #47383