The `restriction` group contains many lints which are not about
necessarily “bad” things, but style choices — perhaps even style choices
which contradict conventional Rust style — or are otherwise very
situational. This results in silly wording like “Why is this bad?
It isn't, but ...”, which I’ve seen confuse a newcomer at least once.
To improve this situation, this commit replaces the “Why is this bad?”
section heading with “Why restrict this?”, for most, but not all,
restriction lints. I left alone the ones whose placement in the
restriction group is more incidental.
In order to make this make sense, I had to remove the “It isn't, but”
texts from the contents of the sections. Sometimes further changes
were needed, or there were obvious fixes to make, and I went ahead
and made those changes without attempting to split them into another
commit, even though many of them are not strictly necessary for the
“Why restrict this?” project.
Rephrase and expand `empty_enum` documentation.
* Remove incorrect claim that “wrappers around it are the conventional way to define an uninhabited type”.
* Discuss why one would use `!`, a newtype struct, or keep the enum.
* Add links to relevant documentation.
Before writing this change, I asked the community via [IRLO](https://internals.rust-lang.org/t/idiomatic-definition-of-uninhabited-never-newtypes/20877) and [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Never.20type.20wrappers.20.2F.20defining.20uninhabited.20newtypes) for feedback. The broad consensus seemed to me to be that in a world where both `never_type` and `min_exhaustive_patterns` are stable and therefore available for general use, we _might_ want to `!` or newtypes of it — but it's certainly not “conventional” _yet._ Therefore, I've removed “conventional” and added a discussion of the pros and cons of different choices.
changelog: [`empty_enum`]: expanded documentation
* Remove incorrect claim that “wrappers around it are the conventional
way to define an uninhabited type”.
* Discuss why one would use `!`, a newtype struct, or keep the enum.
* Add links to relevant documentation.
fulfill expectations in `check_unsafe_derive_deserialize`
The utility function `clippy_utils::fulfill_or_allowed` is not used because using it would require to move the check for allowed after the check iterating over all inherent impls of the type, doing possibly unnecessary work.
Instead, `is_lint_allowed` is called as before, but additionally, once certain that the lint should be emitted, `span_lint_hir_and_then` is called instead of `span_lint_and_help` to also fulfill expectations.
Note: as this is my first contribution, please feel free to nitpick or request changes. I am happy to adjust the implementation.
fixes: #12802
changelog: fulfill expectations in [`unsafe_derive_deserialize`]
Add new lint `while_float`
This PR adds a nursery lint that checks for while loops comparing floating point values.
changelog:
```
changelog: [`while_float`]: Checks for while loops comparing floating point values.
```
Fixes#758
doc_lazy_continuation: do not warn on End events
```
changelog: none
```
This avoids event spans that would otherwise cause crashes, since an
End's span covers the range of the tag (which will be earlier than the
line break within the tag).
This avoids event spans that would otherwise cause crashes, since an
End's span covers the range of the tag (which will be earlier than the
line break within the tag).
Add configuration option for ignoring `panic!()` in tests
```
changelog: [`panic`]: Now can be disabled in tests with the `allow-panic-in-tests` option
```
I often find myself using `panic!(…)` in tests a lot, where I often do something like:
```rust
match enam {
Enam::A => …,
Enam::B => …,
_ => panic!("This should not happen at all."),
}
```
I think this patch should go nicely with already existing `allow-unwrap-in-tests` and `allow-expect-in-tests`.
Manually set library paths in .github/driver.sh
Fixes https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Windows.20CI.20failing
Rustup 1.27.1 no longer adds `[SYSROOT]/bin` to `PATH` by default - https://github.com/rust-lang/rustup/issues/3825. This is fine for the packaged binaries since windows loads `dll`s from the folder the executable is in, but our built one is in a different folder
There's an environment variable to get the old behaviour back, but as it's deprecated and not much code I think returning to setting it manually is fine
changelog: none
The utility function `clippy_utils::fulfill_or_allowed` is not used because
using it would require to move the check for allowed after the check
iterating over all inherent impls of the type, doing possibly
unnecessary work.
Instead, `is_lint_allowed` is called as before, but additionally, once
certain that the lint should be emitted, `span_lint_hir_and_then` is called
instead of `span_lint_and_help` to also fulfill expectations.
fixes: #12802
changelog: fulfill expectations in `check_unsafe_derive_deserialize`
make sure the msrv for `const_raw_ptr_deref` is met when linting [`missing_const_for_fn`]
fixes: #8864
---
changelog: make sure the msrv for `const_ptr_deref` is met when linting [`missing_const_for_fn`]
less aggressive needless_borrows_for_generic_args
Current implementation looks for significant drops, that can change the behavior, but that's not enough - value might not have a `Drop` itself but one of its children might have it.
A good example is passing a reference to `PathBuf` to `std::fs::File::open`. There's no benefits to pass `PathBuf` by value, but since `clippy` can't see `Drop` on `Vec` several layers down it complains forcing pass by value and making it impossible to use the same name later.
New implementation only looks at copy values or values created in place so existing variable will never be moved but things that take a string reference created and value is created inplace `&"".to_owned()` will make it to suggest to use `"".to_owned()` still.
Fixes https://github.com/rust-lang/rust-clippy/issues/12454
changelog: [`needless_borrows_for_generic_args`]: avoid moving variables
`assigning_clones`: move to `pedantic` so it is allow by default
In a nutshell, the `assigning_clones` lint suggests to make your code less readable for a small performance gain. See #12778 for more motivation.
fixes#12778
changelog: [`assigning_clones`]: move to the `pedantic` group
improve [`match_same_arms`] messages, enable rustfix test
closes: #9251
don't worry about the commit size, most of them are generated
---
changelog: improve [`match_same_arms`] lint messages
`significant_drop_in_scrutinee`: Fix false positives due to false drops of place expressions
Place expressions do not really create temporaries, so they will not create significant drops. For example, the following code snippet is quite good (#8963):
```rust
fn main() {
let x = std::sync::Mutex::new(vec![1, 2, 3]);
let x_guard = x.lock().unwrap();
match x_guard[0] {
1 => println!("1!"),
x => println!("{x}"),
}
drop(x_guard); // Some "usage"
}
```
Also, the previous logic thinks that references like `&MutexGuard<_>`/`Ref<'_, MutexGuard<'_, _>>` have significant drops, which is simply not true, so it is fixed together in this PR.
Fixes https://github.com/rust-lang/rust-clippy/issues/8963
Fixes https://github.com/rust-lang/rust-clippy/issues/9072
changelog: [`significant_drop_in_scrutinee`]: Fix false positives due to false drops of place expressions.
r? `@blyxyas`
new lint: `macro_metavars_in_unsafe`
This implements a lint that I've been meaning to write for a while: a macro with an `expr` metavariable that is then expanded in an unsafe context. It's bad because it lets the user write unsafe code without an unsafe block.
Note: this has gone through some major rewrites, so any comment before https://github.com/rust-lang/rust-clippy/pull/12107#issuecomment-2029503545 is outdated and was based on an older version that has since been completely rewritten.
changelog: new lint: [`macro_metavars_in_unsafe`]
add new lint that disallow renaming parameters in trait functions
fixes: #11443fixes: #486
changelog: add new lint [`renamed_function_params`]
Note that the lint name is not final, because I have a bad reputation in naming things, and I don't trust myself.
Lint direct priority conflicts in `[workspace.lints]`
Partially addresses #12729
This still doesn't do any workspace resolution stuff, so it will not catch any virtual workspaces or conflicts from inherited definitions. But while we're parsing the `Cargo.toml` we might as well check the workspace definitions if we find them
changelog: none
Handle `rustc_on_unimplemented` in duplicated_attributes
```rust
#[rustc_on_unimplemented(
on(
_Self = "&str",
label = "`a"
),
on(
_Self = "alloc::string::String",
label = "a"
),
)]
```
The lint treats this as a repetition because `rustc_on_unimplemented:🔛:label` appears twice, but that's ok.
Fixes#12619
changelog: [`duplicated_attributes`]: fix handling of `rustc_on_unimplemented`
Add new lint `doc_lazy_continuation`
changelog: [`doc_lazy_continuation`]: add lint that warns on so-called "lazy paragraph continuations"
This is a follow-up for https://github.com/rust-lang/rust/pull/121659, since most cases of unintended block quotes are lazy continuations. The lint is designed to be more generally useful than that, though, because it will also catch unintended list items and unintended block quotes that didn't coincidentally hit a pulldown-cmark bug.
The second commit is the result of running `cargo dev dogfood --fix`, and manually fixing anything that seems wrong. NOTE: this lint's suggestions should never change the parser's interpretation of the markdown, but in many cases, it seems that doc comments in clippy were written without regard for this feature of Markdown (which, I suppose, is why this lint should exist).
