Skip to content
ZOLO / non-exhaustive-match Lint · warning

Non-exhaustive match (legacy lint, no longer emitted)

Legacy alias: closed matches are now checked once by the type checker as `TE829`. Kept so older links keep a migration target.

Legacy alias (not emitted)

non-exhaustive-match was the name of an older, AST-only lint. The compiler no longer emits or accepts this lint rule: it could not reason about payloads, products, recursive types, or type aliases reliably. Closed matches are now checked once by the type checker under the stable blocking diagnostic TE829. This page remains only so older links have a useful migration destination.

enum Color { Red, Green, Blue }

fn name_of(c: Color) -> str {
    match c {
        Color::Red => "red",
        Color::Green => "green",
        // error[TE829]: non-exhaustive — `Color::Blue` not handled
    }
}

Fix it

1. Add the missing arms

The robust fix — every variant explicitly handled. If you later add a new variant to Color, the compiler will tell you exactly where you forgot to update.

match c {
    Color::Red => "red",
    Color::Green => "green",
    Color::Blue => "blue",
}

2. Add a wildcard arm

Use this only when "everything else" is genuinely the same answer. It also turns off the helpful "you forgot to update the match" signal — adding a new variant will silently fall into the wildcard branch.

match c {
    Color::Red => "red",
    _ => "not red",
}

A defensive variant pairs the wildcard with a panic when intentionally handling future variants at runtime:

match c {
    Color::Red => "red",
    _ => panic("unhandled variant: ${c}"),
}

See also

  • TE829 — normative closed-match exhaustiveness diagnostic.
  • /docs/pattern-matching — guards, struct destructuring, and array patterns.

Global index

Find your way through Zolo

Try an idea

Start here

9 results

9 results

enespt-br