There was some dependence between the different subcommands of clippy_dev. And
this dependence will increased with the introduction of the sync and release
subcommands. This moves the common functions to a `utils` module, to decouple
the other modules.
This allows us to use the method in both `fmt.rs` and `lib.rs` in
multiple places. The downside is that we panic inside the method now,
instead of using the error handling in `fmt.rs`. We may want to
centralize the error handling for clippy_dev at some point, though.
If you've been using `./util/dev` before, this now becomes `cargo dev`.
The key part of this change is found in `.cargo/config`.
This means one less shell script and a bit more cross-platform support
for contributors.
Fix false-positive of redundant_clone and move to clippy::perf
This PR introduces dataflow analysis to `redundant_clone` lint to filter out borrowed variables, which had been incorrectly detected.
Depends on https://github.com/rust-lang/rust/pull/64207.
changelog: Moved `redundant_clone` lint to `perf` group
# What this lint catches
## `clone`/`to_owned`
```rust
let s = String::new();
let t = s.clone();
```
```rust
// MIR
_1 = String::new();
_2 = &_1;
_3 = clone(_2); // (*)
```
We can turn this `clone` call into a move if
1. `_2` is the sole borrow of `_1` at the statement `(*)`
2. `_1` is not used hereafter
## `Deref` + type-specific `to_owned` method
```rust
let s = std::path::PathBuf::new();
let t = s.to_path_buf();
```
```rust
// MIR
_1 = PathBuf::new();
_2 = &1;
_3 = call deref(_2);
_4 = _3; // Copies borrow
StorageDead(_2);
_5 = Path::to_path_buf(_4); // (*)
```
We can turn this `to_path_buf` call into a move if
1. `_3` `_4` are the sole borrow of `_1` at `(*)`
2. `_1` is not used hereafter
# What this PR introduces
1. `MaybeStorageLive` that determines whether a local lives at a particular location
2. `PossibleBorrowerVisitor` that constructs [`TransitiveRelation`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/transitive_relation/struct.TransitiveRelation.html) of possible borrows, e.g. visiting `_2 = &1; _3 = &_2:` will result in `_3 -> _2 -> _1` relation. Then `_3` and `_2` will be counted as possible borrowers of `_1` in the sole-borrow analysis above.
