[`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
Look at adjusted types instead of fn signature types in `ptr_arg`
This simplifies the implementation of the `ptr_arg` lint a bit and:
Fixes#13308Fixes#10612
Currently, the lint checks if e.g. a `&String` parameter is only used in contexts where a `&str` could work. Part of it worked by looking for path exprs to that parameter in function call position specifically, looking at the callee signature and checking if that parameter type without refs is `String` (or one of a bunch of other special cases).
This simplified version removes the special casing of function calls and looking at the parameter type and instead just looks at the **adjusted type**, regardless of the expression it's in. This naturally also covers what the previous version was doing (if the expression is in a function call argument position expecting a `&str`, then it will have that adjustment. If it requires a `&String` then it won't have that adjustment and we won't lint).
The linked issue was a FP that happened because the previous implementation simply didn't consider projection types in the signature type, but with this simplification we don't really need to consider that (because we aren't looking at function signatures at all anymore -- the `&mut Self::Owned` parameter type of `clone_into` is the already-instantiated and normalized type `&mut String`).
changelog: none
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
Make it clearer that the suggestion is an alternative one
`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.
Inspired by a misunderstanding in #13321
changelog: none
`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
Remove unnecessary symbols and add missing symbols
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: Remove unnecessary symbols and add missing symbols
