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

fix(eslint-plugin): [return-await] clean up in-try-catch detection and make autofixes safe #9031

Merged

Conversation

kirkwaiblinger
Copy link
Member

@kirkwaiblinger kirkwaiblinger commented Apr 30, 2024

PR Checklist

Overview

These 3 bugs are closely related, and the code is largely interdependent, so I figured it would be easiest to group into 1 PR. We can do sequential PRs instead if need be.

The diff looks like there's a lot going on, but I think it's actually not so bad, if we go step-by-step. (Then again, this is all swimming around in my head so it probably makes more sense to me than to a reader):

  1. docs changes. Not tied to any specific code change, just tried to improve them somewhat.
  2. Refactoring/Logic simplification - when determining whether a node is inside of a try, catch, or finally, we now just find the nearest try-catch-finally statement and work from there, rather than checking each ancestor separately. (bye-bye inTry, inCatch, hasFinallyBlock, isReturnPromiseInFinally, all replaced by findEnclosingTryStatement)
  3. Logic change - extract error-handling logic from in-try-catch into a helper function that now also checks nested try-catch-finally statements, rather than just the closest one found (affectsExplicitErrorHandling), fixing Bug: [return-await] should handle nested try-catch-finally blocks with "in-try-catch" option #8907.
  4. Trivially fix the control flow in the in-try-catch thanks to the above helper, fixing Bug: [return-await] awaited promise allowed in terminal catch block #8663.
  5. Logic change - Use the above utilities outside of the in-try-catch option as well, as the condition for whether to autofix or suggest a fix, fixing Bug: [return-await] unsafe autofixes in error handling code #8661.
  6. Lots of accompanying test changes. With the exception of one valid test change for Bug: [return-await] awaited promise allowed in terminal catch block #8663, all the test changes are just changing autofixes to suggestions (Bug: [return-await] unsafe autofixes in error handling code #8661). The test additions are to handle the nested try-catch-finallys (Bug: [return-await] should handle nested try-catch-finally blocks with "in-try-catch" option #8907)

@typescript-eslint
Copy link
Contributor

Thanks for the PR, @kirkwaiblinger!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!


🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint.

Copy link

netlify bot commented Apr 30, 2024

Deploy Preview for typescript-eslint ready!

Name Link
🔨 Latest commit c23b3a6
🔍 Latest deploy log https://app.netlify.com/sites/typescript-eslint/deploys/6659e95db4c9d30008efaa7f
😎 Deploy Preview https://deploy-preview-9031--typescript-eslint.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse
1 paths audited
Performance: 100 (🟢 up 2 from production)
Accessibility: 100 (no change from production)
Best Practices: 92 (no change from production)
SEO: 98 (no change from production)
PWA: 80 (no change from production)
View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify site configuration.

},
],
},
{
code: `
async function bar() {}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just tests 3 totally separable errors, so I broke it up into 3 separate tests.

});
} else if (!isAwait && isInTryCatch) {
if (inCatch(expression) && !hasFinallyBlock(expression)) {
return;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The return statements were just wrong. Directly caused #8663 and played into #8907 as well.

With the inCatch/hasFinallyBlock etc logic extracted to the affectsErrorHandling variable, they now correctly are included in the preceeding branch (enforcing removing the await).

@@ -222,13 +250,29 @@ export default createRule({
return;
}

const affectsErrorHandling = affectsExplicitErrorHandling(expression);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thought is that one day (soon) there will be a || affectsExplicitResourceManagement(expression) 🙏 #7889/#9044

@kirkwaiblinger kirkwaiblinger changed the title fix(eslint-plugin): [no-return-await] Clean up the logic for in-try-catch detection and make autofixes safe fix(eslint-plugin): [no-return-await] clean up in-try-catch detection and make autofixes safe Apr 30, 2024
@kirkwaiblinger kirkwaiblinger marked this pull request as ready for review April 30, 2024 15:28
@kirkwaiblinger kirkwaiblinger added the bug Something isn't working label May 3, 2024
@kirkwaiblinger kirkwaiblinger changed the title fix(eslint-plugin): [no-return-await] clean up in-try-catch detection and make autofixes safe fix(eslint-plugin): [return-await] clean up in-try-catch detection and make autofixes safe May 4, 2024
Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is excellent work, nicely done @kirkwaiblinger. I tried a few times to find something major to complain about but couldn't find anything. 👏

From me, there's just the one nit on a thrown error. Since this is a pretty tricky area I'll slap on the 1 approval label in the hopes someone else will be able to review too.

packages/eslint-plugin/src/rules/return-await.ts Outdated Show resolved Hide resolved
| { fix: TSESLint.ReportFixFunction }
| { suggest: TSESLint.SuggestionReportDescriptor<MessageId>[] } {
return useFix ? { fix: suggestion.fix } : { suggest: [suggestion] };
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Praise] I like this :)

Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wrong button

@kirkwaiblinger
Copy link
Member Author

@JoshuaKGoldberg

wrong button

WRONG LEVER

Copy link
Member

@JoshuaKGoldberg JoshuaKGoldberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kuzco from The Emperor's New Groove dancing

@kirkwaiblinger kirkwaiblinger merged commit 2619c3b into typescript-eslint:main May 31, 2024
59 of 60 checks passed
@kirkwaiblinger kirkwaiblinger deleted the return-await-bugs branch May 31, 2024 15:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants