fix(linter/catch-or-return): handle arrow functions with implicit returns correctly

[Copilot]

The catch-or-return rule incorrectly flagged arrow functions with implicit returns as missing catch handlers, even though implicit returns are semantically equivalent to explicit returns.

// Was incorrectly flagged as needing .catch()
const handler = () => Promise.resolve(null);

// Also incorrectly flagged
const obj = {
  method: () => Promise.resolve({ id: '' })
};

Changes

• Added is_in_returned_context helper: Detects when an ExpressionStatement is the body of an arrow function with expression = true, indicating an implicit return
• Updated rule logic: Skip diagnostic for promises in implicitly-returned contexts
• Added test coverage: 10 new test cases covering arrow functions with implicit returns, block bodies, and edge cases
• Updated documentation: Added arrow function example to rule description

Technical Details

Arrow functions with expression bodies (() => expr) set expression = true on the AST node. The body still contains a FunctionBody with an ExpressionStatement, but the expression flag indicates it's implicitly returned. The fix walks the AST parent chain to detect this pattern.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>linter: catch-or-return doesn't handle inline arrow functions</issue_title>
<issue_description>The eslint-plugin-promise(catch-or-return) isn't properly detecting a return with inline arrow functions.

This is the error that its reporting, however looking at the snippet, the error is invalid since the promise is being returned.

I'm using 1.35.0

  × eslint-plugin-promise(catch-or-return): Expected `catch` or `return`.
    ╭─[src/areas/project-management/modals/template-task-modal/template-task-form-handlers.tsx:42:30]
 41 │   uploadImage: () => Promise.resolve(undefined),
 42 │   openLinkModalPrompt: () => Promise.resolve(null),
    ·                              ─────────────────────
 43 │   submitTemplate: () => Promise.resolve({ id: '' }),
    ╰────
  help: Return the promise or chain a `catch()`.
```</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes linter: catch-or-return doesn't handle inline arrow functions #17438

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR fixes the catch-or-return linter rule to correctly handle arrow functions with implicit returns. Previously, the rule incorrectly flagged arrow functions with expression bodies (e.g., () => Promise.resolve(null)) as missing catch handlers, even though these expressions are implicitly returned and therefore exempt from the rule.

Key Changes:

• Added a helper function to detect when an ExpressionStatement is implicitly returned by an arrow function (by checking the expression flag on the AST node)
• Integrated the check into the rule's run logic to skip diagnostics for implicitly-returned promises
• Added comprehensive test coverage with 10 new test cases covering various scenarios

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
crates/oxc_linter/src/rules/promise/catch_or_return.rs	Added is_arrow_function_expression_return helper function and integrated it into the rule logic; added pass/fail test cases
crates/oxc_linter/src/snapshots/promise_catch_or_return.snap	Updated snapshots with two new failing test cases for arrow functions with block bodies that don't return

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codspeed-hq]

CodSpeed Performance Report

Merging #17440 will not alter performance

_{Comparing copilot/fix-inline-arrow-function-linter (7537556) with main (a38892a)¹}

Summary

✅ 4 untouched
⏩ 41 skipped²

Footnotes

1. No successful run was found on main (f8c8552) during the generation of this report, so a38892a was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 41 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩