[`missing_panics_doc`] Fix#13381Fix#13381
Makes `missing_panics_doc` act like other "panicking" lints (`unwrap_used`, `panic`, etc) in constant environments.
changelog: Ignore `missing_panics_doc` in constant environments
fix: Fixed incorrect comment form suggestion for too_long_first_doc_paragraph lint
fixes#13309
changelog: none
Comment form is now a variable and a new test for too_long_first_doc_paragraph was added.
chore: Ran cargo dev fmt
chore: Fixed spacing
fix: Fixed spacing for comment suggestion
fix: Added new module level test to too_long_first_doc_paragraph
chore: Ran cargo uibless
`needless_pass_by_value` sometimes suggest marking the concerned type as
`Copy`. Adding a `or` before this suggestion makes it clearer that this
is not the second part of the original suggestion, but an alternative one.
Not trigger `duplicated_attributes` on duplicate reasons
As at #13355 we shoudn't trigger `duplicated_attributes` on duplicate reasons attr
changelog: [`duplicated_attributes`]: not trigger `duplicated_attributes` on duplicate reasons
Special-case suggestions for null pointers constness cast
This implements the suggestions from #13361. It fits into the existing `ptr_cast_constness` lint, as this is a specialized version. However,
1. I have not modified the lint MSRV, so the documentation for this lint will still show that it applies only from Rust 1.72.0. This is true in the general case, but the lint for null pointers will trigger even before this version as `null()` and `null_mut()` were already present in Rust 1.0 and there is no reason not to apply this lint. I guess this is only a minor documentation issue that can be ignored.
2. I have not covered the `core::ptr::null::<T>().cast_mut()` (could be made into `core::ptr::null_mut::<T>()`) and `cotr::ptr::null_mut::<T>().cast_const()` (could be made into `core::ptr::null::<T>()`) cases. Should they be covered? If they should, here or in a separate PR?
changelog: [`ptr_cast_constness`]: special-case suggestions for null pointers constness cast
Fix#13361
Fix possible typo in `ptr_arg` lint
This fixes a possible typo in the [`ptr_arg`](https://rust-lang.github.io/rust-clippy/master/index.html#/ptr_arg) lint. I'm new to Rust, so apologies if I misunderstood the meaning of this lint.
changelog: [`ptr_arg`]: Fix typo ("size" -> "type")
[`single_match`, `single_match_else`] fix suggestion when match irrefutable
fixes#13012
changelog:[`single_match`, `single_match_else`]: fix suggestion when `match` irrefutable
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.
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)
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
