[`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 ^^
redundant_type_annotations: only pass certain def kinds to type_of
Fixes#11190Fixesrust-lang/rust#113516
Also adds an `is_lint_allowed` check to skip the lint when it's not needed
changelog: none
New lints: `impossible_comparisons` and `redundant_comparisons`
Inspired by a bug we had in production, like all good lints ;)
Adds two lints for "double" comparisons, specifically when the same expression is being compared against two different constants.
`impossible_comparisons` checks for expressions that can never be true at all. Example:
```rust
status_code <= 400 && status_code > 500
```
Presumably, the programmer intended to write `status_code >= 400 && status_code < 500` in this case.
`redundant_comparisons` checks for expressions where either half has no effect. Example:
```rust
status_code <= 400 && status_code < 500
```
Works with other literal types like floats and strings, and *some* cases where the constant is more complex than a literal, see the tests for more.
**Limitations and/or future work:**
* Doesn't work if the LHS can have side-effects at all, for example by being a function call
* Only works for exactly two comparison expressions, so `x > y && x > z && x < w` won't get checked
* Doesn't check for comparison expressions combined with `||`. Very similar logic could be applied there.
changelog: New lints [`impossible_comparisons`] and [`redundant_comparisons`]
Fix `suspicious_xor_used_as_pow.rs` performance
The original `suspicious_xor_used_as_pow` lint had poor performance, so I fixed that + a little refactor so that module is readable.
**107 millis. -> 106 millis.** Using `SPEEDTEST` on Rust's VMs
fix#11060
changelog: [`suspicious_xor_used_as_pow`]: Improve performance by 0.934%
New lint `ignored_unit_patterns`
This idea comes from #11238. I've put the lint in `pedantic` as it might trigger numerous positives (three in Clippy itself).
changelog: [`ignored_unit_patterns`]: new lint
Suppress `question_mark` warning if `question_mark_used` is not allowed
Closes#11283
changelog: [`question_mark`]: Don't lint if `question_mark_used` is not allowed
[`unwrap_used`]: Do not lint unwrapping on `!` or never-like enums
Fixes#11245
changelog: [`unwrap_used`]: Do not lint unwrapping on `!` or never-like enums
changelog: [`expect_used`]: Do not lint unwrapping on `!` or never-like enums
`redundant_closure` fixes
fixes#8548
A good chunk of the code is fixing false negatives. The old code banned any non late-bound regions from appearing in the callee's signature. The new version checks when the late-bound region is actually required.
changelog: Better track when a early-bound region appears when a late-bound region is required in `redundant_closure`.
changelog: Don't lint `redundant_closure` when the closure gives explicit types.
