Check expr usage for `manual_flatten`
Fixes#6784Fixes#7538
`manual_flatten` should not trigger when `if let` match expression will be used.
changelog: [`manual_flatten`] checks for expr usage after `if let`
Manual map 7413
fixes: #7413
This only fixes the specific problem from #7413, not the general case. The full fix requires interacting with the borrow checker to determine the lifetime of all the borrows made in the function. I'll open an issue about it later.
changelog: Don't suggest using `map` when the option is borrowed in the match, and also consumed in the arm.
changelog: Locals declared within the would-be closure will not prevent the closure from being suggested in `manual_map` and `map_entry`
lintcheck always copies in a fresh crate when provided with a crate path
changelog: none
When lintcheck is run on local crates it copies the crate to `target/lintcheck/sources/crate_name` on the first run only.
Then in subsequent runs of lintcheck it reuses this same copy.
This caching behaviour makes sense when dealing with immutable crates.io releases and git commits.
However it is quite surprising that the changes to my local crate are not used when I run lintcheck.
To fix this I removed the copy, instead clippy runs directly off the provided crate folder.
I have tested this and have not observed any negative effects from doing this.
But maybe i'm missing something as im not familiar with clippy!
Alternatively we could make it copy the entire crate every run, but that seems problematic to me as multi-gigabyte target folders will take a long time to copy and wear down SSDs for developers who frequently run lintcheck.
Downgrade option_if_let_else to nursery
I believe that this lint's loose understanding of ownership (#5822, #6737) makes it unsuitable to be enabled by default in its current state, even as a pedantic lint.
Additionally the lint has known problems with type inference (#6137), though I may be willing to consider this a non-blocker in isolation if it weren't for the ownership false positives.
A fourth false positive involving const fn: #7567.
But on top of these, for me the biggest issue is I basically fully agree with https://github.com/rust-lang/rust-clippy/issues/6137#issuecomment-705605688. In my experience this lint universally makes code worse even when the resulting code does compile.
---
changelog: remove [`option_if_let_else`] from default set of enabled lints
* Captures by sub closures are now considered
* Copy types are correctly borrowed by reference when their value is used
* Fields are no longer automatically borrowed by value
* Bindings in `match` and `let` patterns are now checked to determine how a local is captured
Use `avoid-breaking-exported-api` configuration in types module
This PR empowers our lovely `avoid-breaking-exported-api` configuration value to also influence the emission of lints inside the `types` module.
(That's pretty much it, not really a change worthy of writing a fairy tale about. Don't get me wrong, I would love to write a short one, but I sadly need to study now).
---
Closes: rust-lang/rust-clippy#7489
changelog: The `avoid-breaking-exported-api` configuration now also works for [`box_vec`], [`redundant_allocation`], [`rc_buffer`], [`vec_box`], [`option_option`], [`linkedlist`], [`rc_mutex`]
changelog: [`rc_mutex`]: update the lint message to comply with the normal format
---
r? `@camsteffen,` as you implemented the configuration value
cc: `@flip1995,` as we've discussed this change in rust-lang/rust-clippy#7308
Add `unwrap_or_else_default` lint
---
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: Add a new [`unwrap_or_else_default`] style lint. This will catch `unwrap_or_else(Default::default)` on Result and Option and suggest `unwrap_or_default()` instead.
No effect inclusive range
I noticed during last PR that range expression is `ExprKind::Struct` while inclusive range is `ExprKind::Call` which was why it was not handled. This PR adds check for this case.
changelog: [`no_effect]` Report inclusive range in no_effect lint
`never_loop`: suggest using an `if let` instead of a `for` loop
changelog: suggest using an `if let` statement instead of a `for` loop that [`never_loop`]s
Fixes#7537, r? `@camsteffen.`
Clean up examples in new lint suggestion template
I'm pretty sure they meant to write `bounds checking` when they wrote `bounce checking` but I could be wrong. After that I thought I could improve it further and ended up with this.
changelog: none
Cleanup usage of `span_to_snippet` and `LintContext::sess`
- avoid using `SourceMap::span_to_snippet` directly and use `clippy_utils::source::snippet_opt` instead
- don't use `LintContext::sess()` on `EarlyContext`s which have a `sess` field directly available, saving the import of `LintContext`
changelog: none
Don't emit `too_many_lines` for closures
changelog: don't emit the [`too_many_lines`] lint inside closures to avoir duplicated diagnostics.
Fixes#7517.
