new lint: `only_used_in_recursion`
changed:
- added `only_used_in_recursion`.
- fixed code that variables are only used in recursion.
- this would not lint when `unused_variable`
This fixes: #8390
-----
changelog: add lint [`only_used_in_recursion`]
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.
Only point at the end of the crate. We could try making it point at the
beginning of the crate, but that is confused with `DUMMY_SP`, causing
the output to be *worse*.
This change will make it so that VSCode will *not* underline the whole
file when `main` is missing, so other errors will be visible.
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 🙃 (And now I need sleep 💤 )
---
changelog: New lint [`allow_lint_without_reason`] (Requires the `lint_reasons` feature)
Closes: rust-lang/rust-clippy#8502
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`]
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 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
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
```
