[`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
Bump ui_test
This should give a bunch of ui improvements when lots of tests are running. Please lmk of any issues with it. Switching to `--quiet` should always avoid any issues, so there's a workaround if anything crops up. Also please check that this does not regress performance for you. It doesn't for me, but that doesn't mean much.
changelog: none
Visit struct fields recursively in uninit fallback check
This makes the fallback a bit more consistent with the other checks and rustc.
Fixes#13364. When using a generic type as the `Vec` element type like the issue title says, rustc's uninit check fails and our fallback is used, which didn't look at struct fields when it could.
changelog: none
[`single_match`, `single_match_else`] fix suggestion when match irrefutable
fixes#13012
changelog:[`single_match`, `single_match_else`]: fix suggestion when `match` irrefutable
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 `.
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
check std::panic::panic_any in panic lint
close#13292
This PR detects `std::panic::panic_any` in panic lint.
changelog: check std::panic::panic_any in panic lint
Rewrite `empty_line_after_doc_comments` and `empty_line_after_outer_attr`, move them from `nursery` to `suspicious`
changelog: [`empty_line_after_doc_comments`], [`empty_line_after_outer_attr`]: rewrite and move them from `nursery` to `suspicious`
They now lint when there's a comment between the last attr/doc comment and the empty line, to cover the case:
```rust
/// Docs for `old_code
// fn old_code() {}
fn new_code() {}
```
When these lints or `suspicious_doc_comments` trigger we no longer trigger any other doc lint as a broad fix for #12917, reverts some of #13002 as the empty line lints cover it
I ended up not doing https://github.com/rust-lang/rust-clippy/issues/12917#issuecomment-2161828859 as I don't think it's needed
Ignore underscore-prefixed args for needless_pass_by_value lint
When a user explicitly tags a param as unused (yet?), there is no need to raise another lint on it.
fixes#7295
Note that I had to rename all `_*` params in the tests, but kept the variable name length to avoid extra changes in the expected output.
changelog: [`needless_pass_by_value`]: do not warn if the argument name starts with an `_`
Diverging subexpression lint should not fire on todo!()
As per #10243 it is not that helpful to point out that a subexpression diverges, so do not fire on todo
changelog: [`diverging_sub_expression`]: do not trigger on todo
Fix confusing message in double_must_use lint
Close#13003
As mentioned at #13003 it isn't quite clear what it means "an empty `#[must_use]` attribute" so clarify it
changelog: [none]
Trigger [`string_slice`] if expression is reference to `&str`
Close#12708
changelog: [`string_slice`]: trigger lint if expression is reference to `&str`
fix false positive in explicit_iter_loop with msrv
close#13184
This PR fix false positive in explicit_iter_loop when msrv < 1.80
changelog: fix false positive in explicit_iter_loop when msrv < 1.80
Clarify suggestion message for unwrap lint
Close#10217
As mentioned at #10217 message for `unwrap` uses `..` like `Some(..)` which can confuse with slice and other places mostly use `<item>` like `for (i, <item>) in target_groups_json.iter().enumerate().skip(1) {` So replace `..` to `<item>`
changelog: [`unnecessary_unwrap`] clarify suggestion message
Add a test for ice-3717.rs
this PR is a part of https://github.com/rust-lang/rust-clippy/issues/13099.
Based on the changes introduced in #13098 for introduce ui_test, we will update the uitest output.
This is a fix for `ice-3717.rs`.
Although fixes have already been made in #13216, it seems that he is a first-time contributor.
I thought it might be better for him to refer to my PR, so I created it accordingly.
Since this is my first contribution in a while, please let me know if there are any issues or required changes.
changelog: none
r! `@flip1995`
Replace `rustc_semver` with `rustc_session::RustcVersion`
Allows dropping a dependency but there is a behaviour change here, the following versions are no longer accepted:
* `1` (would need to be `1.0` or `1.0.0`)
* `1.0.0-alpha`
* `1.0.0-alpha.2`
* `1.0.0-beta`
But this seems unlikely to effect anybody, I did some GitHub searching and found no occurrences outside our UI tests
r? `@flip1995`
changelog: none
Apply "polymorphization at home" to RawVec
The idea here is to move all the logic in RawVec into functions with explicit size and alignment parameters. This should eliminate all the fussing about how tweaking RawVec code produces large swings in compile times.
This uncovered https://github.com/rust-lang/rust-clippy/issues/12979, so I've modified the relevant test in a way that tries to preserve the spirit of the test without tripping the ICE.
Fix case where doc_markdown is triggered on words ending with "ified"
Fixes#13097.
r? `@Alexendoo`
changelog: Fix case where doc_markdown is triggered on words ending with "ified"
[`macro_metavars_in_unsafe`]: recognize metavariables in tail expressions
Fixes#13219
`macro_metavars_in_unsafe` keeps track of the current "expansion depth" (incremented/decremented when entering/leaving a macro span) to tell if an expression from the root context is contained within a macro (see the doc comment I added for a hopefully better explanation)
Before this PR, we didn't increment said `expn_depth` for `unsafe` blocks within macros, because we already do that in `visit_stmt` anyway, so it would work fine for statements, but that's not enough for tail expressions of an unsafe block.
So we now also increment it for macro unsafe blocks.
Also updated the comment for `expn_depth` while I'm at it because "This is not necessary for correctness" isn't correct now that I think about it
------
changelog: none
Respect allow `inconsistent_struct_constructor` on the struct definition
Closes#13203
Now we check if the target type is marked with `#[allow(clippy:inconsistent_struct_constructor)]` before lining.
As a side-effect of this change, The rule in the subject no longer runs on non-local `AdtDef`s. However, as suggested by `@Jarcho` it shouldn't be a big deal since most of the time we didn't have access to this information anyway.
> You can't get lint attributes from other crates. I would probably just restrict the lint to only work with types from the current crate while you're at it. Upstream crates don't have a definition order from the point of view of the current crate (with the exception of #[repr(C)] structs).
changelog: Respect allow `inconsistent_struct_constructor` on the struct definition.
Add lint for `unused_result_ok`
This PR adds a lint to capture the use of `expr.ok();` when the result is not _really_ used.
This could be interpreted as the result being checked (like it is with `unwrap()` or `expect`) but
it actually only ignores the result.
`let _ = expr;` expresses that intent better.
This was also mentionned in #8994 (although not being the main topic of that issue).
changelog: [`misleading_use_of_ok`]: Add new lint to capture `.ok();` when the result is not _really_ used.
