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
update Miri
I had to use a hacked version of josh to create this, so let's be careful with merging this and maybe wait a bit to see if the josh issue becomes more clear. But the history looks good to me, we are not adding duplicates of rustc commits that were previously mirrored to Miri.
Also I want to add some cross-testing of Miri in x.py.
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
