Ensure stack in two places that affect s390x
In our Fedora s390x test results, we found two tests that started hitting stack
overflows in the 1.87.0 update. It seems to be related in some part to our use
of PGO as well, probably inlining more into stack frames that were already
recursive. The main points of recursion that I identified were:
- `ui/parser/survive-peano-lesson-queue.rs` in `ThirBuildCx::mirror_exprs`
- `ui/associated-consts/issue-93775.rs` in `Parser::parse_ty`
A couple new `ensure_sufficient_stack` calls will solve these tests.
This solve a stack overflow found on Fedora s390x when building
`tests/ui/parser/survive-peano-lesson-queue.rs`. Note that the singular
`mirror_expr` method already has this stack check, but in this case the
plural method was the one recursing too deeply.
`UsePath` contains a `SmallVec<[Res; 3]>`. This holds up to three `Res`
results, one per namespace (type, value, or macro). `lower_import_res`
takes a `PerNS<Option<Res<NodeId>>>` result and lowers it into the
`SmallVec`. This is pretty weird. The input `PerNS` makes it clear which
`Res` belongs to which namespace, but the `SmallVec` throws that
information away.
And code that operates on the `SmallVec` tends to use iteration (or even
just grabbing the first entry!) without knowing which namespace the
`Res` belongs to. Even weirder! Also, `SmallVec` is an overly flexible
type to use here, because it can contain any number of elements (even
though it's optimized for 3 in this case).
This commit changes `UsePath` so it also contains a
`PerNS<Option<Res<HirId>>>`. This type preserves more information and is
more self-documenting. The commit also changes a lot of the use sites to
access the result for a particular namespace. E.g. if you're looking up
a trait, it will be in the `Res` for the type namespace if it's present;
it's silly to look in the `Res` for the value namespace or macro
namespace. Overall I find the new code much easier to understand.
However, some use sites still iterate. These now use `present_items`
because that filters out the `None` results.
Also, `redundant_pub_crate.rs` gets a bigger change. A
`UseKind:ListStem` item gets no `Res` results, which means the old `all`
call in `is_not_macro_export` would succeed (because `all` succeeds on
an empty iterator) and the `ListStem` would be ignored. This is what we
want, but was more by luck than design. The new code detects `ListStem`
explicitly. The commit generalizes the name of that function
accordingly.
Finally, the commit also removes the `use_path` arena, because
`PerNS<Option<Res>>` impls `Copy` (unlike `SmallVec`) and it can be
allocated in the arena shared by all `Copy` types.
Specifically `TyAlias`, `Enum`, `Struct`, `Union`. So the fields match
the textual order in the source code.
The interesting part of the change is in
`compiler/rustc_hir/src/hir.rs`. The rest is extremely mechanical
refactoring.
This pattern of iterating over scopes and drops occurs multiple times in
this file, with slight variations. All of them use `for` loops except
this one. This commits changes it for consistency.
It's not needed, because `next` and `local` fields uniquely identify the
drop. This is a ~2% speed win on the very large program in #134404, and
it's also a tiny bit simpler.
interpret: add allocation parameters to `AllocBytes`
Necessary for a better implementation of [rust-lang/miri#4343](https://github.com/rust-lang/miri/pull/4343). Also included here is the code from that PR, adapted to this new interface for the sake of example and so that CI can run on them; the Miri changes can be reverted and merged separately, though.
r? `@RalfJung`
Properly analyze captures from unsafe binders
We need to represent the unsafe binder unwrap as an adjustment in HIR. Pretty straightforward b/c we already represent it as a projection elem in MIR.
Fixes#141418Fixes#141417
r? oli-obk
`unpretty=thir-tree`: don't require the final expr to be the body's value
Two motivations for this:
- I couldn't find a comment motivating this hard-coding. I can imagine it might be easier to read `unpretty=thir-flat` output if the final expression in the THIR is always the body's value, but if that's the reason, that should be the justification in the source. I can also imagine it's meant to check that all expressions will be visited by the pretty-printer, but the existing check doesn't quite do that either.
- Guard patterns (#129967) contain expressions, so lowering params containing guard patterns may add more expressions to the THIR. Currently a body's params are lowered after its expression, so guard expressions in params would end up last, breaking this. As an alternative, the params could be lowered first (#141356).
lower bodies' params to thir before the body's value
Two motivations for this:
- Lowering params first means errors from lowering the params are emitted before errors from lowering the body's expression. This comes up in [tests/ui/associated-consts/associated-const-type-parameter-pattern.stderr](https://github.com/rust-lang/rust/compare/master...dianne:rust:thir-lower-params-before-body-expr?expand=1#diff-acac6ea10e991af0da91633e08b2739f9f9ca0c8f826401b6ba829914d0806f2), where both the params and expression encounter errors in translating consts to patterns. This change puts the errors in the order they appear in the source file.
- Guard patterns (#129967) contain expressions, so lowering params containing guard patterns may add more expressions to the THIR. However, there's a check for `-Zunpretty=thir-tree` that the final expression in the THIR corresponds to its value [(link)](c43786c9b7/compiler/rustc_mir_build/src/builder/mod.rs (L453-L455)); lowering params last would break this. As an alternative way to get guard patterns to work, I think the pretty-printer could use the expression returned by `thir_body` and the check could be removed or changed (#141357).
This taints the typeck results with errors if a `continue` is found not
pointing to a loop, which fixes an ICE.
A few things were going wrong here. First, since this wasn't caught in
typeck, we'd end up building the THIR and then running liveness lints on
ill-formed HIR. Since liveness assumes all `continue`s point to loops,
it wasn't setting a live node for the `continue`'s destination. However,
the fallback for this was faulty; it would create a new live node to
represent the erroneous state after the analysis's RWU table had already
been built. This would ICE if the new live node was used in operations,
such as merging results from the arms of a match. I've removed this
error-recovery since it was buggy, and we should really catch bad labels
before liveness.
I've also replaced an outdated comment about when liveness lints are
run. At this point, I think the call to `check_liveness` could be moved
elsewhere, but if it can be run when the typeck results are tainted by
errors, it'll need some slight refactoring so it can bail out in that
case. In lieu of that, I've added an assertion.
Invoke a query only when it doesn't return immediately anyway
This should cause less query key caching and less dep graph data, hopefully resulting in some perf improvements
Stage0 bootstrap update
This PR [follows the release process](https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday) to update the stage0 compiler.
The only thing of note is 58651d1b31, which was flagged by clippy as a correctness fix. I think allowing that lint in our case makes sense, but it's worth to have a second pair of eyes on it.
r? `@Mark-Simulacrum`
Set groundwork for proper const normalization
r? lcnr
Updates a lot of our normalization/alias infrastructure to be setup to handle mgca aliases and normalization once const items are represented more like aliases than bodies. Inherent associated consts are still super busted, I didn't update the assertions that IACs the right arg setup because that winds up being somewhat involved to do *before* proper support for normalizing const aliases is implemented.
I dont *intend* for this to have any effect on stable. We continue normalizing via ctfe on stable and the codepaths in `project` for consts should only be reachable with mgca or ace.
allow deref patterns to move out of boxes
This adds a case to lower deref patterns on boxes using a built-in deref instead of a `Deref::deref` or `DerefMut::deref_mut` call: if `deref!(inner): Box<T>` is matching on place `place`, the inner pattern `inner` now matches on `*place` rather than a temporary. No longer needing to call a method also means it won't borrow the scrutinee in match arms. This allows for bindings in `inner` to move out of `*place`.
For comparison with box patterns, this uses the same MIR lowering but different THIR. Consequently, deref patterns on boxes are treated the same as any other deref patterns in match exhaustiveness analysis. Box patterns can't quite be implemented in terms of deref patterns until exhaustiveness checking for deref patterns is implemented (I'll open a PR for exhaustiveness soon!).
Tracking issue: #87121
r? ``@Nadrieril``
Make #![feature(let_chains)] bootstrap conditional in compiler/
Let chains have been stabilized recently in #132833, so we can remove the gating from our uses in the compiler (as the compiler uses edition 2024).
This allows deref patterns to move out of boxes.
Implementation-wise, I've opted to put the information of whether a
deref pattern uses a built-in deref or a method call in the THIR. It'd
be a bit less code to check `.is_box()` everywhere, but I think this way
feels more robust (and we don't have a `mutability` field in the THIR
that we ignore when the smart pointer's a box). I'm not sure about the
naming (or using `ByRef`), though.
`deref_patterns`: support string and byte string literals in explicit `deref!("...")` patterns
When `deref_patterns` is enabled, this allows string literal patterns to be used where `str` is expected and byte string literal patterns to be used where `[u8]` or `[u8; N]` is expected. This lets them be used in explicit `deref!("...")` patterns to match on `String`, `Box<str>`, `Vec<u8>`, `Box<[u8;N]>`, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on #138992: similar to how byte string literals matching on `&[u8]` is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call `<str as PartialEq>::eq` in the MIR lowering for string equality tests).
This PR does not add support for implicit deref pattern syntax (e.g. `"..."` matching on `String`, as `string_deref_patterns` allows). I have that implemented locally, but I'm saving it for a follow-up PR[^1].
This also does not add support for using named or associated constants of type `&str` where `str` is expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals.
This is gated by the `deref_patterns` feature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up[^1]. Even without deref patterns, I think there's probably motivation for these changes.
The update to the unstable book added by this will conflict with #140022, so they shouldn't be merged at the same time.
Tracking issue for deref patterns: #87121
r? ``@oli-obk``
cc ``@Nadrieril``
[^1]: The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see #44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by `deref_patterns`). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR.
deref patterns: implement implicit deref patterns
This implements implicit deref patterns (per https://hackmd.io/4qDDMcvyQ-GDB089IPcHGg#Implicit-deref-patterns) and adds tests and an unstable book chapter.
Best reviewed commit-by-commit. Overall there's a lot of additions, but a lot of that is tests, documentation, and simple(?) refactoring.
Tracking issue: #87121
r? ``@Nadrieril``
do not emit `OpaqueCast` projections with `-Znext-solver`
We normalize opaque types in their defining scope if the new solver is enabled. This means projections do not contain any 'revealable' opaque types we need to worry about. We either have a type which has been normalized by writeback or we need to normalize it anyways.
r? ```@compiler-errors``` ```@oli-obk```
