Correct doc comments inside `use_expr_visitor.rs`
Just a simple update. I haven't changed any content inside the comments, as they still seem correct. Have a wonderful rest of the day 🙃
Introduce `let...else`
Tracking issue: #87335
The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..`, but I decided against this because, when a "mismatched type" error is found in typeck, there is no way to trace where in the HIR the expected type originated, AFAICT. In order to pass down this information, I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType`, but I left that as a future enhancement. For now, I simply assert that the block is `!` with a custom `ObligationCauseCode`, and I think this is clear enough, at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect.
Overall, I believe this PR is feature-complete with regard to the RFC.
Warn when [T; N].into_iter() is ambiguous in the new edition.
Fixes https://github.com/rust-lang/rust/issues/88475
In https://github.com/rust-lang/rust/issues/88475, a situation was found where `[T; N].into_iter()` becomes *ambiguous* in the new edition. This is different than the case where `(&[T; N]).into_iter()` resolves differently, which was the only case handled by the `array_into_iter` lint. This is almost identical to the new-traits-in-the-prelude problem. Effectively, due to the array-into-iter hack disappearing in Rust 2021, we effectively added `IntoIterator` to the 'prelude' in Rust 2021 specifically for arrays.
This modifies the prelude collisions lint to detect that case and emit a `array_into_iter` lint in that case.
Don't use `guess_head_span` in `predicates_of` for foreign span
Previously, the result of `predicates_of` for a foreign trait
would depend on the *current* state of the corresponding source
file in the foreign crate. This could lead to ICEs during incremental
compilation, since the on-disk contents of the upstream source file
could potentially change without the upstream crate being recompiled.
Additionally, this ensure that that the metadata we produce for a crate
only depends on its *compiled* upstream dependencies (e.g an rlib or
rmeta file), *not* the current on-disk state of the upstream crate
source files.
update const generics feature gates
**tl;dr: split const generics into three features: `adt_const_params`, `const_generics_defaults` and `generic_const_exprs`**
continuing the work of `@BoxyUwU` in #88324, this PR
- renames `feature(const_evaluatable_checked)` to `feature(generic_const_exprs)` which now doesn't need any other feature gate to work. Previously `feature(const_evaluatable_checked)` was only useful in combination with `feature(const_generics)`.
- completely removes `feature(lazy_normalization_consts)`. This feature only supplied the parents generics to anonymous constants, which is pretty useless as generic anon consts are only allowed with `feature(generic_const_exprs)` anyways.
- moves the ability to use additional const param types from `feature(const_generics)` into `feature(adt_const_params)`. As `feature(const_generics)` is now mostly useless without `feature(generic_const_exprs)` we also remove that feature flag.
- updates tests, removing duplicates and unnecessary revisions in some cases and also deletes all unused `*.stderr` files.
I not also remove the ordering restriction for const and type parameters if any of the three const generics features is active.
This ordering restriction feels like the only "real" use of the current `feature(const_generics)` right now so this change isn't a perfect solution, but as I intend to stabilize the ordering - and `feature(const_generics_defaults)` - in the very near future, I think this is acceptable for now.
---
cc `@rust-lang/project-const-generics` about the new feature names and this change in general.
I don't think we need any external approval for this change but I do intend to publish an update to the const generics tracking issue the day this PR lands, so I don't want this merged yet.
Apologies to whoever ends up reviewing this PR 😅❤️
r? rust-lang/project-const-generics
Handle match statements with non exhaustive variants in closures
This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.
If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.
Closes https://github.com/rust-lang/project-rfc-2229/issues/59
r? `@nikomatsakis`
