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.
Document `std::env::current_exe` possible rename behaviour
It might not be obvious that the "path of the current running executable" may (or may not) imply "at the time it was loaded".
This came up recently in chat so I thought it might be worth documenting.
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
Update unstable docs for `asm!` macro
This adds documentation that SPIR-V is supported, expands on the restrictions for labels, and has some minor cleanups or clarifications.
r? `@joshtriplett`
Fix: don't document private macros by default
As part of #88019, I made it so private macros are documented in `--document-private-items` mode. Unfortunately, it appears that I also accidentally made them be documented when *not* in `--document-private-items` mode. This PR fixes that and adds a regression test.
r? `@jyn514` (I hope you don't mind that I keep sending PRs your way)
Fixes#88453.
rustc_target: `TyAndLayout::field` should never error.
This refactor (making `TyAndLayout::field` return `TyAndLayout` without any `Result` around it) is based on a simple observation, regarding `TyAndLayout::field`:
If `cx.layout_of(ty)` succeeds (for some `cx` and `ty`), then `.field(cx, i)` on the resulting `TyAndLayout` should *always* succeed in computing `cx.layout_of(field_ty)` (where `field_ty` is the type of the `i`th field of `ty`).
The reason for this is that no matter which field is chosen, `cx.layout_of(field_ty)` *will have already been computed*, as part of computing `cx.layout_of(ty)`, as we cannot determine the layout of *any* type without considering the layouts of *all* of its fields.
And so it should be fine to turn any errors into ICEs, since they likely indicate a `cx` mismatch, or some other edge case that is due to a compiler bug (as opposed to ever being an user-facing error).
<hr/>
Each commit should probably be reviewed separately, though note that there's some `where` clauses (in `rustc_target::abi::call::*`) that change in most commits.
cc `@nagisa` `@oli-obk`
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`
