Lint redundant clone of fields
Makes `redundant_clone` warn on unnecessary `foo.field.clone()` sometimes (it can detect an unnecessary clone only if the base of projection, `foo` in this case, is not used at all after that). This is enough for cases like `returns_tuple().0.clone()`.
If there are more than one such assignment, the last one may be
the one supplied to `clone` method.
Makes `find_stmt_assigns_to` internally reverses the iterator to make
the intent to "iterate statements backward" clear.
The path of `libc::c_void` has changes in 5c1a6b8a6d
The DefId path is now always platform specific like
`libc::windows::c_void`. This fixes our c_void detection to only check
the first and last elements.
This now only checks for wildcard_dependencies if the source is a
non-git source.
I tried adding a compiletest suite for the cargo lints, but I was unable
to override the `Cargo.toml` of the original executable.
I tested this manually by modifying the main `Cargo.toml`.
Fixes#3458
I believe if the user already decided to put underscores in their
literal, Clippy should be willing to believe that they put a number of
underscores that they felt was readable.
This lint looks for:
let mut vec = Vec::with_capacity(len);
vec.set_len(len);
The suggested replacement is `vec![0; len]`.
This is far too opinionated to be a deny-by-default lint because the performance
characteristics of the suggested replacement are totally different.
I am not convinced that this lint has value beyond what deny(unsafe_code) gives
you. Unsafe code is unsafe but please don't deny-by-default lint it if that's
the only reason.
Warning was:
warning: the feature `macro_at_most_once_rep` has been stable since 1.32.0 and no longer requires an attribute to enable
--> clippy_lints/src/lib.rs:19:12
|
19 | #![feature(macro_at_most_once_rep)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(stable_features)] on by default
