For some time CTFE has been using a dedicated MIR which is never
optimized, so the check for promoted became redundant.

The change is limited to the iteration over indices instead of using
`basic_blocks_mut()` directly, in the case the previous implementation
intentionally avoided invalidating the caches stored in MIR body.

Previously for enums using the `Variants::Single` layout, the variant
index was being confused with its discriminant. For example, in the case
of `enum E { A = 1 }`.

Use `discriminant_for_variant` to avoid the issue.

We have stable options for adding linker arguments; we should have a
stable option to help debug linker arguments.

The documentation makes it clear that the *exact* format of the output
is not a stable guarantee.

Before, the trait's associated item would be used. Now, the impl's
associated item is used. The only exception is for impls that use
default values for associated items set by the trait. In that case,
the trait's associated item is still used.

As an example of the old and new behavior, take this code:

    trait MyTrait {
        type AssocTy;
    }

    impl MyTrait for String {
        type AssocTy = u8;
    }

Before, when resolving a link to `String::AssocTy`,
`resolve_associated_trait_item` would return the associated item for
`MyTrait::AssocTy`. Now, it would return the associated item for
`<String as MyTrait>::AssocTy`, as it claims in its docs.

Before this, the item name and the stability, source link, and "collapse
all docs" would compete for room on a single line, resulting in awkward
wrapping behavior on mobile. This gives a separate line for that
out-of-band information. It also removes the "copy path" icon on mobile
to make a little more room.

Also, switch to flex-wrap: wrap, so anytime there's not enough room for
`source`, it gets bumped to the next line.

Add MaybeUninit::(slice_)as_bytes(_mut)

This adds methods to convert between `MaybeUninit<T>` and a slice of `MaybeUninit<u8>`. This is safe since `MaybeUninit<u8>` can correctly handle padding bytes in any `T`.

These methods are added:
```rust
impl<T> MaybeUninit<T> {
	pub fn as_bytes(&self) -> &[MaybeUninit<u8>];
	pub fn as_bytes_mut(&mut self) -> &mut [MaybeUninit<u8>];
	pub fn slice_as_bytes(this: &[MaybeUninit<T>]) -> &[MaybeUninit<u8>];
	pub fn slice_as_bytes_mut(this: &mut [MaybeUninit<T>]) -> &mut [MaybeUninit<u8>];
}
```

…wiser

Fix variant index / discriminant confusion in uninhabited enum branching

Fix confusion between variant index and variant discriminant. The pass
incorrectly assumed that for `Variants::Single` variant index is the same as
variant discriminant.

r? `@wesleywiser`

…rgs, r=pnkfelix

Stabilize `-Z print-link-args` as `--print link-args`

We have stable options for adding linker arguments; we should have a
stable option to help debug linker arguments.

Add documentation for the new option. In the documentation, make it clear that
the *exact* format of the output is not a stable guarantee.

…illaumeGomez

rustdoc: decouple stability and const-stability

This PR tweaks the stability rendering code to consider stability and const-stability separately. This fixes two issues:

- Stabilities that match the enclosing item are now always omitted, even if the item has const-stability as well (rust-lang#90552)
- Const-stable unstable functions will now have their (const-) stability rendered.

Fixes rust-lang#90552.

Point at correct argument when async fn output type lifetime disagrees with signature

Fixes most of rust-lang#74256.

## Problems fixed

This PR fixes a couple of related problems in the error reporting code.

### Highlighting the wrong argument

First, the error reporting code was looking at the desugared return type of an `async fn` to decide which parameter to highlight. For example, a function like

```rust
async fn async_fn(self: &Struct, f: &u32) -> &u32
{ f }
```

desugars to

```rust
async fn async_fn<'a, 'b>(self: &'a Struct, f: &'b u32)
-> impl Future<Output = &'a u32> + 'a + 'b
{ f }
```

Since `f: &'b u32` is returned but the output type is `&'a u32`, the error would occur when checking that `'a: 'b`.

The reporting code would look to see if the "offending" lifetime `'b` was included in the return type, and because the code was looking at the desugared future type, it was included. So it defaulted to reporting that the source of the other lifetime `'a` (the `self` type) was the problem, when it was really the type of `f`. (Note that if it had chosen instead to look at `'a` first, it too would have been included in the output type, and it would have arbitrarily reported the error (correctly this time) on the type of `f`.)

Looking at the actual future type isn't useful for this reason; it captures all input lifetimes. Using the written return type for `async fn` solves this problem and results in less confusing error messages for the user.

This isn't a perfect fix, unfortunately; writing the "manually desugared" form of the above function still results in the wrong parameter being highlighted. Looking at the output type of every `impl Future` return type doesn't feel like a very principled approach, though it might work. The problem would remain for function signatures that look like the desugared one above but use different traits. There may be deeper changes required to pinpoint which part of each type is conflicting.

### Lying about await point capture causing lifetime conflicts

The second issue fixed by this PR is the unnecessary complexity in `try_report_anon_anon_conflict`. It turns out that the root cause I suggested in rust-lang#76547 (comment) wasn't really the root cause. Adding special handling to report that a variable was captured over an await point only made the error messages less correct and pointed to a problem other than the one that actually occurred.

Given the above discussion, it's easy to see why: `async fn`s capture all input lifetimes in their return type, so holding an argument across an await point should never cause a lifetime conflict! Removing the special handling simplified the code and improved the error messages (though they still aren't very good!)

## Future work

* Fix error reporting on the "desugared" form of this code
* Get the `suggest_adding_lifetime_params` suggestion firing on these examples
  * cc rust-lang#42703, I think

r? `@estebank`

improve `_` constants in item signature handling

removing the "type" from the error messages does slightly worsen the error messages for types, but figuring out whether the placeholder is for a type or a constant and correctly dealing with that seemed fairly difficult to me so I took the easy way out ✨ Imo the error message is still clear enough.

r? `@BoxyUwU` cc `@estebank`

…chenkov

intra-doc: Use the impl's assoc item where possible

Before, the trait's associated item would be used. Now, the impl's
associated item is used. The only exception is for impls that use
default values for associated items set by the trait. In that case,
the trait's associated item is still used.

As an example of the old and new behavior, take this code:

    trait MyTrait {
        type AssocTy;
    }

    impl MyTrait for String {
        type AssocTy = u8;
    }

Before, when resolving a link to `String::AssocTy`,
`resolve_associated_trait_item` would return the associated item for
`MyTrait::AssocTy`. Now, it would return the associated item for
`<String as MyTrait>::AssocTy`, as it claims in its docs.

r? `@petrochenkov`

…_t, r=michaelwoerister

Change lint message to be stronger for &T -> &mut T transmute

The old message implied that it's only UB if you use the reference to mutate, which (as far as I know) is not true. As in, the following program has UB, and a &T -> &mut T transmute is effectively an `unreachable_unchecked`.

```rust
fn main() {
    #[allow(mutable_transmutes)]
    unsafe {
        let _ = std::mem::transmute::<&i32, &mut i32>(&0);
    }
}
```

In the future, it might be a good idea to use the edition system to make this a hard error, since I don't think it is *ever* defined behaviour? Unless we rule that `&UnsafeCell<i32> -> &mut i32` is fine. (That, and you always could just use `.get()`, so you're not losing anything)

…eGomez

Rustdoc mobile: put out-of-band info on its own line

Before this, the item name and the stability, source link, and "collapse
all docs" would compete for room on a single line, resulting in awkward
wrapping behavior on mobile. This gives a separate line for that
out-of-band information. It also removes the "copy path" icon on mobile
to make a little more room.

Demo: https://rustdoc.crud.net/jsha/mobile-column-flex/std/string/struct.String.html

r? `@GuillaumeGomez`

…lacrum

Help optimize out backtraces when disabled

The comment in `rust_backtrace_env` says:

>    // If the `backtrace` feature of this crate isn't enabled quickly return
>   // `None` so this can be constant propagated all over the place to turn
>  // optimize away callers.

but this optimization has regressed, because the only caller of this function had an alternative path that unconditionally (and pointlessly) asked for a full backtrace, so the disabled state couldn't propagate.

I've added a getter for the full format that respects the feature flag, so that the caller will now be able to really optimize out the disabled backtrace path. I've also made `rust_backtrace_env` trivially inlineable when backtraces are disabled.

…r=notriddle

Fix star handling in block doc comments

Fixes rust-lang#92872.

Some extra explanation about this PR and why rust-lang#92357 created this regression: when we merge doc comment kinds for example in:

```rust
/// he
/**
* hello
*/
#[doc = "boom"]
```

We don't want to remove the empty lines between them. However, to correctly compute the "horizontal trim", we still need it, so instead, I put back a part of the "vertical trim" directly in the "horizontal trim" computation so it doesn't impact the output buffer but allows us to correctly handle the stars.

r? `@camelid`

…=lnicola

⬆️ rust-analyzer

r? `@ghost`

…tly, r=pietroalbini

Fix CVE-2022-21658

See https://blog.rust-lang.org/2022/01/20/cve-2022-21658.html. Patches reviewed by `@m-ou-se.`

r? `@ghost`