disallow calls to `LintContext::struct_span_lint` and `TyCtxt::struct_span_lint_hir`
`LintContext::struct_span_lint` and `TyCtxt::struct_span_lint_hir` don't show the link to the clippy documentation, see: #11805
In #11810, the last few calls to those methods were replaced with `span_lint_*`. It seems like we should just disallow them altogether so that no new code tries to use them.
The existing `disallowed_methods` lint makes this easy.
changelog: none
Add richer structure for Stable MIR Projections
Resolves https://github.com/rust-lang/project-stable-mir/issues/49.
Projections in Stable MIR are currently just strings. This PR replaces that representation with a richer structure, namely projections become vectors of `ProjectionElem`s, just as in MIR. The `ProjectionElem` enum is heavily based off of the MIR `ProjectionElem`.
This PR is a draft since there are several outstanding issues to resolve, including:
- How should `UserTypeProjection`s be represented in Stable MIR? In MIR, the projections are just a vector of `ProjectionElem<(),()>`, meaning `ProjectionElem`s that don't have Local or Type arguments (for `Index`, `Field`, etc. objects). Should `UserTypeProjection`s be represented this way in Stable MIR as well? Or is there a more user-friendly representation that wouldn't drag along all the `ProjectionElem` variants that presumably can't appear?
- What is the expected behavior of a `Place`'s `ty` function? Should it resolve down the chain of projections so that something like `*_1.f` would return the type referenced by field `f`?
- Tests should be added for `UserTypeProjection`
[`impl_trait_in_params`]: avoid ICE when function with `impl Trait` type has no parameters
Fixes#11803
If I'm reading the old code correctly, it was taking the span of the first parameter (without checking that it exists, which caused the ICE) and uses that to figure out where the generic parameter to insert should go (cc `@blyxyas` you wrote the lint, is that correct?).
This seemed equivalent to just `generics.span`, which doesn't require calculating the spans like that and simplifies it a fair bit
changelog: don't ICE when function has no parameters but generics have an `impl Trait` type
Also shifts comments explaining why Stable MIR drops an optional variant
name field, for `Downcast` projection elements, to the `Place::stable`
function.
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
