`|x: String| {x}.clone()` applies `clone()` to `{x}`, while `|x: String|
-> String {x}.clone()` applies `.clone()` to the closure because a
closure with an explicit return type requires a block as its body.
This extends the `precedence` lint to suggest using parentheses around
the closure definition in the second case, when `.clone()` would apply
to the whole closure.
changelog: [`precedence`]: warn about ambiguity when a closure is used
as a method call receiver
[Related
discussion](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Closure.20syntax.20ambiguity/with/504671477)
`|x: String| {x}.clone()` applies `clone()` to {x}, while
`|x: String| -> String {x}.clone()` applies `.clone()` to
the closure because a closure with an explicit return type
requires a block.
This extends the `precedence` lint to suggest using parentheses
around the closure definition when the closure would be cloned,
as in `(|x: String| -> String {x}).clone()`.
`let-else` statements do not allow the init expression to end with '}'
Fixesrust-lang/rust-clippy#15914
changelog: [`manual_let_else`]: If the init expression ends with `'}'`
wrap it with `(...)`
- Make the diagnostic message actually desribe the problem
- Always give the suggestion, by using `snippet_with_context`
- Make the suggestion verbose, because we sometimes lint multiline exprs
like `match`es
changelog: [`manual_option_as_slice`]: improve diagnostics
- only lint on definitions of offending mutexes, not all their uses
(fixes https://github.com/rust-lang/rust-clippy/issues/13378)
- give more orderly help messages
- stop linting on `Mutex<*const T>` (see the corresponding commit for
context)
- offer (partial) suggestions
The last change might be deemed a bit too much for the feature freeze,
but it can be easily extracted out into a separate PR.
changelog: [`mutex_atomic`]: only lint the definitions, not uses
changelog: [`mutex_atomic`]: better help messages, and suggestions
changelog: [`mutex_atomic`]: don't lint `Mutex<*const T>`
changelog: [`mutex_integer`]: only lint the definitions, not uses
changelog: [`mutex_integer`]: better help messages, and suggestions
Based on
https://github.com/rust-lang/rust-clippy/pull/15520#discussion_r2372599748,
with the following changes/additions:
- No longer use the `Trait` enum for quickly filtering out irrelevant
impls -- instead, check the `trait_of` basically right away:
1. pre-fetch `DefId`s of the relevant traits into the lint pass
2. reuse `cx.tcx.impl_trait_ref`'s output for the the `DefId` of the
trait being implemented
3. compare those `DefId`s, which should be very cheap
- Next, check whether `self_ty` implements the other relevant trait.
- Pre-filter impl items in the same (lazy) iterator, but delay the
proc-macro check as much as possible
changelog: none
Not auto-assigning since @blyxyas and/or @Jarcho will be the ones
reviewing it:
r? ghost
Resolvesrust-lang/rust-clippy#15780.
I didn't get any feedback on that issue. So I hope it is okay that I
charged ahead and addressed it.
changelog: Allow `explicit_write` in tests
improve coverage
Considering comments above attributes for items
Fixed the ICE and safety comments between attributes
- No longer using attr.span()
- ignoring attributes manually
Improve error messages on unsafe fns
Add a config option `inherent-impl-lint-scope` to the lint
`multiple_inherent_impl` to target a different scope according to
people's needs. It can take three values: `module`, `file`, and `crate`
(default).
- `module` is the weakest option. It lints if there are two or more
impls in the same module.
- `file` is a bit stronger, since it lints if there are two or more
impls in the same file. So, this triggers the lint (where it did not
with module):
- `crate` is the strongest of them; it triggers as soon as there are two
or more impls anywhere in the crate. It is the current behaviour of the
lint, so it's the default option.
changelog: [`multiple_inherent_impl`] : Add config option (`module`,
`file` or `crate`) to target specific scope
fixesrust-lang/rust-clippy#14867
`Mutex<*const _>` doesn't make a lot of sense (there can be no
contention over a read-only reference), but `AtomicPtr::new(*const _)`
straight up doesn't compile
- The main message should point out what's wrong, not directly suggest a
solution.
- The second part of the message is a separate advice, so it should be
emitted separately.
