Fix `needless_borrow` false positive
The PR fixes the false positive exposed by `@BusyJay's` example in: https://github.com/rust-lang/rust-clippy/issues/9111#issuecomment-1277114280
The current approach is described in https://github.com/rust-lang/rust-clippy/pull/9674#issuecomment-1289294201 and https://github.com/rust-lang/rust-clippy/pull/9674#issuecomment-1292225232.
The original approach appears below.
---
The proposed fix is to flag only "simple" trait implementations involving references, a concept
that I introduce next.
Intuitively, a trait implementation is "simple" if all it does is dereference and apply the trait
implementation of a type named by a type parameter. `AsRef` provides a good example of a simple
implementation: https://doc.rust-lang.org/std/convert/trait.AsRef.html#impl-AsRef%3CU%3E-for-%26T
We can make this idea more precise as follows. Given a trait implementation, first determine
whether the implementation is "used defined." If so, then examine its nested obligations.
Consider the implementation simple if-and-only-if:
- there is at least one nested obligation for the same trait
- for each type `X` in the nested obligation's substitution, either `X` is the same as that of
the original obligation's substitution, or the original type is `&X`
For example, the following implementation from `@BusyJay's` example is "complex" (i.e., not simple)
because it produces no nested obligations:
```rust
impl<'a> Extend<&'a u8> for A { ... }
```
On the other hand, the following slightly modified implementation is simple, because it produces
a nested obligation for `Extend<X>`:
```rust
impl<'a, X> Extend<&'a X> for A where A: Extend<X> { ... }
```
How does flagging only simple implementations help? One way of interpreting the false positive in
`@BusyJay's` example is that it separates a reference from a concrete type. Doing so turns a
successful type inference into a failing one. By flagging only simple implementations, we
separate references from type variables only, thereby eliminating this class of false positives.
Note that `Deref` is a special case, as the obligations generated for it already involve the
underlying type.
r? `@Jarcho` (Sorry to keep pinging you with `needless_borrow` stuff. But my impression is no one knows this code better than you.)
changelog: fix `needless_borrow` false positive
Remove `lib.register_*` and `src/docs*` in `cargo dev update_lints`
Follow up to #9709 / #9541
There's a good number of PRs with some leftover `src/docs` files for example, and as a reviewer it's something we're used to ignoring so it can easily slip through
r? `@flip1995`
changelog: none
Track `clippy.toml` and `Cargo.toml` in `file_depinfo`
Causes cargo to re-run clippy when those paths are modified
Also tracks the path to `clippy-driver` in debug mode to remove the workarounds in `cargo dev lint` and `lintcheck` (cc `@matthiaskrgr)`
changelog: Automatically re-run Clippy if `Cargo.toml` or `clippy.toml` are modified
Fixes#2130Fixes#8512
r? `@flip1995`
Causes cargo to re-run clippy when those paths are modified
Also tracks the path to `clippy-driver` in debug mode to remove the
workarounds in `cargo dev lint` and `lintcheck`
make ignored internally mutable types for `mutable-key` configurable
We had some false positives where people would create their own types that had interior mutability unrelated to hash/eq. This addition lets you configure this as e.g. `arc-like-types=["bytes::Bytes"]`
This fixes#5325 by allowing users to specify the types whose innards like `Arc` should be ignored (the generic types are still checked) for the sake of detecting inner mutability.
r? `@Alexendoo`
---
changelog: Allow configuring types to ignore internal mutability in `mutable-key`
Update `from_raw_with_void_ptr` to support types other than `Box`
This PR updates the `from_raw_with_void_ptr` lint, which covered
`Box::from_raw`, to also cover the `from_raw` static method of the
`Rc`, `Arc`, `alloc::rc::Weak` and `alloc::sync::Weak` types.
It also improves the description and error messages of this lint.
---
changelog: [`from_raw_with_void_ptr`]: Now works with the `Rc`, `Arc`, `alloc::rc::Weak` and `alloc::sync::Weak` types.
add new lint `seek_to_start_instead_of_rewind `
changelog: `seek_to_start_instead_of_rewind`: new lint to suggest using `rewind` instead of `seek` to start
Resolve#8600
We had some false positives where people would create their own types
that had interior mutability unrelated to hash/eq. This addition lets
you configure this as e.g. `arc-like-types=["bytes::Bytes"]`
Add lint to tell about let else pattern
Adds a lint to tell the user if the let_else pattern should be used.
~~The PR is blocked probably on rustfmt support, as clippy shouldn't suggest features that aren't yet fully supported by all tools.~~ Edit: I guess adding it as a restriction lint for now is the best option, it can be turned into a style lint later.
---
changelog: addition of a new lint to check for manual `let else`
Sometimes type annotations are needed for type inferrence to work,
or because of coercions. We don't know this, and we also don't
want users to possibly repeat the entire pattern.
This PR updates the `from_raw_with_void_ptr` lint, which covered
`Box::from_raw`, to also cover the `from_raw` static method of the
`Rc`, `Arc`, `alloc::rc::Weak` and `alloc::sync::Weak` types.
It also improves the description and error messages of this lint.
---
changelog: [`from_raw_with_void_ptr`]: Now works with the `Rc`, `Arc`, `alloc::rc::Weak` and `alloc::sync::Weak` types.
Generate lint categories and explanations with `declare_clippy_lint`
This means contributors will no longer have to run `cargo dev update_lints` after changing a lints documentation or its category, which may also mean fewer merge conflicts in general
It works by swapping `declare_clippy_lint` out for a `proc_macro` of the same name. The proc macro emits a `LintInfo` alongside the generated `Lint` which are gathered into `declared_lint::LINTS`. The categories/explanations are then read from `declared_lint::LINTS` at runtime
The removal of `src/docs` is split into a separate commit to be more easily ignored
It is slightly slower though, adding a bit under a second to build time. Less noticeable in full builds or with a slower linker (benchmark uses mold)
```bash
hyperfine --warmup 2 \
--parameter-list commit "declare-proc-macro,master" \
--command-name "{commit}" \
--setup "git checkout {commit}" \
--prepare "touch clippy_lints/src/lib.rs" \
"cargo build"
```
```
Benchmark 1: declare-proc-macro
Time (mean ± σ): 10.731 s ± 0.154 s [User: 7.739 s, System: 1.791 s]
Range (min … max): 10.598 s … 11.125 s 10 runs
Benchmark 2: master
Time (mean ± σ): 9.422 s ± 0.094 s [User: 7.183 s, System: 1.732 s]
Range (min … max): 9.287 s … 9.624 s 10 runs
Summary
'master' ran
1.14 ± 0.02 times faster than 'declare-proc-macro'
```
r? `@flip1995`
cc `@llogiq` for `--explain`
changelog: none
Improvement for `equatable_if_let`
fixes#9221
This PR makes sure that enums or structs not implementing `PartialEq` trait but still using the `if let` patterns can be linted to be rewritten with `matches!`.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
- \[ ] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[ ] Executed `cargo dev update_lints`
- \[ ] Added lint documentation
- \[x] Run `cargo dev fmt`
---
changelog: Improve [`equatable_if_let`] with additional `matches!` suggestions.
Fix allow_attributes_without_reason applying to external crate macros
Previously the `clippy::allow_attributes_without_reason` lint would apply to external crate macros. Many macros in the Rust ecosystem include these `allow` attributes without adding a reason, making this lint pretty much unusable in any sizable Rust project.
This commit fixes that by adding a check to the lint if the attribute is from an external crate macro and returning early.
```
changelog: [`allow_attributes_without_reason`]: allow_attributes_without_reason no longer applies to external crate macros
```
fix: support `map_or` for `or_fun_call` lint
fixes https://github.com/rust-lang/rust-clippy/issues/8993
The methods defined in `KNOW_TYPES`, except for `map_or`, accepts only one argument, so the matching `if let [arg] = args` works only for these methods.
This PR adds `rest_arg` argument to `check_general_case` method and handling of cases with two arguments to support `map_or`.
changelog: `or_fun_call` support `map_or`
* add `rest_arg` to pass second argument from `map_or(U, F)`
* extract some procedures into closure
* add `rest_arg` to pass second argument from `map_or(U, F)`
* extract some procedures into closure
refac: rename rest_arg/second_arg
refac: organize function argument order
* put `second_arg` next to `arg` argument
Mark `let_underscore_lock` and `let_underscore_drop` as uplifted
Here I've renamed both the uplifted lints, however rustc's `let_underscore_lock` is slightly less capable than the clippy lint as it doesn't catch `parking_lot` types or `Result<Guard, ..>`, should we still remove it? The `Result` change looks like it was unintentional to me so that could probably be fixed upstream
changelog: Uplift [`let_underscore_drop`] to rustc https://github.com/rust-lang/rust/pull/97739
changelog: Remove overlap between rustc's `let_underscore_lock` and Clippy's [`let_underscore_lock`]
r? `@flip1995`
