add help text where missing to lints
Fixes https://github.com/rust-lang/rust-clippy/issues/11805
Essentially just changes the section of code that applies the lint from using `cx.struct_span_lint` and instead opts for `span_lint_and_then`, which automatically appends the help text.
changelog: add missing help text for `cast_possible_wrap`, `mod_module_files`, and `self_named_module_files` lints
CC #3770
From https://github.com/rust-lang/rust-clippy/issues/3770#issuecomment-687565594 (@flip1995):
> Oh I thought I replied to this: I definitely see now that having this
> as a correctness lint might be the wrong categorization. What we might
> want to do is to just allow this lint, if there are comments in the
> arm bodies. But a good first step would be to downgrade this lint to
> style or complexity. I would vote for style since merging two arms is
> not always less complex.
Rollup of 5 pull requests
Successful merges:
- #116244 (Apply structured suggestion that allows test to work since 1.64)
- #117686 (Build pre-coroutine-transform coroutine body on error)
- #117834 (target_feature: make it more clear what that 'Option' means)
- #117893 (Suggest dereferencing the LHS for binops such as `&T == T`)
- #117911 (Fix some typos)
r? `@ghost`
`@rustbot` modify labels: rollup
target_feature: make it more clear what that 'Option' means
Reading those tables in compiler/rustc_codegen_ssa/src/target_features.rs, it's not immediately clear that `None` means "stable". Let's use an enum with appropriately named variants to make that more obvious.
Build pre-coroutine-transform coroutine body on error
I was accidentally building the post-transform coroutine body, rather than the pre-transform coroutine body. There's no pinning expected here yet, and the return type isn't yet transformed into `CoroutineState`.
Fixes#117670
make `LayoutError::Cycle` carry `ErrorGuaranteed`
Addresses a FIXME, and also I think it's wise for error variants to carry their `ErrorGuaranteed` -- makes it easier to use that `ErrorGuaranteed` for creating, e.g. `TyKind::Error` and other error kinds. Splitting out from #117703.
Implement new lint `iter_over_hash_type`
Implements and fixes https://github.com/rust-lang/rust-clippy/issues/11788
This PR adds a new *restriction* lint `iter_over_hash_type` which prevents `Hash`-types (that is, `HashSet` and `HashMap`) from being used as the iterator in `for` loops.
The justification for this is because in `Hash`-based types, the ordering of items is not guaranteed and may vary between executions of the same program on the same hardware. In addition, it reduces readability due to the unclear iteration order.
The implementation of this lint also ensures the following:
- Calls to `HashMap::keys`, `HashMap::values`, and `HashSet::iter` are also denied when used in `for` loops,
- When this expression is used in procedural macros, it is not linted/denied.
changelog: add new `iter_over_hash_type` lint to prevent unordered iterations through hashed data structures
fix: [manual_memcpy] reduce indexing suggestions when array length is equal to loop range
fixes: #11689
This PR improves `manual_memcpy` suggestions by reducing unnecessary indexing.
For example,
```rust
let src = [0, 1, 2, 3, 4];
let mut dest = [0; 4];
for i in 0..4 {
dest[i] = src[i];
{
```
Clippy suggests `dest[..4].copy_from_slice(&src[..4]);`.
I reduced this suggestion as `dest.copy_from_slice(&src[..4]);`. (Removed needless indexing.)
changelog: [`manual_memcpy`]: Reduce indexing suggestions when array length is equal to loop range
Add CoroutineWitness to covered types in smir
Previously we accepted `CouroutineWitness` as `unreachable!` but https://github.com/rust-lang/project-stable-mir/issues/50 shows it is indeed reachable, this pr fixes that and covers `CouroutineWitness`
Custom MIR: Support cleanup blocks
Cleanup blocks are declared with `bb (cleanup) = { ... }`.
`Call` and `Drop` terminators take an additional argument describing the unwind action, which is one of the following:
* `UnwindContinue()`
* `UnwindUnreachable()`
* `UnwindTerminate(reason)`, where reason is `ReasonAbi` or `ReasonInCleanup`
* `UnwindCleanup(block)`
Also support unwind resume and unwind terminate terminators:
* `UnwindResume()`
* `UnwindTerminate(reason)`
Cleanup blocks are declared with `bb (cleanup) = { ... }`.
`Call` and `Drop` terminators take an additional argument describing the
unwind action, which is one of the following:
* `UnwindContinue()`
* `UnwindUnreachable()`
* `UnwindTerminate(reason)`, where reason is `ReasonAbi` or `ReasonInCleanup`
* `UnwindCleanup(block)`
Also support unwind resume and unwind terminate terminators:
* `UnwindResume()`
* `UnwindTerminate(reason)`
