implemented unnecessary min

[FelixMaetzler]

fixes #11924
new version of #11951 because i'm to stupid to figure it out how to fix it

changelog: [`unnecessary_min`]: added lint

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @giraffate (or someone else) soon.

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

[bors]

☔ The latest upstream changes (presumably #12054) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #11987) made this pull request unmergeable. Please resolve the merge conflicts.

[asquared31415]

I don't know whether clippy has a policy for these sorts of things, but linting using the values of constants makes me wary. It would be possible to change A, B, or C in such a way that the use of min or max do actually do something, especially if it's something like min(CONST_LIMIT, user_input).

[FelixMaetzler]

I don't know whether clippy has a policy for these sorts of things, but linting using the values of constants makes me wary. It would be possible to change A, B, or C in such a way that the use of min or max do actually do something

I don't think i get your point.
In your commented block of code all "variables" are constants so afaik it is not possible that one of them can change.
In the case of

min(CONST_LIMIT, user_input)

there should be only a lint emitted if CONST_LIMIT is either the minimum or maximum value. If it is the minimum value, then the result will always be the minumum regardless of the user_input and if it is the maximum value then the result will always be the user_input.

Or did you mean something like that?:

let mut m = u32::MAX;
for _ in 0..1000{
   m = m.min(user_input);
}

In this situation nothing should be linted.
I'll add a test to confirm it.

thank you for your feedback. I appreciate it.

[FelixMaetzler]

i added the test

[asquared31415]

I would like to see tests using the u32::min(a, b) syntax to be sure that the suggestions are correct.

It might be worth adding a test for things like u32::min(CONST, { some_math * abc - 3 }) or other complex expressions that could be placed in the call.

[FelixMaetzler]

i'll add that.
Thank you.

[FelixMaetzler]

i tried your suggestion and it doesn't lint it.
It seems like it currently only works as a method with the . like a.min(b).

[FelixMaetzler]

I changed only one character and now the CI is failing.
i did cargo dev update_lints.
What can i do?

[y21]

I think you should be able to fix this by rebasing on master and then running cargo dev update_lints.
There are probably some changes on the master branch that your local branch doesn't yet have

[FelixMaetzler]

thank you. that worked!
should i rebase every time before making a new commit to my feature branch?

[y21]

I don't think you need to do that for every commit. I usually only rebase when conflicts happen or to squash commits when the PR is about to be merged or to clean up history/remove some commits that don't really add any value.

Looks like it was only needed here because there are currently 699 lints on master but your branch was behind a bit and didn't, so running cargo dev update_lints on the branch didn't update the "lint count" to 700, but on master it wants it updated. That doesn't happen very often ^^

[vohoanglong0107]

Hi @FelixMaetzler. Are you still working on this? Would you mind if I continue your work to combine issue #11901 to this?

[FelixMaetzler]

yes i'm working on it. But imho the feature is finished. I just have to resolve the conflicts and wait on further review.
I don't mind if you continue my work. Currently i don't have time because i have exams at my university.
Feel free to contribute in any way you want :-)
(If you like you can resolve the conflicts)
@vohoanglong0107

[vohoanglong0107]

Thanks @FelixMaetzler. Then I will start by fixing the conflict in this PR

[xFrednet]

Hey @FelixMaetzler can this PR be closed in favor of #12368?

[FelixMaetzler]

Hey @xFrednet, yes this PR can be closed. Thank you.