[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
Fix SPEEDTEST instructions and output
* `--nocapture` hasn't been needed anymore since forever (even before `ui_test`)
* the result was dividing by 1000 instead of the number of test runs, giving bogus (but still useful for the purpose) timing results.
changelog: fix SPEEDTEST instructions and output
Update ui test crate
This update also removes the `//`@run-rustfix`` flag, and just runs rustfix on all tests. This means I had to opt out of running rustfix on ~100 tests, but it also allowed me to remove the rustfix coverage check entirely, as it is now effectively builtin.
changelog: update ui-test crate to 0.13 (automatically runs rustfix on all tests)
redundant_locals: fix FPs on mutated shadows
Fixes#11290.
When a mutable binding is shadowed by
a mutable binding of the same name in a different scope, mutations in that scope have different meaning.
This PR fixes spurious `redundant_locals` emissions on such locals.
cc `@Centri3,` `@flip1995`
changelog: [`redundant_locals`]: fix false positives on mutated shadows
Rustup
r? `@ghost`
cc `@max-niederman` With the latest sync, I'm getting a lot of FP in the `redundant_locals` lint you recently added. Any ideas where this could come from?
changelog: none
When a mutable binding is shadowed by
a mutable binding of the same name in a different scope,
mutations in that scope have different meaning.
This commit fixes spurious `redundant_locals` emissions
on such locals.
[`filter_map_bool_then`]: Don't ICE on late bound regions
Fixes#11309
Also lints `&NonCopy` now, since any `&` is `Copy`. That was accidental, but it seems that this is a consequence (or improvement!) of this fix.
r? `@Jarcho`
changelog: [`filter_map_bool_then`]: Don't ICE on late bound regions
[`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse
#11198 extended this lint to also warn on `Vec::new()` + `resize(0, len)`, but did not update the lint documentation, so it left some confused (https://github.com/rust-lang/rust-clippy/issues/10938#issuecomment-1663880083).
This PR should make it a bit more clear. (cc `@djc` `@vi` what do you think about this?)
<details>
<summary>More details</summary>
Godbolt for `Vec::new()` + `.resize(x, 0)`: https://godbolt.org/z/e7q9xc9rG
The resize call first does a normal allocation (`__rust_alloc`):
```asm
alloc::raw_vec::finish_grow:
...
cmp qword ptr [rcx + 8], 0
je .LBB1_7 ; if capacity == 0 -> LBB1_7
.LBB1_7:
...
call qword ptr [rip + __rust_alloc@GOTPCREL]
```
*Then* a memset for zero initialization:
```asm
example::f:
...
xor esi, esi ; 0
call qword ptr [rip + memset@GOTPCREL]
```
------------
Godbolt for `vec![0; len]`: https://godbolt.org/z/M3vr53vWY
Important bit:
```asm
example::f:
...
call qword ptr [rip + __rust_alloc_zeroed@GOTPCREL]
```
</details>
changelog: [`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse than `vec![0; len]`
[`redundant_guards`]: don't lint on float literals
Fixes#11304
changelog: [`redundant_guards`]: don't lint on float literals
r? `@Centri3` i figured you are probably a good reviewer for this since you implemented the lint ^^
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes#114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
