[manual_div_ceil]: init

[belyakov-am]

Suggest using div_ceil() instead of manual implementation for basic cases.

Partially fixes #12894

changelog: new lint: [manual_div_ceil]

[rustbot]

r? @blyxyas

rustbot has assigned @blyxyas.
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

[belyakov-am]

See #12894 for more details

[J-ZhengLi]

Some drive-by thoughts 😄 :

It seems like div_ceil for signed integers are still unstable, so if this was put in complexity group, we might ended up suggesting something that the users cannot fix. (not to mention that it have an applicability of MachineApplicable)
As for unsigned integers, this function was stabilized for 1.73.0 and onward, so a msrv configuration would be very nice~

[belyakov-am]

Thanks for your input!

I'm struggling to find a proper way to separate lint for stable and unstable (i.e. unsigned and signed integers)
Can you please point me in a direction that would be helpful for this?

[J-ZhengLi]

BTW, when a binary operand is cast expr, the suggestion might be broken, something like:

let z: u32 = 7;
let _ = (z as i32 + (y - 1)) / y;

this suggests z as i32.div_ceil(y), you'll need a pair of parentheses to wrap the caller (see maybe_par).

[J-ZhengLi]

I'm struggling to find a proper way to separate lint for stable and unstable (i.e. unsigned and signed integers) Can you please point me in a direction that would be helpful for this?

ah yes, it appears that you already have a function to check if it's Int or Uint right?

Then you should be able to separate it into two scenarios, one is where the type is ty::Int, in this case, don't offer a fixable suggestion yet... unless the user already have that required feature enabled, meaning cx.tcx.features().declared_features.contains(&Symbol::inter("int_roundings")) is true.

[belyakov-am]

Thanks a lot!

This declared_features hashset is very insightful, I'd never find it on my own

[blyxyas]

Not related, but maybe we should do some benchmarks on (a + (b - 1)) / b vs div_ceil, it seems to be 1 instruction faster

[blyxyas]

Very good for a first iteration on the lint! Some minor improvements, this is really close to the finish line!

[blyxyas]

This check should be before the double check_int_ty_and_feature, and you could also put the if let ExprKind::Binary(add_op, add_lhs, add_rhs) = div_lhs.kind here, because it's repeated three times without any reason (more than changing variable name)

[blyxyas]

You can use this notation //~ ERROR to indicate an error 🌈

[bors]

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

[blyxyas]

LGTM, thanks! ❤️

Sorry for the delay, I've been busy and turns out I didn't actually start the Final Comment Period with the team (which I could've sweared I did, but anyways 😅 ), in a few days I'll merge this PR.

Thanks for your contribution! And sorry again for keeping you waiting

In-between it gets accepted for merge by the team, could you squash the commits into one?

[flip1995]

Looking at lintcheck, all new lint suggestions are valid, so no FPs there. But the suggestions generation for macros is broken:

warning: manually reimplementing `div_ceil`
   --> target/lintcheck/sources/rand_core-0.6.0/src/impls.rs:59:26
    |
59  |         let chunk_size = (chunk_size_u8 + SIZE - 1) / SIZE;
    |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider using `.div_ceil()`: `chunk_size_u8.div_ceil(fill_via_chunks!(src, dest, u64))`
...
132 |     fill_via_chunks!(src, dest, u64)
    |     -------------------------------- in this macro invocation
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_div_ceil
    = note: this warning originates in the macro `fill_via_chunks` (in Nightly builds, run with -Z macro-backtrace for more info)

[bors]

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

[blyxyas]

I've done some updating. But I'm not being able to replicate the macro bug that Philipp is talking about, is there any more information? @belyakov-am Can you replicate it?

If we're not able to replicate it, we can safely merge this.

[bors]

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

[belyakov-am]

Thanks! And sorry for disappearing for so long
I wasn't able to reproduce this one

[flip1995]

I also doesn't show up in the latest lintcheck run anymore. So I guess my concern is resolved.

[blyxyas]

LGTM, thanks! ❤️ (I just synced and rebased to get this rerolling, just lib.rs issues)

[blyxyas]

Just looked at lintcheck, everything looks correct!

@bors r+

[bors]

📌 Commit 9415e6e has been approved by blyxyas

It is now in the queue for this repository.

[bors]

⌛ Testing commit 9415e6e with merge 9e9042a...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: blyxyas
Pushing 9e9042a to master...