Rollup of 6 pull requests
Successful merges:
- #87085 (Search result colors)
- #87090 (Make BTreeSet::split_off name elements like other set methods do)
- #87098 (Unignore some pretty printing tests)
- #87099 (Upgrade `cc` crate to 1.0.69)
- #87101 (Suggest a path separator if a stray colon is found in a match arm)
- #87102 (Add GUI test for "go to first" feature)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fix 5707
changelog: ``[`redundant_clone`]``, fix#5707
# Root problem of #5707 :
```
&2:&mut HashMap = &mut _4;
&3:&str = & _5;
_1 = HashMap::insert(move _2,move _3, _);
```
generate PossibleBorrower(_2,_1) and PossibleBorrower(_3,_1).
However, it misses PossibleBorrower(_3,_2).
# My solution to #5707 :
When meet a function call, we should:
1. build PossibleBorrower between borrow parameters and return value (currently)
2. build PossibleBorrower between immutable borrow parameters and mutable borrow parameters (*add*)
3. build PossibleBorrower inside mutable borrow parameters (*add*)
For example:
```
_2: &mut _22;
_3: &mut _;
_4: & _;
_5: & _;
_1 = call(move _2, move _3, move _4, move _5);
```
we need to build
1. return value with parameter(current implementataion)
PossibleBorrower(_2,_1)
PossibleBorrower(_3,_1)
PossibleBorrower(_4,_1)
PossibleBorrower(_5,_1)
2. between mutable borrow and immutable borrow
PossibleBorrower(_4,_2)
PossibleBorrower(_5,_2)
PossibleBorrower(_4,_3)
PossibleBorrower(_5,_3)
3. between mutable borrow and mutable borrow
PossibleBorrower(_3,_2)
PossibleBorrower(_2,_3)
But that's not enough.
Modification to _2 actually apply to _22.
So I write a `PossibleBorrowed` visitor, which tracks (borrower => possible borrowed) relation.
For example (_2 => _22).
However, a lot of problems exist here.
## Known Problems:
1. not sure all `&mut`'s origin are collected.
I'm not sure how to deal with `&mut` when meet a function call, so I didn't do it currently.
Also, my implement is not flow sensitive, so it's not accurate.
```
foo(_2:&mut _, _3: &_)
```
This pr doesn't count _3 as origin of _2.
2. introduce false negative
`foo(_2, _3)` will emit PossibleBorrower(_3,_2) in this pr, but _3 and _2 may not have relation.
Clippy may feel that _3 is still in use because of _2, but actually, _3 is on longer needed and can be moved.
## Insight
The key problem is determine where every `&mut` come from accurately.
I think Polonius is an elegant solution to it. Polonius is flow sensitive and accurate.
But I'm uncertain about whether we can import Polonius in rust-clippy currently.
This pr actually is part of Polonius' functionality, I think.
# TODO
1. `cargo test` can't pass yet due to similar variable name
create method overview docs for core::option and core::result
The `Option` and `Result` types have large lists of methods. They each could use an overview page of methods grouped by category. These proposed overviews include "truth tables" for the underappreciated boolean operators/combinators of these types. The methods are already somewhat categorized in the source, but some logical groupings are broken up by the necessities of putting related methods in different `impl` blocks, for example.
This is based on #86209, but those are small changes and unlikely to conflict.
Avoid cloning ExpnData to access Span edition
ExpnData is a fairly hefty structure to clone; cloning it may not be cheap. In
some cases this may get optimized out, but it's not clear that will always be
the case. Try to avoid that cost.
r? `@ghost` -- opening for a perf run to start with
Add GUI test for "go to first" feature
It adds a test for #85876 to ensure the feature is working as expected and prevent potential regression.
cc ```@jeanlucthumm```
r? ```@Manishearth```
Search result colors
Part of #87072 (fixes the first and fourth regressions and add tests to prevent it from happening again).
cc ````@Nemo157````
r? ````@camelid````
Fix internal `default_hash_types` lint to use resolved path
I run into false positives now and then (mostly in Clippy) when I want to name some util after HashMap.
Fix internal `default_hash_types` lint to use resolved path
I run into false positives now and then (mostly in Clippy) when I want to name some util after HashMap.
ExpnData is a fairly hefty structure to clone; cloning it may not be cheap. In
some cases this may get optimized out, but it's not clear that will always be
the case. Try to avoid that cost.
Refactor `format_args!` expansion parsing
Introduces `FormatExpn::parse` and `FormatArgsExpn::parse`. Motivated by rust-lang/rust#83302, so I only have to change Clippy in one place. Fixed an FP along the way.
I also allowed `needless_bool` in macros because I often want to do `if_chain! { .. then { true } else { false } }`.
changelog: Fix false positive in `useless_format` when some text is appended or prepended to a single string with some useless formatting params
changelog: Allow `needless_bool` in macros
target abi
Implement cfg(target_abi) (RFC 2992)
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.
Gated by `feature(cfg_target_abi)`.
Add a test for `target_abi`, and a test for the feature gate.
Add `target_abi` to tidy as a platform-specific cfg.
Update targets to use `target_abi`
All eabi targets have `target_abi = "eabi".`
All eabihf targets have `target_abi = "eabihf"`.
`armv6_unknown_freebsd` and `armv7_unknown_freebsd` have `target_abi = "eabihf"`.
All abi64 targets have `target_abi = "abi64"`.
All ilp32 targets have `target_abi = "ilp32"`.
All softfloat targets have `target_abi = "softfloat"`.
All *-uwp-windows-* targets have `target_abi = "uwp"`.
All spe targets have `target_abi = "spe"`.
All macabi targets have `target_abi = "macabi"`.
aarch64-apple-ios-sim has `target_abi = "sim"`.
`x86_64-fortanix-unknown-sgx` has `target_abi = "fortanix"`.
`x86_64-unknown-linux-gnux32` has `target_abi = "x32"`.
Add FIXME entries for targets for which existing values need to change
once `cfg_target_abi` becomes stable. (All of them are tier 3 targets.)
Add a test for `target_abi` in `--print cfg`.
Use clang 12.0.1 on dist-x86_64/i686-linux
The LLD + ThinLTO __morestack bug has been fixed in 12.0.1, so
we can now update our clang version. This also means that we no
longer need to build Python 2.
