fix(47383): Destructuring of unknown catch variable is not an error

[Oleksandr Tarasiuk (a-tarasyuk)]

Fixes #47383

[Jake Bailey (jakebailey)]

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?

[Jake Bailey (jakebailey)]

Hm, apparently checkTryStatement doesn't actually call a check function on the catch clause / its variable declaration. That doesn't seem right.

[Jake Bailey (jakebailey)]

Yeah, I think checkTryStatement needs checkVariableLikeDeclaration(declaration), but that seems to cause some baseline changes including follow-on errors about implicit any, which are probably not right.

[Jake Bailey (jakebailey)]

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?

[Oleksandr Tarasiuk (a-tarasyuk)]

Jake Bailey (@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?

[Jake Bailey (jakebailey)]

Unless I'm mistaken, all of the examples above should have name be of type any (versus unknown), but that's what the PR has (so maybe your comment is wrong), so that's still good and consistent with other restructuring.

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.

[Nathan Shively-Sanders (sandersn)]

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?

[Oleksandr Tarasiuk (a-tarasyuk)]

Nathan Shively-Sanders (@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.