Dan Gohman [Mon, 2 May 2022 20:46:29 +0000 (13:46 -0700)]
Fix `cast_lossless` to avoid warning on `usize` to `f64` conversion.
Previously, the `cast_lossless` lint would issue a warning on code that
converted a `usize` value to `f64`, on 32-bit targets.
`usize` to `f64` is a lossless cast on 32-bit targets, however there is
no corresponding `f64::from` that takes a `usize`, so `cast_lossless`'s
suggested replacement does not compile.
This PR disables the lint in the case of casting from `usize` or `isize`.
Fixes #3689.
changelog: [`cast_lossless`] no longer gives wrong suggestion on usize->f64
Auto merge of #8764 - dtolnay-contrib:checkoutv3, r=llogiq
Update GitHub Actions actions/checkout@v2 to v3
The v2 implementation uses Node 12, which is end-of-life on April 30, 2022. See https://nodejs.org/en/about/releases/. Update to v3, which is based on Node 16 whose support lasts until April 30, 2024.
David Tolnay [Sat, 30 Apr 2022 02:28:03 +0000 (19:28 -0700)]
Update GitHub Actions actions/checkout@v2 to v3
The v2 implementation uses Node 12, which is end-of-life on April 30, 2022.
See https://nodejs.org/en/about/releases/. Update to v3, which is based on
Node 16 whose support lasts until April 30, 2024.
Auto merge of #8743 - Alexendoo:useless-attribute-redundant-pub-crate, r=llogiq
ignore `redundant_pub_crate` in `useless_attribute`
changelog: [`useless_attribute`] no longer lints [`redundant_pub_crate`]
As mentioned in https://github.com/rust-lang/rust-clippy/issues/8732#issuecomment-1106489634
> And it turns out I can't even explicitly allow it at the usage site, because then `clippy::useless_attribute` fires (which would also be a FP?), which is deny-by-default.
>
> Though it does work if I then allow `clippy::useless_attribute`. 😂
>
> ```rust
> #[allow(clippy::useless_attribute)]
> #[allow(clippy::redundant_pub_crate)]
> pub(crate) use bit;
> ```
>
> The originally-reported warning now no longer occurs.
Avoids changing the drop order in an observable way, where the type of `x` has a drop with side effects and something between `x` and the first use also does, e.g.
The implementation of `type_needs_ordered_drop_inner` was changed a bit, it now uses `Ty::has_significant_drop` and reordered the ifs to check diagnostic name before checking the implicit drop impl
changelog: [`needless_late_init`]: No longer lints `if let` statements, `let mut` bindings and no longer significantly changes drop order
This PR fixes 2 things:
- The known problem that integer types are always suggested as signed, by suggesting an unsigned suffix for literals that wouldnt fit in the signed type, and ignores any literals too big for the corresponding unsigned type too.
- The lint would only look at the integer part of any floating point literals without an exponent, this causing #6129. This just ignores those literals.
Examples:
```rust
let _ = 2_32; // still 2_i32
let _ = 234_8; // would now suggest 234_u8
// these are now ignored
let _ = 500_8;
let _ = 123_32.123;
```
changelog: suggest correct integer types in [`mistyped_literal_suffix`], ignore float literals without an exponent
fixes #6129
mistyped_literal_suffixes: improve suggestions for integer types
Instead of just always suggesting signed suffixes regardless of size
of the value, it now suggests an unsigned suffix when the value wouldn't
fit into the corresponding signed type, and ignores the literal entirely
if it is too big for the unsigned type as well.
It's only a warning so this wasn't causing the test to fail, but if you had another error somewhere or used `--nocapture` the extra warnings would be shown
Auto merge of #8716 - binggh:stable-sort-message-update, r=giraffate
Less authoritative stable_sort_primitive message
fixes #8241
Hey all - first contribution here so I'm deciding to start with something small.
Updated the linked message to be less authoritative as well as moved the lint grouping from `perf` to `pedantic` as suggested by `@camsteffen` under the issue.
changelog: [`stable_sort_primitive`]: emit less authoritative message and move to `pedantic`
Auto merge of #8700 - youknowone:needless_match-false-positive, r=xFrednet
Fix needless_match false positive for if-let when the else block doesn't match to given expr
<!--
Thank you for making Clippy better!
We're collecting our changelog from pull request descriptions.
If your PR only includes internal changes, you can just write
`changelog: none`. Otherwise, please write a short comment
explaining your change. Also, it's helpful for us that
the lint name is put into brackets `[]` and backticks `` ` ` ``,
e.g. ``[`lint_name`]``.
If your PR fixes an issue, you can add "fixes #issue_number" into this
PR description. This way the issue will be automatically closed when
your PR is merged.
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
Auto merge of #8707 - OneSignal:await-invalid-types, r=llogiq
Add `await_holding_invalid_type` lint
changelog: [`await_holding_invalid_type`]
This lint allows users to create a denylist of types which are not allowed to be
held across await points. This is essentially a re-implementation of the
language-level [`must_not_suspend`
lint](https://github.com/rust-lang/rust/issues/83310). That lint has a lot of
work still to be done before it will reach Rust stable, and in the meantime
there are a lot of types which can trip up developers if they are used
improperly.
I originally implemented this specifically for `tracing::span::Entered`, until I discovered #8434 and read the commentary on that PR. Given this implementation is fully user configurable, doesn't tie clippy to any one particular crate, and introduces no additional dependencies, it seems more appropriate.
Auto merge of #8701 - xFrednet:0000-clippy-print-hir-attr, r=flip1995
Rework `#[clippy::dump]` attribute for debugging
Hey `@rust-lang/clippy,` this adds a new `#[clippy::print_hir]` attribute that prints the node to the console using `{:#?}`. Personally, I use print debugging quite a lot while working on Clippy, and this is a simple shortcut that also works in the playground (Once this has been synced). The question is now, if we want to have this attribute. Are there any concerns? I think it's similar to our `#[clippy::author]` attribute.
I haven't added a test, as the `.stdout` file would require updates with every HIR change inside rustc. Here are some examples, for the current implementation
Lily Mara [Thu, 14 Apr 2022 23:52:10 +0000 (16:52 -0700)]
Add `await_holding_invalid_type` lint
changelog: [`await_holding_invalid_type`]
This lint allows users to create a denylist of types which are not allowed to be
held across await points. This is essentially a re-implementation of the
language-level [`must_not_suspend`
lint](https://github.com/rust-lang/rust/issues/83310). That lint has a lot of
work still to be done before it will reach Rust stable, and in the meantime
there are a lot of types which can trip up developers if they are used
improperly.
Auto merge of #8705 - cpw2n5:spellcheck, r=Manishearth
Spellcheck
I'm brand new to this so any feedback will be helpful. I set the project up locally and ran a spellcheck on it. The code changes should only be spelling corrections. I ran the build and tests and they came back successful locally.
changelog: Various spelling corrections in comments and code.
This adds test to make sure correct behavior of lint
- The first test's option variable is not a temporary variable
- The second test does not make usage of `take()`
- The third test makes usage of `take()` and uses a temporary variable
Instead of type checking the entire expression (causing a false
positive), only type check for a subset of the expression (the receiver of
the matched function: `take()`)
This lint checks if Option::take() is used on a temporary value (a value
that is not of type &mut Option and that is not a Place expression) to
suggest omitting take()