Add ignored_result_err lint to detect discarded Result error variants

[scuzzycheese]

View all comments

changelog: new lint: [ignored_result_err]: Add ignored_result_err lint to detect discarded Result error variants. fixes #16107

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @dswij (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: 8 candidates
• 8 candidates expanded to 8 candidates
• Random selection from Jarcho, dswij, llogiq, samueltardieu

[github-actions]

Lintcheck changes for 95c0e72

Lint	Added	Removed	Changed
clippy::ignored_result_err	309	0	0

This comment will be updated if you push new changes

[dswij]

r? clippy

[scuzzycheese]

Re-opening PR, I made mistake by resetting my origin.

[scuzzycheese]

@rustbot ready

[scuzzycheese]

Hi @flip1995
Just bumping this since I accidentally closed and reopened it a few days ago, which threw off the bot status.
Whenever you have some free time, I’d love to get your feedback on the implementation!

[scuzzycheese]

@rustbot ready

[scuzzycheese]

@flip1995 - Any movement on this?

[scuzzycheese]

@flip1995 - ping! :D

[scuzzycheese]

@flip1995 - Just a follow up on this.

[scuzzycheese]

@flip1995 - ping

[CommanderStorm]

r? clippy

[Manishearth]

I don't think I'll have time to look at this either

r? @Clippy

I'm a bit busy with Rust security things right now

[blyxyas]

Hello @scuzzycheese! Thanks for the contribution, being that you've been on this little 🏓 ping pong of reviewers (sometimes happens :/), I'll try to prioritize you. ❤️

[blyxyas]

Hmm, it seems that this lint is very similar to match_wild_err_arm what do you think about implementing some ideas of this lint into that other one? For one, I like the idea of relaxing the requirements for that lint to lint other "wildcard in Err arms" (such as an if let Ok(x) = y { .. } else { .. }), and for it to not require panics to lint.

What do you think about this idea?

[scuzzycheese]

I have to say, that i'm not convinced that match_wild_err_arm is similar in many ways.

The purpose of this lint is to detect when the error variable is being discarded, which is what happens when there is no match being used.

It actually doesn't try to detect match arms at all. Here are the patterns it detects:

• if let Ok(x) = expr (with or without else)
• while let Ok(x) = expr
• let Ok(x) = expr else { ... }

I feel like match_wild_err_arm is a different use case, designed to catch a different thing. Can if I can't incorporate the above expressions into match_wild_err_arm, then it's not a particularly useful lint.

I honestly feel like these are two different use cases. And they should be able to be used independently.

[blyxyas]

The bad pattern here is discarding the error form, right? Good code does not discard errors, it handles them. So in the case of this lint, we're encountering an unhandled error.

In the case of match_wild_err_arm, it's also about unhandled errors. The only difference is that one has explicit behavior for the Error case and the other is effectively Err(_) => {}.

Even in this example: let Ok(x) = expr else { ... }, we are seeing the same behavior as

match expr {
    Ok(x) => x,
     Err(_) => {...}
}

[scuzzycheese]

Ok, so are we saying we would take ALL the functionality into match_wild_err_arm? Because the whole reason I wrote this was to make sure that it captured the situations I think are dangerous.

[blyxyas]

Indeed ❤️!

Because the whole reason I wrote this was to make sure that it captured the situations I think are dangerous.

I know, and I understand that it can feel like we're valuing your work less just because we see that this two functionalities should go together. But looking at both these two helpful lints, we just don't see enough difference in user experience to warrant having to learn the two names and having two different documentation pages.

You're very welcome to merge the logic from PR into match_wild_err_arm , and I'm sorry for the lost work.

[scuzzycheese]

Thanks for the reply. It's not a loss, I just didn't want to lose any of the functionality in my checks. If they are captured completely in match_wild_err_arm I'll be happy with that. Let me get on that. I just need to deal with a merge conflict first which I'll push, then I'll move them into match_wild_err_arm. Thanks

…

On Tue, 13 Oct 2026 at 14:33, Alejandra González ***@***.***> wrote: *blyxyas* left a comment (rust-lang/rust-clippy#17326) <#17326 (comment)> Indeed ❤️! Because the whole reason I wrote this was to make sure that it captured the situations I think are dangerous. I know, and I understand that it can feel like we're valuing your work less just because we see that this two functionalities should go together. But looking at both these two helpful lints, we just don't see enough difference in user experience to warrant having to learn the two names and having two different documentation pages. You're very welcome to merge the logic from PR into match_wild_err_arm , and I'm sorry for the "lost" work. — Reply to this email directly, view it on GitHub <#17326?email_source=notifications&email_token=AAPCF2AK6LCPUFPZYZWL7B35TYOIJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMJUGU2TSNZTGMY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6145597331>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPCF2BT5GWMYTSD7TQZ6BT5TYOIJAVCNFSNUABEKJSXA33TNF2G64TZHMZDMOBVGA2DIMZ3JFZXG5LFHM2DOOBQGY2TAOJYGOQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAPCF2FKQXSH6ELQ27D2B435TYOIJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMJUGU2TSNZTGMY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AAPCF2D7HUP4BGH4NL76QIT5TYOIJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMJUGU2TSNZTGMY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[scuzzycheese]

I have a.... query about putting this inside match_wild_err_arm.
match_wild_err_arm is included in pedantic. Whereas ignored_result_err was a restricted lint.
I found when moving this into match_wild_err_arm, the dogfood tests now failed with 25 new diagnostics across 25 new sites. This is... quite an impact. Which means, that if we just fold this into match_wild_err_arm, anyone who has pedantic turned on is highly likely to have to make code changes to make this pass, and it's could cause a lot of impact for many clippy users who have pedantic turned on.
I'm not sure this is the right course of action. If we leave it within ignored_result_err, it means these can be turned on specifically if a user wants it, whereas this is going to be forces on users if it's included in match_wild_err_arm.

Is this acceptable? I'm not convinced it's... a good choice.

What do you think?