Documented constant expression evaluation for `repeat_once`
Documents the fact that the `repeat_once` lint evaluates constant expressions
---
closes: #7306
changelog: none
(I don't think it's worth a change log entry, as nothing has really changed)
r? `@giraffate` as you've implemented the lint and were part of the discussion in the issue 🙃
similar_names: No longer suggest inserting or appending an underscore
changelog: [`similar_names`] lint no longer suggests to insert or add an underscore to "fix" too similar names
New lint: [`self_named_constructor`]
Adds the `self_named_constructor` lint for detecting when an implemented method has the same name as the type it is implemented for.
changelog: [`self_named_constructor`]
closes: #7142
Remove refs from Pat slices
Changes `PatKind::Or(&'hir [&'hir Pat<'hir>])` to `PatKind::Or(&'hir [Pat<'hir>])` and others. This is more consistent with `ExprKind`, saves a little memory, and is a little easier to use.
Add instructions to run from source
changelog: none
We often get messages on Zulip asking how to install and run Clippy from source. This adds instructions to the readme. I also added a note explaining that `cargo install --path . --force` is bad, which I just decided after some investigating. I use macOS. It would be nice to get some tests on other platforms to see if this is correct.
FP fix and documentation for `branches_sharing_code` lint
Closesrust-lang/rust-clippy#7369
Related rust-lang/rust-clippy#7452 I'm still thinking about the best way to fix this. I could simply add another visitor to ensure that the moved expressions don't modify values being used in the condition, but I'm not totally happy with this due to the complexity. I therefore only documented it for now
changelog: [`branches_sharing_code`] fixed false positive where block expressions would sometimes be ignored.
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
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.
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
