…andler] directly

The "continue" in the name was really confusing; it sounds way too much like "resume" which is a totally different concept around panics.

The construction of the GlobalCtxt is moved from a generator's stack to
the Queries struct.  Since the GlobalCtxt requires the HIR Forest and the
arenas to live longer, those are moved into Queries the same way.

The resulting handling of objects is more brittle, because consumers of
the Once objects need to be careful of their initialisation.

…d elements.

fix clippy

allow customising ty::TraitRef's printing behavior

fix clippy

stylistic fix

Fixed the documentation for any as is a trait rather than a type.

Rephrase docs in for ptr

These methods can be supplied with NULL just fine, this is the whole point of `Option<&T>` return type.

Allow customising ty::TraitRef's printing behavior

This pr allows to explicitly choose which representation of `TraitRef` (`<T as Trait<U>>` or `Trait<U>`) you want to print. `Debug` and `Display` representations of `TraitRef` now match.

Closes rust-lang#59188.

Panic machinery comments and tweaks

This is mostly more comments, but I also renamed some things:
* `BoxMeUp::box_me_up` is not terribly descriptive, and since this is a "take"-style method (the argument is `&mut self` but the return type is fully owned, even though you can't tell from the type) I chose a name involving "take".
* `continue_panic_fmt` was very confusing as it was entirely unclear what was being continued -- for some time I thought "continue" might be the same as "resume" for a panic, but that's something entirely different. So I renamed this to `begin_panic_handler`, matching the `begin_panic*` theme of the other entry points.

r? @Dylan-DPC @SimonSapin

…r=oli-obk

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 rust-lang#66203 (comment) for some context around this approach.

Fixes rust-lang#51314.

Handle GlobalCtxt directly from librustc_interface query system

This PR constructs the `GlobalCtxt` as a member of the `Queries` in librustc_interface.
This simplifies the code to construct it, at the expense of added complexity in the query control flow.
This allows to handle the arenas directly from librustc_interface.

Based on rust-lang#66707

r? @Zoxc

…=cramertj

Record temporary static references in generator witnesses

Closes rust-lang#66695

* Record the pointer to static's type in MIR.
* Normalize the static's type (so that constants can be compared correctly).

…r=Dylan-DPC

Cleanup error code

r? @Dylan-DPC

…ssage-assigner, r=Dylan-DPC

Clarifies how to tag users for assigning PRs

Clarifies language of where to put `r?` text to assign a particular user. Mostly a follow up of [this discussion](rust-lang#66797 (comment)).

Clarify `{f32,f64}::EPSILON` docs

The doc for `EPSILON` says:
>  This is the difference between `1.0` and the next **largest** representable number.

Which is a bit unclear.

[Wikipedia](https://en.wikipedia.org/wiki/Machine_epsilon) says
> Machine epsilon is defined as the difference between 1 and the next **larger** floating point number

So this PR update the docs to match the Wikipedia version.

The original PR also has this in a [comment](rust-lang#50919 (comment)).

…i-obk

Miri: do not consider memory allocated by caller_location leaked

Fixes rust-lang/miri#1071

r? @oli-obk

I am not sure if this is the best approach, but it certainly is the easiest.

Minor documentation fix

Fixed the documentation for any as is a trait rather than a type.