Make const panic!("..") work in Rust 2021.

During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead.

panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.

r? `@RalfJung`

Create `QuerySideEffects` and use it for diagnostics

The code for saving and loading diagnostics during execution is generalized to handle a new `QuerySideEffects` struct. Currently, this struct just holds diagnostics - in a follow-up PR, I plan to add support for storing attriutes marked as used during query execution.

This is a pure refactor, with no intended behavior changes.

Remove unsound TrustedRandomAccess implementations

Removes the implementations that depend on the user-definable trait `Copy`.

Fixes #85873 in the most straightforward way.

<hr>

_Edit:_ This PR now contains additional trait infrastructure to avoid performance regressions around in-place collect, see the discussion in this thread starting from the codegen test failure at https://github.com/rust-lang/rust/pull/85874#issuecomment-872327577.

With this PR, `TrustedRandomAccess` gains additional documentation that specifically allows for and specifies the safety conditions around subtype coercions – those coercions can happen in safe Rust code with the `Zip` API’s usage of `TrustedRandomAccess`. This PR introduces a new supertrait of `TrustedRandomAccess`(currently named `TrustedRandomAccessNoCoerce`) that _doesn’t allow_ such coercions, which means it can be still be useful for optimizing cases such as in-place collect where no iterator is handed out to a user (who could do coercions) after a `get_unchecked` call; the benefit of the supertrait is that it doesn’t come with the additional safety conditions around supertraits either, so it can be implemented for more types than `TrustedRandomAccess`.

The `TrustedRandomAccess` implementations for `vec::IntoIter`, `vec_deque::IntoIter`, and `array::IntoIter` are removed as they don’t conform with the newly documented safety conditions, this way unsoundness is removed. But this PR in turn (re-)adds a `TrustedRandomAccessNoCoerce` implementation for `vec::IntoIter` to avoid performance regressions from stable in a case of in-place collecting of `Vec`s [the above-mentioned codegen test failure]. Re-introducing the (currently nightly+beta-only) impls for `VecDeque`’s and `[T; N]`’s iterators is technically possible, but goes beyond the scope of this PR (i.e. it can happen in a future PR).

Rollup of 10 pull requests

Successful merges:

 - #81050 (Stabilize core::task::ready!)
 - #81363 (Remove P: Unpin bound on impl Future for Pin)
 - #86839 (Add doc aliases to fs.rs)
 - #87435 (fix example code for E0617)
 - #87451 (Add support for tuple struct field documentation)
 - #87491 (Integrate context into the memorial to Anna)
 - #87521 (Add long explanation for E0498)
 - #87527 (Don't run MIR unsafeck at all when using `-Zthir-unsafeck`)
 - #87550 (Add `CI_ONLY_WHEN_CHANNEL` and run `x86_64-gnu-stable` only on nightly)
 - #87565 (Use backticks when referring to `core::future::Ready` in panic message)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Use backticks when referring to `core::future::Ready` in panic message

Add `CI_ONLY_WHEN_CHANNEL` and run `x86_64-gnu-stable` only on nightly

Backporting a commit made on #87508. cc ``@Mark-Simulacrum``

Don't run MIR unsafeck at all when using `-Zthir-unsafeck`

I don't know how I missed this :D
r? ``@oli-obk``

Add long explanation for E0498

Helps with #61137

Integrate context into the memorial to Anna

This came up after I reviewed https://github.com/rust-lang/rust/pull/87298, but I didn't propose this in time before that PR was merged.

If y'all feel this is too much churn on the file, no worries, feel free to close, but I felt this was a more fitting integration of the memorial into the test suite.

CC ``@boringcactus.``

Add support for tuple struct field documentation

Fixes  #42615.
This is #80320 updated to new codebase and with added tests.
Part of https://github.com/rust-lang/rust/issues/83255.

cc ```@camelid``` (since you were involved on the original PR).
r? ```@jyn514```

fix example code for E0617

Closes #86908

Add doc aliases to fs.rs

Add aliases for create_dir, create_dir_all, remove_dir, remove_dir_all

Remove P: Unpin bound on impl Future for Pin

We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly.

The `Unpin` bound was originally added in #56939 following the recommendation of ``@withoutboats`` in https://github.com/rust-lang/rust/issues/55766#issue-378417538

That comment does not give explicit justification for why the bound should be added. The relevant context was:

> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound.

The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.

Stabilize core::task::ready!

_Tracking issue: https://github.com/rust-lang/rust/issues/70922_

This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886, this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed.

The `task::ready!` API has existed in the futures ecosystem for several years, and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library.

r? ``@tmandry``

cc/ ``@rust-lang/wg-async-foundations`` ``@rust-lang/libs``

## Example
```rust
use core::task::{Context, Poll};
use core::future::Future;
use core::pin::Pin;

async fn get_num() -> usize {
    42
}

pub fn do_poll(cx: &mut Context<'_>) -> Poll<()> {
    let mut f = get_num();
    let f = unsafe { Pin::new_unchecked(&mut f) };

    let num = ready!(f.poll(cx));
    // ... use num

    Poll::Ready(())
}
```

update Miri

Fixes https://github.com/rust-lang/rust/issues/87518
Cc `@rust-lang/miri` r? `@ghost`

Add `mkdir` to `create_dir`, `rmdir` to `remove_dir`.

Rollup of 10 pull requests

Successful merges:

 - #87315 (Add docs for raw-dylib to unstable book)
 - #87330 (Use hashbrown's `extend_reserve()` in `HashMap`)
 - #87443 (Don't treat git repos as non-existent when `ignore_git` is set)
 - #87453 (Suggest removing unnecessary &mut as help message)
 - #87500 (Document math behind MIN/MAX consts on integers)
 - #87501 (Remove min_type_alias_impl_trait in favor of type_alias_impl_trait)
 - #87507 (SGX mutex is *not* moveable)
 - #87513 (bootstrap.py: change `git log` option to indicate desired behavior)
 - #87523 (Stop creating a reference then immediately dereferencing it.)
 - #87524 (Fix ICE in `diagnostic_hir_wf_check`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Co-authored-by: NRalf Jung <post@ralfj.de>

During const eval, this replaces calls to core::panicking::panic_fmt and
std::panicking::being_panic_fmt with a call to a new const fn:
core::panicking::const_panic_fmt. That function uses
fmt::Arguments::as_str() to get the str and calls panic_str with that
instead.

panic!() invocations with formatting arguments are still not accepted,
as the creation of such a fmt::Arguments cannot be done in constant
functions right now.

Add TrustedRandomAccessNoCoerce supertrait without requirements or guarantees about subtype coercions

Update all the TrustedRandomAccess impls to also implement the new supertrait

Include new details regarding coercions to a subtype.
These conditions also explain why the previously removed implementations
for {array, vec, vec_deque}::IntoIter<T> were unsound, because they introduced
an extra `T: Clone` for the TrustedRandomAccess impl, even though their parameter T
is covariant.

Removes the implementations that depend on the user-definable trait `Copy`.

Fix ICE in `diagnostic_hir_wf_check`

Fixes #87495. The [documentation for `ObligationCauseCode::WellFormed`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/traits/enum.ObligationCauseCode.html#variant.WellFormed) says that

> it is always correct [...] to specify `WellFormed(None)`

instead of `WellFormed(Some(...))`, which seems to have caused the issue here, as `diagnostic_hir_wf_check` does not expect to be called with an associated constant and will ICE:

https://github.com/rust-lang/rust/blob/fd853c00e255559255885aadff9e93a1760c8728/compiler/rustc_typeck/src/hir_wf_check.rs#L131-L134

Therefore, I have changed `check_associated_item()` to pass a `WellFormed(None)` for associated constants.

r? ``@Aaron1011``

Stop creating a reference then immediately dereferencing it.

Stop creating a reference then immediately dereferencing it.