Correctly handle async blocks for NEEDLESS_PASS_BY_REF_MUT
Fixes https://github.com/rust-lang/rust-clippy/issues/11299.
The problem was that the `async block`s are popping a closure which we didn't go into, making it miss the mutable access to the variables.
cc `@Centri3`
changelog: none
[`useless_conversion`]: only lint on paths to fn items and fix FP in macro
Fixes#11065 (which is actually two issues: an ICE and a false positive)
It now makes sure that the function call path points to a function-like item (and not e.g. a `const` like in the linked issue), so that calling `TyCtxt::fn_sig` later in the lint does not ICE (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616836099).
It *also* makes sure that the expression is not part of a macro call (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616919639). ~~I'm not sure if there's a better way to check this other than to walk the parent expr chain and see if any of them are expansions.~~ (edit: it doesn't do this anymore)
changelog: [`useless_conversion`]: fix ICE when call receiver is a non-fn item
changelog: [`useless_conversion`]: don't lint if argument is a macro argument (fixes a FP)
r? `@llogiq` (reviewed #10814, which introduced these issues)
Correctly handle async blocks for NEEDLESS_PASS_BY_REF_MUT
Fixes https://github.com/rust-lang/rust-clippy/issues/11299.
The problem was that the `async block`s are popping a closure which we didn't go into, making it miss the mutable access to the variables.
cc `@Centri3`
changelog: none
[`useless_conversion`]: only lint on paths to fn items and fix FP in macro
Fixes#11065 (which is actually two issues: an ICE and a false positive)
It now makes sure that the function call path points to a function-like item (and not e.g. a `const` like in the linked issue), so that calling `TyCtxt::fn_sig` later in the lint does not ICE (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616836099).
It *also* makes sure that the expression is not part of a macro call (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616919639). ~~I'm not sure if there's a better way to check this other than to walk the parent expr chain and see if any of them are expansions.~~ (edit: it doesn't do this anymore)
changelog: [`useless_conversion`]: fix ICE when call receiver is a non-fn item
changelog: [`useless_conversion`]: don't lint if argument is a macro argument (fixes a FP)
r? `@llogiq` (reviewed #10814, which introduced these issues)
Clippy Book Chapter Updates Reborn: Method Checking
This PR adds a new chapter to the book: "Method Checking". Some major re-phrasing was done and some changes in the code comments (apart from grammar and minor changes).
## Notes
- Requires #10595 **and** #10622 to be merged before this, or else several links will be broken
- To talk about the whole project, please use the tracking issue for the project #10597 (It also contains a timeline, discussions and more information)
changelog: Add a new "Method Checking" chapter to the book.
r? `@flip1995`
Clippy Book Chapter Updates Reborn: Defining Lints
Revival of #9659, I've made a few changes (mainly ones from reviews from #9426, like removing mid-section storytelling) and some re-writes. The goal of the project would be to slowly re-write the Clippy book (only chapters that need it) to more up-to-date style.
## Notes
- Things like `git status` commands have changed, we need to make sure that they're correct.
- As this is a team-wide effort, I would please ask anyone and everyone to read it and give your opinion.
- To talk about the whole project, please use the tracking issue for the project #10597 (It also contains a timeline, discussions and more information)
---
changelog: Add a new "Defining lints" chapter to the book
r? `@flip1995`
Point at return type when it influences non-first `match` arm
When encountering code like
```rust
fn foo() -> i32 {
match 0 {
1 => return 0,
2 => "",
_ => 1,
}
}
```
Point at the return type and not at the prior arm, as that arm has type `!` which isn't influencing the arm corresponding to arm `2`.
Fix#78124.
Use ui_test's Windows path backslash heuristic
changelog: none
Instead of unconditionally replacing `\` with `/` we now use [`Match::PathBackslash`](https://docs.rs/ui_test/latest/ui_test/enum.Match.html#variant.PathBackslash) to only replace backslashes in paths that look like windows paths
`ui-toml` and `ui-cargo` tests still use the old way because they produce verbatim paths on windows in some tests (`\\?\C:\foo\...`) which was finnicky to get the replacement order correct with
Also removes the `ui_test` -> `compiletest` alias and `VarGuard`
allow calling `to_owned` on borrowed value for [`implicit_clone`]
fixes: #11281
a small and simple fix that give up checking for `referenced_value.to_owned()` usage.
changelog: allow calling `to_owned` with borrowed value for [`implicit_clone`]
[iter_overeager_cloned]: detect `.cloned().filter()` and `.cloned().find()`
changelog: [`iter_overeager_cloned`]: detect `.cloned().filter()` and `.cloned().find()`
Key idea:
```
// before
iter.cloned().filter(|x| unimplemented!() )
// after
iter.filter(|&x| unimplemented!() ).cloned()
// before
iter.cloned().filter( foo )
// after
// notice `iter` must be `Iterator<Item= &T>` (callee of `cloned()`)
// so the parameter in the closure of `filter` must be `&&T`
// so the deref is safe
iter.filter(|&x| foo(x) ).cloned()
```
Do not bless by default in ui tests
This restores the default behaviour to check the `.stderr`, it was changed in #11239 to bless by default in `cargo test` (unless in github actions), but check by default in `cargo uitest` which is fairly confusing
It also meant `cargo uitest -F internal` no longer worked
`--bless` prevents the use of `Args::test` but we can look at reintegrating with that after `@oli-obk's` vacation
r? `@flip1995`
changelog: none
