Fix underflow in `manual_split_once` lint
Hi, a friend found clippy started crashing on a suspiciously large allocation of `u64::MAX` memory on their code.
The mostly minimized repro is:
```rust
fn _f01(title: &str) -> Option<()> {
let _ = title[1..].splitn(2, '[').next()?;
Some(())
}
```
The underflow happens in this case on line 57 of the patch but I've changed the other substraction to saturating as well since it could potentially cause the same issue.
I'm not sure where to put a regression test, or if it's even worth for such a thing.
Aside, has it been considered before to build clippy with overflow checks enabled?
changelog: fix ICE of underflow in `manual_split_once` lint
Fix `needless_borrow` causing mutable borrows to be moved
fixes#8191
changelog: Fix `needless_borrow` causing mutable borrows to be moved
changelog: Rename `ref_in_deref` to `needless_borrow`
changelog: Suggest removing the borrow on method call receivers in `needless_borrow`
Check usages in `ptr_arg`
fixes#214fixes#1981fixes#3381fixes#6406fixes#6964
This does not take into account the return type of the function currently, so `(&Vec<_>) -> &Vec<_>` functions may still be false positives.
The name given for the type also has to match the real type name, so `type Foo = Vec<u32>` won't trigger the lint, but `type Vec = Vec<u32>` will. I'm not sure if this is the best way to handle this, or if a note about the actual type should be added instead.
changelog: Check if the argument is used in a way which requires the original type in `ptr_arg`
changelog: Lint mutable references in `ptr_arg`
fix op_ref false positive
fixes#7572
changelog: `op_ref` don't lint for unnecessary reference in BinOp impl if removing the reference will lead to unconditional recursion
issue #8239: Printed hint for lint or_fun_call is cropped and does no…
fixesrust-lang/rust-clippy#8239
changelog: [`or_fun_call`]: if suggestion contains more lines than MAX_SUGGESTION_HIGHLIGHT_LINES it is stripped to one line
* Track the argument when used to initialize simple `let` bindings
* Check if the argument is passed to a function requiring the original type
* Use `multipart_suggestion` rather than multiple suggestions
* Check if the name given in the source code matches the name of the actual type
`manual_memcpy` fix
fixes#8160
Ideally this would work with `VecDeque`, but the current interface is unsuitable for it. At a minimum something like `range_as_slices` would be needed.
changelog: Don't lint `manual_memcpy` on `VecDeque`
changelog: Suggest `copy_from_slice` for `manual_memcpy` when applicable