Use `.into_iter()` rather than `.drain(..)`
Replacing `.drain(..)` with `.into_iter()` makes my project's binary size smaller.
Fixes#1908
Applicability of this suggestion is `MaybeIncorrect` rather than `MachineApplicable` due to the complexity of "checking otherwise usage" X-|
changelog: Add new lint [`iter_with_drain`]
Add `unnecessary_find_map` lint
This PR adds an `unnecessary_find_map` lint. It is essentially just a minor enhancement of `unnecessary_filter_map`.
Closes#8467
changelog: New lint `unnecessary_find_map`
new lint: `missing-spin-loop`
This fixes#7809. I went with the shorter name because the function is called `std::hint::spin_loop`. It doesn't yet detect `while let` loops. I left that for a follow-up PR.
---
changelog: new lint: [`missing_spin_loop`]
Transmute_undefined_repr to nursery again
This PR reinstates #8418, which was reverted in #8425 (incorrectly I think).
I don't want to start a revert war over this but I feel very strongly that this lint is not in a state that would be a net benefit to users of clippy. In its current form, making this an enabled-by-default `correctness` lint with authoritative-sounding proclamations of undefined behavior does more harm than the benefit of the true positive cases.
I can file a bunch more examples of false positives but I don't want to give the author of this lint the impression that it is ready to graduate from `nursery` as soon as I've exhausted the amount of time I am willing to spend revising this lint.
Instead I would recommend that the author of the lint try running it on some reputable codebases containing transmutes. Everywhere that the lint triggers please consider critically whether it should be triggering. For cases that you think are true positives, please raise a few of them with the crate authors (in a PR or issue) to better understand their perspective if they think the transmute is correct.
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: Re-remove [`transmute_undefined_repr`] from default set of enabled lints
tests: use std:🧵:available_parallelism() instead of num_cpus to get thread count
removes the dependency added in https://github.com/rust-lang/rust-clippy/pull/8451
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: tests: use std:🧵:available_parallelism() instead of num_cpus to get thread count
Move testing of cargo dev new_lint to cargo dev workflow
This should be placed there. No need to run this in PR CI, if clippy_dev
isn't touched. (It will be run by bors anyway)
changelog: none
Implement internal lint for MSRV lints
This internal lint checks if the `extract_msrv_attrs!` macro is used if
a lint has a MSRV. If not, it suggests to add this attribute to the lint
pass implementation.
Following up https://github.com/rust-lang/rust-clippy/pull/8280#discussion_r785226072. This currently doesn't implement the documentation check. But since this is just an extension of this lint, I think this is a good MVP of this lint.
r? `@camsteffen`
cc `@xFrednet`
changelog: none
This internal lint checks if the `extract_msrv_attrs!` macro is used if
a lint has a MSRV. If not, it suggests to add this attribute to the lint
pass implementation.
Fix some `unnecessary_filter_map` false positives
This is a proposed fix for #4433.
It moves `clone_or_copy_needed` out of `unnecessary_iter_cloned.rs` and into `methods::utils`. It then adds a check of this function to `unnecessary_filter_map::check`.
Fixes#4433
changelog: none
Update edition in rustfmt.toml
I noticed that our `rustfmt.toml` still has the edition 2018 listed. This updates the configuration to use 2021.
This luckily doesn't introduce any formatting changes 🙃
changelog: none
fix false positives of large_enum_variant
fixes: #8321
The size of enums containing generic type was calculated to be 0.
I changed [large_enum_variant] so that such enums are not linted.
changelog: none
Add `print_in_format_impl` lint
changelog: new lint: [`print_in_format_impl`]
Lints the use of `print`-like macros in manual `Display`/`Debug` impls. I feel like I make this mistake every time I write one 😄
r? `@camsteffen`
Disable ``[`new-without-default`]`` for new() methods that are marked…
… with '#[doc(hidden)]'
Fixes#8152
changelog: Disable ``[`new-without-default`]`` for new() methods that are marked with `#[doc(hidden)]`
False positive redundant_closure when using ref pattern in closure params
fixes#8460
Fixed [redundant_closure] so that closures of which params bound as `ref` or `ref mut ` doesn't trigger the lint.
(e.g. `|ref x| some_expr` doesn't trigger the lint.)
changelog: none
tests: default to more threads for ui-tests
Benchmarks (tested on i5-7200U, 2 cores, 4 threads)
```
master branch:
cargo test // prime caches
cargo --color=always test 70,39s user 21,91s system 180% cpu 51,035 total
cargo --color=always test 70,77s user 22,13s system 180% cpu 51,579 total
cargo --color=always test 70,97s user 22,12s system 180% cpu 51,673 total
cargo --color=always nextest run 78,74s user 22,27s system 220% cpu 45,829 total
cargo --color=always nextest run 78,46s user 21,92s system 224% cpu 44,674 total
cargo --color=always nextest run 78,31s user 22,21s system 228% cpu 43,909 total
Patched (ui_speedup branch):
cargo test // prime cache
cargo --color=always test 97,51s user 32,02s system 288% cpu 44,905 total
cargo --color=always test 99,19s user 31,91s system 276% cpu 47,436 total
cargo --color=always test 98,47s user 31,84s system 284% cpu 45,744 total
cargo --color=always nextest run 102,18s user 30,80s system 350% cpu 37,902 total
cargo --color=always nextest run 99,75s user 29,86s system 350% cpu 36,935 total
cargo --color=always nextest run 100,36s user 29,93s system 351% cpu 37,061 total
```
changelog: use more threads for running clippys ui-tests for ~10% walltime speedup
Don't lint `match` expressions with `cfg`ed arms
Somehow there are no open issues related to this for any of the affected lints. At least none that I could fine from a quick search.
changelog: Don't lint `match` expressions with `cfg`ed arms in many cases
Benchmarks (tested on i5-7200U, 2 core 4 threads)
```
master branch:
cargo test // prime caches
cargo --color=always test 70,39s user 21,91s system 180% cpu 51,035 total
cargo --color=always test 70,77s user 22,13s system 180% cpu 51,579 total
cargo --color=always test 70,97s user 22,12s system 180% cpu 51,673 total
cargo --color=always nextest run 78,74s user 22,27s system 220% cpu 45,829 total
cargo --color=always nextest run 78,46s user 21,92s system 224% cpu 44,674 total
cargo --color=always nextest run 78,31s user 22,21s system 228% cpu 43,909 total
Patched (ui_speedup branch)
cargo test // prime cache
cargo --color=always test 97,51s user 32,02s system 288% cpu 44,905 total
cargo --color=always test 99,19s user 31,91s system 276% cpu 47,436 total
cargo --color=always test 98,47s user 31,84s system 284% cpu 45,744 total
cargo --color=always nextest run 102,18s user 30,80s system 350% cpu 37,902 total
cargo --color=always nextest run 99,75s user 29,86s system 350% cpu 36,935 total
cargo --color=always nextest run 100,36s user 29,93s system 351% cpu 37,061 total
```
