handle diverging functions forwarding their return place
Fixes https://github.com/rust-lang/miri/issues/1075: the shim around diverging closures turned into function pointers actually "obtains" a return place inside a diverging function, but just uses it as the return place for a diverging callee. Handle this by using NULL places.
This is kind of a hack as it breaks our invariant that all places are dereferencable, but we'd eventually let raw pointers break that anyway I assume so that seems fine.
r? @oli-obk
Handle const-checks for `&mut` outside of `HasMutInterior`
Addresses [this comment](https://github.com/rust-lang/rust/pull/64470#discussion_r328200508).
Const-checking relied on `HasMutInterior` to forbid `&mut` in a const context. This was strange because all we needed to do was look for an `Rvalue::Ref` with a certain `BorrowKind`, whereas the `Qualif` traits are specifically meant to get the qualifs for a *value*. This PR removes that logic from `HasMutInterior` and moves it into `check_consts::Validator`.
As a result, we can now properly handle qualifications for `static`s, which had to be ignored previously since you can e.g. borrow a static `Cell` from another `static`. We also remove the `derived_from_illegal_borrow` logic, since it is no longer necessary; we give good errors for subsequent reborrows/borrows of illegal borrows.
add reusable MachineStop variant to Miri engine error enum
Replace the Miri-tool-specific `Exit` error variant with something dynamically typed that all clients of the Miri engine can use.
r? @oli-obk
Cc https://github.com/rust-lang/rust/issues/66902
rustc: move mir::SourceScopeLocalData to a field of SourceScopeData.
By having one `ClearCrossCrate<SourceScopeLocalData>` for each scope, as opposed to a single `ClearCrossCrate` for all the `SourceScopeLocalData`s, we can represent the fact that some scopes have `SourceScopeLocalData` associated with them, and some don't.
This is useful when doing MIR inlining across crates, because the `ClearCrossCrate` will be `Clear` for the cross-crate MIR scopes and `Set` for the local ones.
Also see https://github.com/rust-lang/rust/pull/66203#issuecomment-555589574 for some context around this approach.
Fixes#51314.
Use recursion_limit for const eval stack limit
cc https://github.com/rust-lang/miri/issues/643 @orium @RalfJung
I'm really not certain how exactly to handle this change, but it looks like it's that simple.
Reuse `recursion_limit` ("The maximum recursion limit for potentially infinitely recursive operations such as auto-dereference and monomorphization") which is configurable by the user for the const evaluation stack frame limit.
The other option is to make `const_eval_stack_frame_limit` configurable in the same way as `recursion_limit` (but I'm not sure how to do that and it'd be a bigger change).
Fixes https://github.com/rust-lang/miri/issues/643.
Improve lifetime errors with implicit trait object lifetimes
r? @matthewjasper
cc @estebank
I still think the ideal solution would be to construct a `BrAnon`, but that seems like a more invasive change, and can be done later. This at least gets rid of the hack in `OutliveSuggestion` and is slightly more principled.
Feature gating *declarations* => new crate `rustc_feature`
This PR moves the data-oriented parts of feature gating into its own crate, `rustc_feature`.
The parts consist of some data types as well as `accepted`, `active`, `removed`, and `builtin_attrs`.
Feature gate checking itself remains in `syntax::feature_gate::check`. The parts which define how to emit feature gate errors could probably be moved to `rustc_errors` or to the new `rustc_session` crate introduced in #66878. The visitor itself could probably be moved as a pass in `rustc_passes` depending on how the dependency edges work out.
The PR also contains some drive-by cleanup of feature gate checking. As such, the PR probably best read commit-by-commit.
r? @oli-obk
cc @petrochenkov
cc @Mark-Simulacrum
Initial implementation of or-pattern usefulness checking
The title says it all.
I'd like to request a perf run on that, hopefully this doesn't kill performance too much.
cc https://github.com/rust-lang/rust/issues/54883
Miri: do not consider memory allocated by caller_location leaked
Fixes https://github.com/rust-lang/miri/issues/1071
r? @oli-obk
I am not sure if this is the best approach, but it certainly is the easiest.
Record temporary static references in generator witnesses
Closes#66695
* Record the pointer to static's type in MIR.
* Normalize the static's type (so that constants can be compared correctly).
Async fn resume after completion
#65419 -- Attempting to run an async fn after completion mentions generators
Not yet ready for review - work in progress
Just need to run the tests on a proper build server
Create promoted MIR fragments for `const` and `static`s
Resolves#65732.
The previous strategy of removing `Drop` and `StorageDead` for promoted locals only worked for rvalue lifetime extension and only if no `loop`s were present. This PR applies the approach currently used for `fn` and `const fn`s to `const` and `statics`.
This may have some performance impacts.
r? @eddyb
