Add some track_caller info to precondition panics
Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful.
I thought of this while looking at https://github.com/rust-lang/rust/pull/129642#issuecomment-2311703898.
The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces.
The perf implications of this are:
* Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out.
* The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU.
* The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
Rename `{GenericArg,Term}::unpack()` to `kind()`
A well-deserved rename IMO.
r? `@oli-obk` or `@lcnr` (or anyone)
cc `@rust-lang/types,` but I'd be surprised if this is controversial.
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
interpret: do not force_allocate all return places
A while ago I cleaned up our `PlaceTy` a little, but as a side-effect of that, return places had to always be force-allocated. That turns out to cause quite a few extra allocations, and for a project we are doing where we marry Miri with a model checker, that means a lot of extra work -- local variables are just so much easier to reason about than allocations.
So, this PR brings back the ability to have the return place be just a local of the caller. To make this work cleanly I had to rework stack pop handling a bit, which also changes the output of Miri in some cases as the span for errors occurring during a particular phase of stack pop changed.
With these changes, a no-std binary with a function of functions that just take and return scalar types and that uses no pointers now does not move *any* local variables into memory. :)
r? `@oli-obk`
Cleanup CodegenFnAttrFlags
- Rename `USED` to `USED_COMPILER` to better reflect its behavior.
- Reorder some items to group the used and allocator flags together
- Renumber them without gaps
rename internal panicking::try to catch_unwind
The public function is called `catch_unwind`, the intrinsic at some point got renamed to `catch_unwind` -- there's no reason to have the internal implementation of this still be called `try`, so let's rename it to match the rest.
- Rename `USED` to `USED_COMPILER` to better reflect its behavior.
- Reorder some items to group the used and allocator flags together
- Renumber them without gaps
GetUserProfileDirectoryW is now documented to always store the size
Update to match https://github.com/MicrosoftDocs/sdk-api/pull/1810
Also fix a bug in the Miri implementation while I am starting at that code...
r? ```@ChrisDenton```
Fixes#141254
