Auto merge of #9501 - xFrednet:changelog-1.64, r=llogiq
Changelog for Rust 1.64 :apple:
The normal release preparation dance. I've written the changelog like the version has already been released. The PR can be approved and then merged by anyone after the release of Rust 1.64 :upside_down_face:
changelog: Enhancement: [`nonstandard_macro_braces`]: Now includes `matches!()` in the default lint config
[#9471](https://github.com/rust-lang/rust-clippy/pull/9471)
Auto merge of #9505 - mikerite:fix-9504-2, r=dswij
Fix ICE in `unnecessary_to_owned`
Fixes #9504
Compiler generated call `into_future` nodes return empty substs which we need when checking it's predicates. Handle this by simply exitting when we encounter one. This change introduces false negatives in place of the ICEs.
Michael Wright [Wed, 21 Sep 2022 05:02:52 +0000 (07:02 +0200)]
Fix ICE in `unnecessary_to_owned`
Fixes #9504
Compiler generated call `into_iter` nodes return empty substs
which we need when checking it's predicates. Handle this by
simply exitting when we encounter one. This change introduces
false negatives in place of the ICEs.
Extends https://github.com/rust-lang/rust-clippy/pull/9474 to also take into consideration "raw" binary operations. For example, `let a = b / 2` and `let a = 1 * b` won't trigger the lint.
Add `#[allow(unused)]` to test in `cargo dev new_lint`
`rustfix` tests don't automatically apply `-Aunused` which leads to some tests having `_workarounds`, add it to new test files automatically so people don't have to worry about it
Auto merge of #9481 - giraffate:fix_indents, r=xFrednet
Fix indents
Markdowns are not displayed correctly.
https://github.com/rust-lang/rust-clippy/blob/master/book/src/development/common_tools_writing_lints.md#dealing-with-macros-and-expansions
r-a uses the `rustc-dev` component from the rustup installed toolchain clippy specifies so it doesn't need to be manually installed. Also remove references to nightly r-a as the feature is long stable
I discovered `rust-analyzer.linkedProjects` recently and it has made working on the crates not referenced by the `clippy` crate so much nicer
Auto merge of #9475 - Nemo157:mod-files-remap, r=xFrednet
Make module-style lints resilient to --remap-path-prefix
changelog: [`self_named_module_files`], [`mod_module_files`]: Make module-style lints resilient to `--remap-path-prefix`
Without this if a user has configured `--remap-path-prefix` to be used for a prefix containing the current source directory the lints would silently fail to generate a warning.
Auto merge of #9476 - Xaeroxe:bool-to-int-inverted, r=xFrednet
`bool_to_int_with_if` inverse case patch
Enhances `bool_to_int_with_if` such that it can also catch an inverse bool int conversion scenario, and makes the right suggestion for converting to int with a prefixed negation operator.
changelog: [`bool_to_int_with_if`]: Now correctly detects the inverse case, `if bool { 0 } else { 1 }`
Auto merge of #8518 - Alexendoo:write-late-pass, r=flip1995
Migrate write.rs to a late pass
changelog: Migrates write.rs from a pre expansion pass to a late pass
changelog: [`positional_named_format_parameters`] is renamed in favour of the rustc lint `named_arguments_used_positionally`
- Macros are now identified by diagnostic items, so will no longer lint user defined macros named, e.g. a custom `print!`
- `print_literal`/`write_literal` no longer lint no longer lint literals that come from macro expansions, e.g. `env!("FOO")`
- `print_with_newline`/`write_with_newline` no longer lint strings with any internal `\r` or `\n`s
~~A false negative, `print_literal`/`write_literal` don't lint format strings that produce `FormatSpec`s, e.g. ones containing pretty print/width/align specifiers~~
Suggestion changes:
- ~~`print_literal`/`write_literal` no longer have suggestions, as the spans for the `{}`s were not easily obtainable~~
- `print_with_newline`/`write_with_newline` has a better suggestion for a sole literal newline, but no longer has suggestions for len > 1 strings that end in a literal newline
- ~~`use_debug` spans are less precise, now point to the whole format string~~
The diff for write.rs is pretty unwieldy, other than for the `declare_clippy_lint!`s I think you'd be better off viewing it as a brand new file rather than looking at the diff, as it's mostly written from scratch
Auto merge of #9465 - Alexendoo:peekable-fp, r=flip1995
Fix `unused_peekable` closure and `f(&mut peekable)` false positives
changelog: Fix [`unused_peekable`] false positive when peeked in a closure or called as `f(&mut peekable)`
The `return`/`break` changes aren't part of the fix, they allow an earlier return in some cases. `break` is replaced with `return` for style purposes as they do the same thing in this case
We now check if the linted `Expr` is inside an `ItemKind::Static`, which can't take the suggested `Box<[...]`. I _think_ this is the correct fix for #9460
Auto merge of #9448 - Alexendoo:large-enum-variant-u128, r=Manishearth
Replace u128 with u64 in large_enum_variant uitest
A u128 has [an 8 byte alignment on x86](https://github.com/rust-lang/rust/issues/54341), but a 16 byte alignment on aarch64 which changes the size of the enums due to extra padding. This means the test fails on aarch64
Auto merge of #9446 - mikerite:fix-9431-2, r=giraffate
Fix `range_{plus,minus}_one` bad suggestions
Fixes #9431.
The current `range_plus_one` and `range_minus_one` suggestions are completely incorrect when macros are involved.
This commit resolves this by disabling the lints for any range expression that is expanded from a macro. The reasons for this are that it is very difficult to create a correct suggestion in this case and that false negatives are less important for pedantic lints.
changelog: Fix `range_{plus,minus}_one` bad suggestions
Michael Wright [Thu, 8 Sep 2022 18:04:43 +0000 (20:04 +0200)]
Fix `range_{plus,minus}_one` bad suggestions
Fixes #9431.
The current `range_plus_one` and `range_minus_one` suggestions
are completely incorrect when macros are involved.
This commit resolves this by disabling the lints for any range
expression that is expanded from a macro. The reasons for this
are that it is very difficult to create a correct suggestion in
this case and that false negatives are less important for
pedantic lints.
Fixes https://github.com/rust-lang/rust-clippy/issues/9307 and makes the `arithmetic` lint behave like `integer_arithmetic`.
It is worth noting that literal integers of a binary operation (`1 + 1`, `i32::MAX + 1`), **regardless if they are in a constant environment**, won't trigger the lint. Assign operations also have similar reasoning.
changelog: Consider literals in the arithmetic lint
Auto merge of #101241 - camsteffen:refactor-binding-annotations, r=cjgillot
`BindingAnnotation` refactor
* `ast::BindingMode` is deleted and replaced with `hir::BindingAnnotation` (which is moved to `ast`)
* `BindingAnnotation` is changed from an enum to a tuple struct e.g. `BindingAnnotation(ByRef::No, Mutability::Mut)`
* Associated constants added for convenience `BindingAnnotation::{NONE, REF, MUT, REF_MUT}`
One goal is to make it more clear that `BindingAnnotation` merely represents syntax `ref mut` and not the actual binding mode. This was especially confusing since we had `ast::BindingMode`->`hir::BindingAnnotation`->`thir::BindingMode`.
I wish there were more symmetry between `ByRef` and `Mutability` (variant) naming (maybe `Mutable::Yes`?), and I also don't love how long the name `BindingAnnotation` is, but this seems like the best compromise. Ideas welcome.
Suggest `Entry::or_default` for `Entry::or_insert(Default::default())`
Unlike past similar work done in #6228, expand the existing `or_fun_call`
lint to detect `or_insert` calls with a `T::new()` or `T::default()`
argument, much like currently done for `unwrap_or` calls. In that case,
suggest the use of `or_default`, which is more idiomatic.
Note that even with this change, `or_insert_with(T::default)` calls
aren't detected as candidates for `or_default()`, in the same manner
that currently `unwrap_or_else(T::default)` calls aren't detected as
candidates for `unwrap_or_default()`.
Also, as a nearby cleanup, change `KNOW_TYPES` from `static` to `const`,
since as far as I understand it's preferred (should Clippy have a lint
for that?).
Addresses #3812.
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`or_fun_call`]: Suggest `Entry::or_default` for `Entry::or_insert(Default::default())`
relrelb [Tue, 16 Aug 2022 20:26:03 +0000 (23:26 +0300)]
Suggest `Entry::or_default` for `Entry::or_insert(Default::default())`
Unlike past similar work done in #6228, expand the existing `or_fun_call`
lint to detect `or_insert` calls with a `T::new()` or `T::default()`
argument, much like currently done for `unwrap_or` calls. In that case,
suggest the use of `or_default`, which is more idiomatic.
Note that even with this change, `or_insert_with(T::default)` calls
aren't detected as candidates for `or_default()`, in the same manner
that currently `unwrap_or_else(T::default)` calls aren't detected as
candidates for `unwrap_or_default()`.
Also, as a nearby cleanup, change `KNOW_TYPES` from `static` to `const`,
since as far as I understand it's preferred (should Clippy have a lint
for that?).
Auto merge of #9424 - mikerite:fix-9351-4, r=xFrednet
Fix `unnecessary_to_owned` false positive
Fixes #9351.
Note that this commit reworks that fix for #9317. The change
is to check that the type implements `AsRef<str>` before regarding
`to_string` as an equivalent of `to_owned`. This was suggested
by Jarcho in the #9317 issue comments.
The benefit of this is that it moves some complexity out of
`check_other_call_arg` and simplifies the module as a whole.
changelog: FP: [`unnecessary_to_owned`]: No longer lints, if type change would cause errors in the caller function
Michael Wright [Sat, 3 Sep 2022 15:00:44 +0000 (17:00 +0200)]
Fix `unnecessary_to_owned` false positive
Fixes #9351.
Note that this commit reworks that fix for #9317. The change
is to check that the type implements `AsRef<str>` before regarding
`to_string` as an equivalent of `to_owned`. This was suggested
by Jarcho in the #9317 issue comments.
The benefit of this is that it moves some complexity out of
`check_other_call_arg` and simplifies the module as a whole.
Auto merge of #9400 - lukaslueg:approx_large_enum, r=llogiq
Use `approx_ty_size` for `large_enum_variant`
This builds upon #9373 to use the approximate size of each variant for `large_enum_variant`. This allows us to lint in situations where an `enum` contains generics but is still guaranteed to have a large variant on an at-least basis, e.g. with `(T, [u8; 512])`.
* I've changed the wording from "is ... bytes" to "contains at least" because
* the size is now an approximate lower bound (e.g. `512` in the example above). The actual size is larger due to `T`, including due to `T`'s memory layout.
* the discriminant is not taken into account in the message. This comes up with variants like `A(T)`, which are "is at least 0 bytes" otherwise, which may be misleading.
* If the second-largest variant has no fields, there is a special case "carries no data" instead of "is at least 0 bytes".
* A variant like `A(T)` is "at least 0 bytes", which is technically true, yet we don't distinguish between "indeterminate" and truly "ZST".
* The generics-tests that were there before now lint while they didn't lint before. AFAICS this is correct.
I guess the above is correct-ish. However, I use the `SubstsRef` that I got via `cx.tcx.type_of(item.def_id)` to solve for generics in the variants. Is this even applicable, since we start from an - [ ] `ItemKind`?
Auto merge of #9418 - lukaslueg:issue9415, r=llogiq
Fix `mut_mutex_lock` when Mutex is behind immutable deref
I *think* the problem here is the `if let ty::Ref(_, _, Mutability::Mut) = cx.typeck_results().expr_ty(recv).kind()` line tries to check if the `Mutex` can be mutably borrowed (there already is a test for `Arc<Mutex<_>>`), but gets bamboozled by the `&mut Arc` indirection. And I *think* checking the deref-adjustment to filter immutable-adjust (the deref through the `Arc`, starting from `&mut Arc`) is the correct fix.
Fixes #9415
changelog: Fix `mut_mutex_lock` when Mutex is behind immutable deref
projects / rust.git / log