feat: detect == 0 on unsigned types as a manual_clamp lower bound

[LesnyRumcajs]

Closes #16792

For unsigned types, if x == 0 can be expressed as if x < 1. The former was not caught by manual_clamp lint; this PR normalizes it so that cases as described in the linked issue are caught.

changelog: manual_clamp detect == 0 on unsigned types as a clamp lower bound

[rustbot]

r? @dswij

rustbot has assigned @dswij.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

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

[blyxyas]

Hello @dswij and @LesnyRumcajs, I hope that you don't mind we using this contribution to teach @medzernik some things about reviewing (they were very interested!).

This is how most Clippy contributions are structured, some code (usually in between 50 - 200 lines), and then some tests are added.

Things to take into account when reviewing:

• Try to break the contributor's code. It might sound cruel, but think that you're saving time from whoever will have to open the bug report, whoever will have to fix the bug, and whoever reviews that fix, in the future.
• If you're not very familiarized with some feature of the language (like pattern bindings to wildcards, or lifetime shadowing through function boundaries), you can check the Rust Reference.
• Remember to always test (or think how it would interact) with weird setups. How would a macro react? And a proc-macro? What about having this expression in an if let? What if the type implemented Copy + Clone but not Send? What about Sync + !Send?

Also, make sure to check the lintcheck results. And remember that you're not the only reviewing! We are fortunate in that, if Clippy fails, nobody dies! So there's no pressure to catch 100% of the bugs on the first try.

I'll also mention you in another 6-12 pull requests. My suggestion is that you go 1 by 1 and let me know if you have any questions.

[medzernik]

r? @medzernik

[blyxyas]

Hello @medzernik, I'm sorry for the misunderstanding, I thought you were talking about assigning me to your pull requests.

In fact, I didn't even know a non-member had permission to override an assignment like that. For this one we'll keep it, but please don't do it again 😅

[medzernik]

Hello @medzernik, I'm sorry for the misunderstanding, I thought you were talking about assigning me to your pull requests.

In fact, I didn't even know a non-member had permission to override an assignment like that. For this one we'll keep it, but please don't do it again 😅

Oh. Oops. I did it on all 5 xD Sorry.. :D

[medzernik]

I think the PR looks ok? From what I've tried it works as it should and there are no edge-cases from my testing? :D Approved? :D

View changes since this review

[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.

[blyxyas]

LGTM, thanks for addressing this issue! ❤️ ฅ•ω•ฅ
Could you take care of CI before merging?

[LesnyRumcajs]

@blyxyas It should be all green now! I thought there was just a minor import reshuffle conflict, but turned out is_integer_const got replaced with something else.

[blyxyas]

@medzernik do you want to merge this yourself?

@rustbot delegate=@medzernik

[rustbot]

✌️ @medzernik, you can now merge this pull request!

If @blyxyas told you to merge after making some further change, then please make that change and post @rustbot merge.

[medzernik]

@rustbot merge