Add test for `try_err` lint within try blocks.
Fixes#5757
Turns out the current `try_err` implementation already skips expressions inside of a try block.
When inside of a try block, `Err(_)?` is desugared to a `break` instead of normal `return` . This makes `find_return_type()` function at [this line](eb4d88e690/clippy_lints/src/matches/try_err.rs (L29)) always returns `None` and skips the check.
I just added a test case for try block.
changelog: none
Fix [`redundant_slicing`] when the slice is behind a mutable reference
Fixes#12751
changelog: Fix [`redundant_slicing`] when the slice is behind a mutable reference and a immutable reference is expected.
Fix `redundant_closure` false positive with closures has return type contains `'static`
Fix#13073 .
Please enable "ignore white-space change" settings in github UI for easy reviewing.
HACK: The third commit contains a hack to check if a type `T: 'static` when `fn() -> U where U: 'static`.
I don't have a clean way to check for it.
changelog: [`redundant_closure`] Fix false positive with closures has return type contains `'static`
Fix false positive for `missing_backticks` in footnote references
Fixes#13183.
changelog: Fix false positive for `missing_backticks` in footnote references
Add possibility to focus on search input using keyboard
This PR adds the possibility to focus on the search input with `S` or `/` like in rustdoc and `mdbook` and `docs.rs` (unification++). Pressing escape will blur it.
r? `@Alexendoo`
changelog: Add possibility to focus on search input using keyboard
Emit `if_let_mutex` in presence of other mutexes
Currently (master, not nightly nor stable) `if_let_mutex` does not emit a warning here:
```rs
let m1 = Mutex::new(10);
let m2 = Mutex::new(());
if let 100..=200 = *m1.lock().unwrap() {
m2.lock();
} else {
m1.lock();
}
```
It currently looks for the first call to `.lock()` on *any* mutex receiver inside of the if/else body, and only later (outside of the visitor) checks that the receiver matches the mutex in the scrutinee. That means that in cases like the above, it finds the `m2.lock()` expression, stops the visitor, fails the check that it's the same mutex (`m2` != `m1`) and then does not look for any other `.lock()` calls.
So, just make the receiver check also part of the visitor so that we only stop the visitor when we also find the right receiver.
The first commit has the actual changes described here. The sceond one just unnests all the `if let`s
----
changelog: none
Clean up clippy lints page JS source code
Just a small cleanup for the lints page JS source code.
r? `@Alexendoo`
changelog: Clean up clippy lints page JS source code
Misc changes to `clippy_config`
Contains part of #13084
Changes include:
* Sort config list and each configs lint list.
* Add default text for the two configs that were missing it.
* Switch the lint list in the configs to an attribute.
* Make `dev fmt` sort the config list.
r? `@xFrednet`
changelog: none
Fix fix under loop may dropping loop label when applying fix.
changelog: [`explicit_counter_loop`]: fix label drop
changelog: [`for_kv_map`]: add label drop test
`missing_trait_methods`: lint methods in definition order
Lintcheck for #13157 showed a bunch of changes for `missing_trait_methods`
This is because `values_sorted` was sorting the entries by the key's [`DefPathHash`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/def_id/struct.DefPathHash.html), this is stable for a given compiler but can change across versions
changelog: none
Fix while_let_on_iterator dropping loop label when applying fix.
Loop label was not persisted when displaying help and was therefore producing broken rust code when applying fixes.
Solution was to store the `ast::Label` when creating a `higher::WhileLet` from an expression and add the label name to the lint suggestion and diagnostics.
---
Fixes: https://github.com/rust-lang/rust-clippy/issues/13123
changelog: [`while_let_on_iterator`]: Fix issue dropping loop label when displaying help and applying fixes.
Add `BTreeSet` detection to the `set_contains_or_insert` lint
* Detect `BTreeSet::contains` + `BTreeSet::insert` usage in the same way as with the `HashSet`.
CC: `@lochetti` `@bitfield`
----
changelog: [`set_contains_or_insert`]: Handle `BTreeSet` in addition to `HashSet`
Make `std_instead_of_core` somewhat MSRV aware
For #13158, this catches some things e.g. `core::net` and the recently stable `core::error` but not things moved individually like `UnwindSafe`, as far as I can see the version for those isn't easily available
Beta nominating since ideally we'd get this change in the same version as `core::error` becomes stable
cc `@kpreid`
changelog: none
Avoid ref when using format!
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing).
Inlining format args prevents accidental `&` misuse.
See also https://github.com/rust-lang/rust/issues/112156
changelog: none
Fix handling of `Deref` in `assigning_clones`
The `assigning_clones` lint had a special case for producing a bit nicer code for mutable references:
```rust
fn clone_function_lhs_mut_ref(mut_thing: &mut HasCloneFrom, ref_thing: &HasCloneFrom) {
*mut_thing = Clone::clone(ref_thing);
}
//v
fn clone_function_lhs_mut_ref(mut_thing: &mut HasCloneFrom, ref_thing: &HasCloneFrom) {
Clone::clone_from(mut_thing, ref_thing);
}
```
However, this could [break](https://github.com/rust-lang/rust-clippy/issues/12437) when combined with `Deref`.
This PR removes the special case, so that the generated code should work more generally. Later we can improve the detection of `Deref` and put the special case back in a way that does not break code.
Fixes: https://github.com/rust-lang/rust-clippy/issues/12437
r? `@blyxyas`
changelog: [`assigning_clones`]: change applicability to `Unspecified` and fix a problem with `Deref`.
needless_borrows_for_generic_args: Fix for &mut
This commit fixes a bug introduced in #12706, where the behavior of the lint has been changed, to avoid suggestions that introduce a move. The motivation in the commit message is quite poor (if the detection for significant drops is not sufficient because it's not transitive, the proper fix would be to make it transitive). However, #12454, the linked issue, provides a good reason for the change — if the value being borrowed is bound to a variable, then moving it will only introduce friction into future refactorings.
Thus #12706 changes the logic so that the lint triggers if the value being borrowed is Copy, or is the result of a function call, simplifying the logic to the point where analysing "is this the only use of this value" isn't necessary.
However, said PR also introduces an undocumented carveout, where referents that themselves are mutable references are treated as Copy, to catch some cases that we do want to lint against. However, that is not sound — it's possible to consume a mutable reference by moving it.
To avoid emitting false suggestions, this PR reintroduces the referent_used_exactly_once logic and runs that check for referents that are themselves mutable references.
Thinking about the code shape of &mut x, where x: &mut T, raises the point that while removing the &mut outright won't work, the extra indirection is still undesirable, and perhaps instead we should suggest reborrowing: &mut *x. That, however, is left as possible future work.
Fixes#12856
changelog: none
Remove unnecessary `res` field in `for_each_expr` visitors
Small refactor in the `for_each_expr*` visitors. This should not change anything functionally.
Instead of storing the final value `Option<B>` in the visitor and setting it to `Some` when we get a `ControlFlow::Break(B)` from the closure, we can just directly return it from the visitor itself now that visitors support that.
cc #12829 and https://github.com/rust-lang/rust-clippy/pull/12830#discussion_r1627882827
changelog: none
