Avoid using `let else` for `Result`

What it does

source: https://twitter.com/nick_r_cameron/status/1588205358803259392

As suggested in the OP, using let-else syntax for Result type would be a risk of overlooking proper handling of Err.
Also, refactoring, such as replacing Option types with Result is common thing.
This kind of work is sometimes overlooked, so it is worthwhile to cover in lint.

This lint will help you to notice when let-else is applied to the Result type.

Lint Name

let_else_to_result

Category

pedantic

Advantage

It detects potential risk of missing error handling

Drawbacks

No response

Example

enum MyErr { A, B }
fn foo() -> Result<String, MyErr> {
    Ok("foo".into())
}

fn bar() {
    let Ok(foo) = foo() else { return; };
}

Could be written as:

enum MyErr { A, B }
fn foo() -> Result<String, MyErr> {
    Ok("foo".into())
}

fn bar() {
    let foo = match foo() {
        Ok(foo) => foo,
        e => { return; }
    };
}

Start with the issue's Rust examples and the proposed lint name, let_else_to_result. Determine the cases where let-else matches a Result and define tests showing the lint reports them; done means the lint detects the described pattern without flagging unrelated let-else usage.