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`
bors [Tue, 28 Jun 2022 07:03:57 +0000 (07:03 +0000)]
Auto merge of #8639 - Jarcho:trivially_copy_pass_by_ref_5953, r=dswij
`trivially_copy_pass_by_ref` fixes
fixes #5953
fixes #2961
The fix for #5953 is overly aggressive, but the suggestion is so bad that it's worth the false negatives. Basically three things together:
* It's not obviously wrong
* It compiles
* It may actually work when tested
changelog: Don't lint `trivially_copy_pass_by_ref` when unsafe pointers are used.
changelog: Better track lifetimes when linting `trivially_copy_pass_by_ref`.
Marcel Hellwig [Mon, 27 Jun 2022 09:11:52 +0000 (11:11 +0200)]
parse `Cargo.toml` file in ui-cargo tests
compiletest_rs is not meant to test full cargo projects, but instead
only files.
So we need to parse the `Cargo.toml` file ourself and set the
corresponding environment variable. In this case we just set
`CARGO_PKG_RUST_VERSION`, nothing more. But, of course, this can be
extended.
Marcel Hellwig [Mon, 2 May 2022 09:31:39 +0000 (11:31 +0200)]
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
bors [Mon, 27 Jun 2022 00:05:50 +0000 (00:05 +0000)]
Auto merge of #8939 - Jarcho:transmute_ptr_to_ref_lt, r=giraffate
Suggest `pointer::cast` when possible in `transmute_ptr_to_ref`
fixes #8924
changelog: Suggest casting the pointer for any type containing lifetimes in `transmute_ptr_to_ref`.
changelog: Suggest `pointer::cast` when possible in `transmute_ptr_to_ref`.
bors [Sat, 25 Jun 2022 16:48:34 +0000 (16:48 +0000)]
Auto merge of #8985 - botahamec:single-match-option, r=llogiq
Lint `[single_match]` on `Option` matches
fixes #8928
changelog: did some cleanup of the logic for ``[`single_match`]`` and ``[`single_match_else`]`` which fixes the bug where `Option` matches were not linted unless a wildcard was used for one of the arms.
bors [Fri, 24 Jun 2022 08:39:45 +0000 (08:39 +0000)]
Auto merge of #9037 - smoelius:fix-extra-unused-lifetimes-fp, r=dswij
Fix `extra_unused_lifetimes` false positive
This PR fixes #9014.
I confirmed the FP on the `crates.io` source as `@JohnTitor` mentioned, and confirmed that the FP is no longer present following this change.
I did not include a test in this PR because I think constructing one would be complicated, and the fix is pretty simple. But please let me know if this is unacceptable.
bors [Fri, 24 Jun 2022 02:26:35 +0000 (02:26 +0000)]
Auto merge of #9036 - xFrednet:0000-force-warn-in-driver, r=dswij
Check for `--force-warn` in Clippy's driver run condition
Just a thing I've noticed while tinkering on the driver. Currently, the driver only checks for `--cap-lints=allow` to determine if Clippy should run on the code, but ignores possible `--force-warn` arguments
---
changelog: Others: Allowing all lints and only `--force-warn`ing some will now work with Clippy's driver