oxc-project/oxc · warning · OxcDiagnostic

Unnecessary return statement.

Error message

Unnecessary return statement.

What it means

Diagnostic from the `no-useless-return` rule. A `return;` (or `return undefined;`) statement at the end of a function adds nothing because falling off the end already returns undefined. Oxc implements this on the semantic CFG (ControlFlowGraph edges/instructions), reporting return instructions that are the terminal no-op of their function. Help text: 'Remove this redundant `return` statement.'

Source

Thrown at crates/oxc_linter/src/rules/eslint/no_useless_return.rs:16

use oxc_allocator::ArenaVec;
use oxc_ast::AstKind;
use oxc_cfg::{
    BlockNodeId, ControlFlowGraph, EdgeType, InstructionKind, ReturnInstructionKind,
    graph::{Direction, visit::EdgeRef},
};
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_semantic::NodeId;
use oxc_span::{GetSpan, Span};
use rustc_hash::FxHashSet;

use crate::{AstNode, context::LintContext, rule::Rule};

fn no_useless_return_diagnostic(span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn("Unnecessary return statement.")
        .with_help("Remove this redundant `return` statement.")
        .with_label(span)
}

#[derive(Debug, Default, Clone)]
pub struct NoUselessReturn;

declare_oxc_lint!(
    /// ### What it does
    ///
    /// Disallows redundant return statements.
    ///
    /// ### Why is this bad?
    ///
    /// A `return;` statement with nothing after it is redundant, and has no effect
    /// on the runtime behavior of a function. This can be confusing, so it's better
    /// to disallow these redundant statements.
    ///

View on GitHub (pinned to e1e7af627c)

Solutions

  1. Delete the trailing `return;` statement.
  2. If the return documented intent, add a comment instead of dead code.
  3. For `return undefined;` mid-function that is meaningful control flow, keep it but ensure it is not the last statement.
  4. Use `oxlint --fix` which removes the statement automatically.

Example fix

// before
function save(data) {
  persist(data);
  return;
}

// after
function save(data) {
  persist(data);
}
Defensive patterns

Strategy: validation

Validate before calling

// heuristic: flag a bare `return;` that is the last statement of a function body
function hasTrailingBareReturn(fnSource) {
  return /\breturn\s*;?\s*\}\s*$/.test(fnSource);
}

Prevention

When it happens

Trigger: `function f() { doWork(); return; }`, arrow bodies with trailing `return;`, or `return undefined;` as the last statement. The rule walks CFG return instructions and flags those with no value that lead directly to the function exit.

Common situations: Leftover early-return style from C/Java habits; refactors that removed code after return; guard clauses moved so a final bare return remains.

Related errors


AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/6da3f88b002ec1a6. Report an issue: GitHub.