Add new lint `manual_is_power_of_two`
Suggest using `is_power_of_two()` instead of the manual implementations for some basic cases
Part of https://github.com/rust-lang/rust-clippy/issues/12894
----
changelog: new [`manual_is_power_of_two`] lint
Correct version of `too_long_first_doc_paragraph`
`too_long_first_doc_paragraph` is, empirically, not in the Rust 1.81.0 release.
changelog: [`too_long_first_doc_paragraph`]: correct Rust version number in documentation.
[`manual_div_ceil`]: init
Suggest using `div_ceil()` instead of manual implementation for basic cases.
Partially fixes#12894
changelog: new lint: [`manual_div_ceil`]
Changelog for Clippy 1.81 🔰
Roses are red,
Violets are blue,
Expectations are stable,
And reasons are set
---
### The cat of this release is *Keepy* submitted by `@blyxyas:`
<img height=500 src="https://github.com/rust-lang/rust-clippy/assets/73757586/902dd802-5ac8-471e-bb93-e195526ba580" alt="The cats of this Clippy release" />
Cats for the next release can be nominated in the comments :D
---
changelog: none
move `manual_c_str_literals` to complexity
IMO the suggestion to use `c""` literals over a hardcoded `\0` byte string literal has some fairly strong upsides (no need to manually null-terminate it and the compiler checks for intermediary null bytes) that this should just be enabled by default.
It's also written slightly conservatively to only emit a warning when we can be reasonably confident that the lint is *actually* applicable (that is, lint on e.g. `b"foo\0".as_ptr()` but not `b"foo\0"`. The latter looks like a c-string but its type is `&[u8; _]`, and if it's used in a context where a byte slice is needed then you have no nice way to convert to it from a `c"foo"` literal of type `&CStr`).
changelog: move [`manual_c_str_literals`] to complexity (now warn-by-default)
Add new check for passing pointers to an `asm!` block with `nomem` option
changelog: Add new check for passing pointers to an `asm!` block with `nomem` option
Continuing work from https://github.com/rust-lang/rust/pull/127063
Extend `implicit_saturating_sub` lint
Fixes#10070.
It can serve as base if we want to add equivalent checks for other arithmetic operations.
Also one important note: when writing this lint, I realized that I could check for wrong conditions performed beforehand on subtraction and added another part in the lint. Considering they both rely on the same checks, I kept both in the same place. Not sure if it makes sense though...
changelog: Extend `implicit_saturating_sub` lint
Use `is_diagnostic_item` for checking a def_id in `unnecessary_min_or_max`.
close#13191
This PR fixes the false positives in `unnecessary_min_or_max `.
We should use `is_diagnostic_item` for checking def_ids in this lint.
----
changelog: fix false positive in `unnecessary_min_or_max `.
new lint: `zombie_processes`
Closes#10754
Lint description should explain this PR, so I think there's nothing else to say here ^^
changelog: new lint: [`zombie_processes`]
Add new lint: `used_underscore_items`
Closes#13260
---
changelog: new [`used_underscore_items`] lint against using items with a single leading underscore
Fix manual_range_patterns case with one element at OR
Close#11825
As mentioned #11825 `OR` can be used for stylistic purposes with one element, we can filter this case from triggering lint
changelog: [`manual_range_patterns`]: not trigger when `OR` has only one element
