Auto merge of #9120 - anall:bugfix/ice9041, r=Jarcho
Fix ICE in sugg::DerefDelegate with (named) closures
rustc comiler internals helpfully tell us how to fix the issue:
```
to get the signature of a closure, use `substs.as_closure().sig()` not `fn_sig()`
```
Fixes ICE in #9041
This also makes this code in `sugg::DerefDelegate` match a different use `typ.fn_sig(…)` I found: in `mixed_read_write_in_expression` -- being strict on the value of `typ.kind()` will hopefully reduce any future possibility of ICE crashes in this area.
Auto merge of #9132 - hellow554:maybe_trait_bound_on_type_repetition, r=Manishearth
Maybe trait bound on type repetition
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: fix maybe trait on [`type_repetition_in_bounds`] lint
I simplified the two for loops, which did exactly the same. Only downside is, that I need a `copied`, but that's to convert from `&&` to `&`, to that should be a noop?
One more thing: I only handle [`TraitBoundModifier::Maybe`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/enum.TraitBoundModifier.html#variant.Maybe). Can anyone give me an example (and testcase) for [`TraitBoundModifier::MaybeConst`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/enum.TraitBoundModifier.html#variant.MaybeConst)?
the two loops did practically the same, only the type were different (&&
vs &), so I used `copied` to convert `&&` and chained them together.
Instead of parsing the trait info manually, I use the already provided
method `get_trait_info_from_bound`.
Also, instead of using manual string writing, I used `join` by
`itertools`.
bors [Thu, 30 Jun 2022 19:24:50 +0000 (19:24 +0000)]
Auto merge of #9078 - hamza1311:patch-1, r=xFrednet
Fix broken hyperlink in documentation
changelog: none
The hyperlinks in [`is_digit_ascii_radix`](https://rust-lang.github.io/rust-clippy/master/index.html#is_digit_ascii_radix)'s docs are broken. This PR fixes those.
bors [Thu, 30 Jun 2022 17:33:33 +0000 (17:33 +0000)]
Auto merge of #9058 - xFrednet:changelog-1-62, r=flip1995
Changelog for Rust 1.62 :t-rex:
This special artifact was just discovered. The artifact details changes to something called Clippy. Presently and from the context, we were unable to determine what this is supposed to be. All we know, is that it seems to have an active community around it which supports it. The members sometimes use paper clips as a secret symbol for Clippy.
I want to donate this artifact to the rust-lang organization, to have it displayed to the public.
bors [Thu, 30 Jun 2022 16:24:03 +0000 (16:24 +0000)]
Auto merge of #9074 - daxpedda:equatable-if-let-external-macro, r=Manishearth
Fix false-positive in `equatable_if_let`
Was linting in external macros. I guess now that I know about https://github.com/rust-lang/rust-clippy/pull/8694 it seems all kinda pointless until we resolve that.
Nevertheless, it's an improvement.
Fixes #9066.
changelog:`equatable_if_let` No longer lint on macros
bors [Thu, 30 Jun 2022 10:43:39 +0000 (10:43 +0000)]
Auto merge of #9071 - Alexendoo:8734, r=dswij
Uncomment test for #8734
I believe the issue was an interaction between rustfix and `span_lint_and_sugg_for_edges`, so this would've been fixed by https://github.com/rust-lang/rust/pull/98261 (Thanks, `@WaffleLapkin!)`
bors [Thu, 30 Jun 2022 10:27:24 +0000 (10:27 +0000)]
Auto merge of #9070 - flip1995:ci-fix, r=xFrednet
Make sure bors success depends on metadata_collection
r? `@xFrednet`
Currently bors runs the `metadata_collection` but merges before the run is finished, because the bors success dummy step didn't depend on it. This also makes sure that the `metadata_collection` test is run at the same time as the other base runs to not produce overhead.
bors [Thu, 30 Jun 2022 04:04:08 +0000 (04:04 +0000)]
Auto merge of #8666 - Jarcho:while_let_loop_7913, r=dswij
Don't lint `while_let_loop` when significant drop order would change
fixes #7226
fixes #7913
fixes #5717
For #5717 it may not stay fully fixed. This is only completely fixed right now due to all the allowed drop impls have `#[may_dangle]` on their drop impls. This may get changed in the future based on how significant drops are determined, but the example listed with `RefCell` shouldn't break.
changelog: Don't lint `while_let_loop` when the order of significant drops would change
bors [Tue, 28 Jun 2022 18:28:38 +0000 (18:28 +0000)]
Auto merge of #9046 - xFrednet:rust-97660-expection-something-something, r=Jarcho
Fix `#[expect]` for most clippy lints
This PR fixes most `#[expect]` - lint interactions listed in rust-lang/rust#97660. [My comment in the issue](https://github.com/rust-lang/rust/issues/97660#issuecomment-1147269504) shows the current progress (Once this is merged). I plan to work on `duplicate_mod` and `multiple_inherent_impl` and leave the rest for later. I feel like stabilizing the feature is more important than fixing the last few nits, which currently also don't work with `#[allow]`.
bors [Tue, 28 Jun 2022 18:09:26 +0000 (18:09 +0000)]
Auto merge of #8355 - Jarcho:explicit_auto_deref_2, r=flip1995
Add lint `explicit_auto_deref` take 2
fixes: #234
fixes: #8367
fixes: #8380
Still things to do:
* ~~This currently only lints `&*<expr>` when it doesn't trigger `needless_borrow`.~~
* ~~This requires a borrow after a deref to trigger. So `*<expr>` changing `&&T` to `&T` won't be caught.~~
* The `deref` and `deref_mut` trait methods aren't linted.
* Neither ~~field accesses~~, nor method receivers are linted.
* ~~This probably shouldn't lint reborrowing.~~
* Full slicing to deref should probably be handled here as well. e.g. `&vec[..]` when just `&vec` would do
bors [Tue, 28 Jun 2022 07:27:08 +0000 (07:27 +0000)]
Auto merge of #8774 - hellow554:cargo-rust-version, r=flip1995
try reading rust-version from Cargo.toml
Cargo.toml can contain a field `rust-version`, that acts like a MSRV of
clippy.toml file: https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field
This will try to read that field and use it, if the clippy.toml config
has no `msrv` entry
changelog: respect `rust-version` from `Cargo.toml`