bors [Sun, 6 Mar 2022 07:46:56 +0000 (07:46 +0000)]
Auto merge of #8445 - asquared31415:slice_ptr_cast, r=llogiq
Llint for casting between raw slice pointers with different element sizes
This lint disallows using `as` to convert from a raw pointer to a slice (e.g. `*const [i32]`, `*mut [Foo]`) to any other raw pointer to a slice if the element types have different sizes. When a raw slice pointer is cast, the data pointer and count metadata are preserved. This means that when the size of the inner slice's element type changes, the total number of bytes pointed to by the count changes. For example a `*const [i32]` with length 4 (four `i32` elements) is cast `as *const [u8]` the resulting pointer points to four `u8` elements at the same address, losing most of the data. When the size *increases* the resulting pointer will point to *more* data, and accessing that data will be UB.
On its own, *producing* the pointer isn't actually a problem, but because any use of the pointer as a slice will either produce surprising behavior or cause UB I believe this is a correctness lint. If the pointer is not intended to be used as a slice, the user should instead use any of a number of methods to produce just a data pointer including an `as` cast to a thin pointer (e.g. `p as *const i32`) or if the pointer is being created from a slice, the `as_ptr` method on slices. Detecting the intended use of the pointer is outside the scope of this lint, but I believe this lint will also lead users to realize that a slice pointer is only for slices.
There is an exception to this lint when either of the slice element types are zero sized (e.g `*mut [()]`). The total number of bytes pointed to by the slice with a zero sized element is zero. In that case preserving the length metadata is likely intended as a workaround to get the length metadata of a slice pointer though a zero sized slice.
The lint does not forbid casting pointers to slices with the *same* element size as the cast was likely intended to reinterpret the data in the slice as some equivalently sized data and the resulting pointer will behave as intended.
---
changelog: Added ``[`cast_slice_different_sizes`]``, a lint that disallows using `as`-casts to convert between raw pointers to slices when the elements have different sizes.
bors [Fri, 4 Mar 2022 19:23:39 +0000 (19:23 +0000)]
Auto merge of #8504 - xFrednet:8502-allow-lint-without-reason, r=flip1995
Add lint to detect `allow` attributes without reason
I was considering putting this lint into the pedantic group. However, that would result in countless warnings for existing projects. Having it in restriction also seems good to me :upside_down_face: (And now I need sleep :zzz: )
---
changelog: New lint [`allow_lint_without_reason`] (Requires the `lint_reasons` feature)
bors [Wed, 2 Mar 2022 19:12:32 +0000 (19:12 +0000)]
Auto merge of #8174 - rust-lang:missing-spin-loop, r=flip1995
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.
bors [Wed, 2 Mar 2022 17:05:06 +0000 (17:05 +0000)]
Auto merge of #8432 - dtolnay-contrib:transmuteundefinedrepr2, r=Manishearth
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
bors [Tue, 1 Mar 2022 17:40:52 +0000 (17:40 +0000)]
Auto merge of #8313 - flip1995:msrv-internal-lint, r=xFrednet
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.
flip1995 [Wed, 19 Jan 2022 16:35:52 +0000 (17:35 +0100)]
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.
bors [Mon, 28 Feb 2022 20:09:18 +0000 (20:09 +0000)]
Auto merge of #8479 - smoelius:unnecessary-filter-map, r=llogiq
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`.
bors [Sat, 26 Feb 2022 14:49:39 +0000 (14:49 +0000)]
Auto merge of #8462 - ken-matsui:use-precise-namespace-for-reverse, r=llogiq
Use the precise namespace for `Reverse`
Closes: https://github.com/rust-lang/rust-clippy/issues/8461
changelog: [`unnecessary_sort_by`](https://rust-lang.github.io/rust-clippy/master/index.html#unnecessary_sort_by): Use the precise namespace for `Reverse`
bors [Wed, 23 Feb 2022 18:26:30 +0000 (18:26 +0000)]
Auto merge of #8466 - tamaroning:fix_reduntant_closure, r=Manishearth
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
bors [Tue, 22 Feb 2022 21:58:24 +0000 (21:58 +0000)]
Auto merge of #8451 - matthiaskrgr:ui_speedup, r=llogiq
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
Matthias Krüger [Sun, 20 Feb 2022 12:45:37 +0000 (13:45 +0100)]
tests: default to more threads for ui-tests
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
```
bors [Fri, 18 Feb 2022 22:48:23 +0000 (22:48 +0000)]
Auto merge of #8440 - Jarcho:transmute_undefined, r=Manishearth
Some more fixes for `transmute_undefined_repr`
changelog: Fix transmuting a struct containing a pointer into a pointer in `transmute_undefined_repr`
changelog: Allow various forms of type erasure in `transmute_undefined_repr`
bors [Fri, 18 Feb 2022 19:31:10 +0000 (19:31 +0000)]
Auto merge of #8381 - Jarcho:cast_possible_truncation_542, r=Manishearth
Lint enum-to-int casts with `cast_possible_truncation`
fixes: #542
~~This will not lint casting a specific variant to an integer. That really should be a new lint as it's definitely a truncation (other than `isize`/`usize` values).~~
changelog: Lint enum-to-int casts with `cast_possible_truncation`
changelog: New lint `cast_enum_truncation`
bors [Fri, 18 Feb 2022 10:55:05 +0000 (10:55 +0000)]
Auto merge of #8419 - flip1995:await_parking_alot, r=llogiq
Fix `await_holding_lock` not linting `parking_lot` Mutex/RwLock
This adds tests for `RwLock` and `parking_lot::{Mutex, RwLock}`, which were added before in https://github.com/rust-lang/rust-clippy/commit/2dc8c083f54454ca87bb09d691577eada2d23539, but never tested in UI tests. I noticed this while reading [fasterthanli.me](https://fasterthanli.me/articles/a-rust-match-made-in-hell) latest blog post, complaining that Clippy doesn't catch this for `parking_lot`. (Too many people read his blog, he's too powerful)
Some more things:
- Adds a test for #6446
- Improves the lint message
changelog: [`await_holding_lock`]: Now also lints for `parking_lot::{Mutex, RwLock}`
flip1995 [Thu, 17 Feb 2022 16:57:39 +0000 (17:57 +0100)]
Move await_holding_* lints to suspicious and improve doc
Even though the FP for that the lints were moved to pedantic isn't fixed
yet, running the lintcheck tool over the most popular 279 crates didn't
trigger this lint once. I would say that this lint is valuable enough,
despite the known FP, to be warn-by-default. Especially since a pretty
nice workaround exists.
This is a temporary fix for `needless_borrow`. The proper fix is included in #8355.
This should probably be merged into rustc before beta branches on Friday. This issue has been reported six or seven times in the past couple of weeks.
changelog: Fix various issues with `needless_borrow` n´. Note to changelog writer: those issues might have been introduced in this release cycle, so this might not matter in the changelog.