Disallow non-exhaustive matches

[Aehmlo]

I'm not sure if this is better suited as a language feature or a clippy lint (though I assume clippy is an easier route to pursue), but it would be really nice to be able to either mark an enum (lang?) or a region of code (clippy?) as disallowing non-exhaustive matches. I know this might seem weird and/or bad, but I have a project wherein I want to make sure that all possible variants are covered, no wildcards, and I would like to have clippy be able to take care of checking for this on PRs instead of having to check it myself (clippy's way less likely to miss it than I am!).

Let's say my library has an internal enum giving movement types, and a function that performs an action based on this.

enum Movement {
    Fly,
    Run,
}
// Somewhere else
fn respond(movement: Movement) {
    match movement {
        Movement::Fly => fly(),
        // Disallow _ as a pattern
        Movement::Run => run(),
    };
}

Then, if I (or someone else) later add(s) an enum variant, I can be sure, if the tests pass, that the new movement type is being appropriately handled (without the wildcard pattern as a crutch).

enum Movement {
    Dig,
    Fly,
    Run,
}
// Somewhere else
fn respond(movement: Movement) {
    match movement {
        Movement::Fly => fly(),
        Movement::Run => run(),
        // Since we disallowed the wildcard _, we know Dig is being handled without looking
        Movement::Dig => dig(),
    }
}

[flip1995]

Clippy is the right place for this! This lint would go in one of the categories pedantic/restriction, so it would be an opt-in lint.

If someone is interested in implementing this lint, the best point to start would be the clippy_lints/src/matches.rs file.

[Aehmlo]

I think I've implemented this locally. I'll test it out when I get back and send a PR once it's good!

[ghost]

This is definitely a restriction lint. It would have too many problems to be applied generally.

• The case where you have an enum with 25 variants and you want to treat 23 the same.
• Libraries that specifically don't what callers to do exhaustive matching e.g. regex

[Aehmlo]

Closed in #3652.