rustdoc: Avoid using `Iterator::count()` where possible

`count()` iterates over the whole collection. Using `len()` instead, or
`.next().is_none()` when comparing to zero, should be faster.

rustdoc: Remove unused `DocFragment.line` field

Auto merge of #90774 - alexcrichton:tweak-const, r=m-ou-se

std: Tweak expansion of thread-local const

This commit tweaks the expansion of `thread_local!` when combined with a
`const { ... }` value to help ensure that the rules which apply to
`const { ... }` blocks will be the same as when they're stabilized.
Previously with this invocation:

    thread_local!(static NAME: Type = const { init_expr });

this would generate (on supporting platforms):

    #[thread_local]
    static NAME: Type = init_expr;

instead the macro now expands to:

    const INIT_EXPR: Type = init_expr;
    #[thread_local]
    static NAME: Type = INIT_EXPR;

with the hope that because `init_expr` is defined as a `const` item then
it's not accidentally allowing more behavior than if it were put into a
`static`. For example on the stabilization issue [this example][ex] now
gives the same error both ways.

[ex]: https://github.com/rust-lang/rust/issues/84223#issuecomment-953384298

Auto merge of #91019 - JohnTitor:rollup-q95ra7r, r=JohnTitor

Rollup of 8 pull requests

Successful merges:

 - #90386 (Add `-Zassert-incr-state` to assert state of incremental cache)
 - #90438 (Clean up mess for --show-coverage documentation)
 - #90480 (Mention `Vec::remove` in `Vec::swap_remove`'s docs)
 - #90607 (Make slice->str conversion and related functions `const`)
 - #90750 (rustdoc: Replace where-bounded Clean impl with simple function)
 - #90895 (require full validity when determining the discriminant of a value)
 - #90989 (Avoid suggesting literal formatting that turns into member access)
 - #91002 (rustc: Remove `#[rustc_synthetic]`)

Failed merges:

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

Rollup merge of #91002 - petrochenkov:nosynth, r=davidtwco

rustc: Remove `#[rustc_synthetic]`

This function parameter attribute was introduced in https://github.com/rust-lang/rust/pull/44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.

Noticed while reviewing https://github.com/rust-lang/rust/pull/90947.

Rollup merge of #90989 - notriddle:notriddle/rustc-suggest-float-ending-in-dot, r=sanxiyn

Avoid suggesting literal formatting that turns into member access

Fixes #90974

Rollup merge of #90895 - RalfJung:read-discriminant-valid, r=oli-obk

require full validity when determining the discriminant of a value

This resolves (for now) the semantic question that came up in https://github.com/rust-lang/rust/pull/89764: arguably, reading the discriminant of a value is 'using' that value, so we are in our right to demand full validity. Reading a discriminant is somewhat special in that it works for values of *arbitrary* type; all the other primitive MIR operations work on specific types (e.g. `bool` or an integer) and basically implicitly require validity as part of just "doing their job".

The alternative would be to just require that the discriminant itself is valid, if any -- but then what do we do for types that do not have a discriminant, which kind of validity do we check? [This code](https://github.com/rust-lang/rust/blob/81117ff930fbf3792b4f9504e3c6bccc87b10823/compiler/rustc_codegen_ssa/src/mir/place.rs#L206-L215) means we have to at least reject uninhabited types, but I would rather not special case that.

I don't think this can be tested in CTFE (since validity is not enforced there), I will add a compile-fail test to Miri:
```rust
#[allow(enum_intrinsics_non_enums)]
fn main() {
    let i = 2u8;
    std::mem::discriminant(unsafe { &*(&i as *const _ as *const bool) }); // UB
}
```

(I tried running the check even on the CTFE machines, but then it runs during ConstProp and that causes all sorts of problems. We could run it for ConstEval but not ConstProp, but that simply does not seem worth the effort currently.)

r? ``@oli-obk``

Rollup merge of #90750 - camelid:rm-tuple-impls-1, r=jyn514

rustdoc: Replace where-bounded Clean impl with simple function

This is the first step in removing the Clean impls for tuples. Either way, this
significantly simplifies the code since it reduces the amount of "trait magic".

(To clarify, I'm referring to impls like `impl Clean for (A, B)`, not Clean impls
that work on tuples in the user's program.)

cc ``@jyn514``

Rollup merge of #90607 - WaffleLapkin:const_str_from_utf8, r=oli-obk

Make slice->str conversion and related functions `const`

This PR marks the following APIs as `const`:
```rust
// core::str
pub const fn from_utf8(v: &[u8]) -> Result<&str, Utf8Error>;
pub const fn from_utf8_mut(v: &mut [u8]) -> Result<&mut str, Utf8Error>;
pub const unsafe fn from_utf8_unchecked_mut(v: &mut [u8]) -> &mut str;

impl Utf8Error {
    pub const fn valid_up_to(&self) -> usize;
    pub const fn error_len(&self) -> Option<usize>;
}
```

Everything but `from_utf8_unchecked_mut` uses `const_str_from_utf8` feature gate, `from_utf8_unchecked_mut` uses `const_str_from_utf8_unchecked_mut` feature gate.

---

I'm not sure why `from_utf8_unchecked_mut` was left out being  non-`const`, considering that `from_utf8_unchecked` is not only `const`, but **`const` stable**.

---

r? ```@oli-obk``` (performance-only `const_eval_select` use)

Rollup merge of #90480 - r00ster91:remove, r=kennytm

Mention `Vec::remove` in `Vec::swap_remove`'s docs

Thought this was a nice addition.

Rollup merge of #90438 - GuillaumeGomez:doc-show-coverage, r=camelid

Clean up mess for --show-coverage documentation

It was somewhat duplicated for some reasons... Anyway, this remove this duplication and clean up a bit.

r? ```@camelid```

Rollup merge of #90386 - pierwill:assert-incr-state-85864, r=Aaron1011

Add `-Zassert-incr-state` to assert state of incremental cache

Closes #85864.

Auto merge of #90382 - alexcrichton:wasm64-libstd, r=joshtriplett

std: Get the standard library compiling for wasm64

This commit goes through and updates various `#[cfg]` as appropriate to
get the wasm64-unknown-unknown target behaving similarly to the
wasm32-unknown-unknown target. Most of this is just updating various
conditions for `target_arch = "wasm32"` to also account for `target_arch
= "wasm64"` where appropriate. This commit also lists `wasm64` as an
allow-listed architecture to not have the `restricted_std` feature
enabled, enabling experimentation with `-Z build-std` externally.

The main goal of this commit is to enable playing around with
`wasm64-unknown-unknown` externally via `-Z build-std` in a way that's
similar to the `wasm32-unknown-unknown` target. These targets are
effectively the same and only differ in their pointer size, but wasm64
is much newer and has much less ecosystem/library support so it'll still
take time to get wasm64 fully-fledged.

Fill in tracking issues for `const_str_from_utf8` and `const_str_from_utf8_unchecked_mut` features

Clean up mess for --show-coverage documentation

rustc: Remove `#[rustc_synthetic]`

This function parameter attribute was introduced in https://github.com/rust-lang/rust/pull/44866 as an intermediate step in implementing `impl Trait`, it's not necessary or used anywhere by itself.

Auto merge of #90991 - ehuss:update-cargo, r=ehuss

Update cargo

11 commits in 2e2a16e983f597da62bc132eb191bc3276d4b1bb..ad50d0d266213e0cc4f6e526a39d96faae9a3842
2021-11-08 15:13:38 +0000 to 2021-11-17 18:36:37 +0000
- Warn when alias shadows external subcommand (rust-lang/cargo#10082)
- Implement escaping to allow clean -p to delete all files when directory contains glob characters (rust-lang/cargo#10072)
- Match any error when failing to find executables (rust-lang/cargo#10092)
- Enhance error message for target auto-discovery (rust-lang/cargo#10090)
- Include note about bug while building on macOS in mdbook (rust-lang/cargo#10073)
- Improve the help text of the --quiet args for all commands (rust-lang/cargo#10080)
- `future-incompat-report` checks both stdout and stderr for color support (rust-lang/cargo#10024)
- Remove needless borrow to make clippy happy (rust-lang/cargo#10081)
- Describe the background color of the timing graph (rust-lang/cargo#10076)
- Make ProfileChecking comments a doc comments (rust-lang/cargo#10077)
- Fix test: hash value depends on endianness and bitness. (rust-lang/cargo#10011)

Avoid suggesting literal formatting that turns into member access

Fixes #90974

Make slice->str conversion and related functions const

This commit makes the following functions from `core::str` `const fn`:
- `from_utf8[_mut]` (`feature(const_str_from_utf8)`)
- `from_utf8_unchecked_mut` (`feature(const_str_from_utf8_unchecked_mut)`)
- `Utf8Error::{valid_up_to,error_len}` (`feature(const_str_from_utf8)`)

Update cargo

Fix emscripten tests

Auto merge of #90984 - matthiaskrgr:rollup-j5bs96a, r=matthiaskrgr

Rollup of 8 pull requests

Successful merges:

 - #89610 (warn on must_use use on async fn's)
 - #90667 (Improve diagnostics when a static lifetime is expected)
 - #90687 (Permit const panics in stable const contexts in stdlib)
 - #90772 (Add Vec::retain_mut)
 - #90861 (Print escaped string if char literal has multiple characters, but only one printable character)
 - #90884 (Fix span for non-satisfied trivial trait bounds)
 - #90900 (Remove workaround for the forward progress handling in LLVM)
 - #90901 (Improve ManuallyDrop suggestion)

Failed merges:

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

Rollup merge of #90901 - rukai:improve_manuallydrop_help, r=estebank

Improve ManuallyDrop suggestion

closes https://github.com/rust-lang/rust/issues/90585
* Fixes the recommended change to use ManuallyDrop as per the issue
* Changes the note to a help
* improves the span so it only points at the type.

Rollup merge of #90900 - andjo403:removeLlvm12Check, r=nikic

Remove workaround for the forward progress handling in LLVM

this workaround was only needed for LLVM < 12 and the minimum LLVM version was updated to 12 in #90175

Rollup merge of #90884 - Nilstrieb:fix-span-trivial-trait-bound, r=estebank

Fix span for non-satisfied trivial trait bounds

The spans for "trait bound not satisfied" errors in trivial trait bounds referenced the entire item (fn, impl, struct) before.
Now they only reference the obligation itself (`String: Copy`)

Address #90869

Rollup merge of #90861 - 5225225:nonprinting-char, r=davidtwco

Print escaped string if char literal has multiple characters, but only one printable character

Fixes #90857

I'm not sure about the error message here, it could get rather long and *maybe* using the names of characters would be better? That wouldn't help the length any, though.

Rollup merge of #90772 - GuillaumeGomez:vec-retain-mut, r=joshtriplett

Add Vec::retain_mut

This is to continue the discussion started in #83218.

Original comment was:

> Take 2 of #34265, since I needed this today.

The reason I think why we should add `retain_mut` is for coherency and for discoverability. For example we have `chunks` and `chunks_mut` or `get` and `get_mut` or `iter` and `iter_mut`, etc. When looking for mutable `retain`, I would expect `retain_mut` to exist. It took me a while to find out about `drain_filter`. So even if it provides an API close to `drain_filter`, just for the discoverability, I think it's worth it.

cc ``````@m-ou-se`````` ``````@jonas-schievink`````` ``````@Mark-Simulacrum``````

Rollup merge of #90687 - jhpratt:const_panic, r=oli-obk

Permit const panics in stable const contexts in stdlib

Without this change, it is not possible to use `panic!` and similar (including `assert!`) in stable const contexts inside of stdlib. See #89542 for a real-world case that currently fails for this reason. This does _not_ affect any user code.

For example, this snippet currently fails to compile:

```rust
#[stable(feature = "foo", since = "1.0.0")]
#[rustc_const_stable(feature = "foo", since = "1.0.0")]
const fn foo() {
    assert!(false);
    assert!(false, "foo");
}
```

With the addition of `#[rustc_const_unstable]` to `core::panicking::panic`, the error no longer occurs. This snippet has been added verbatim in this PR as a UI test.

To avoid needing to add `#![feature(core_panic)]` to libcore, the two instances of direct calls to `core::panicking::panic` have been switched to use the `panic!` macro.

I am requesting prioritization because this is holding up other stabilizations such as #89542 (which is otherwise ready to merge and succeeds with this change)

Rollup merge of #90667 - rukai:improve_static_lifetime_diagnostics, r=estebank

Improve diagnostics when a static lifetime is expected

Makes progress towards https://github.com/rust-lang/rust/issues/90600

The diagnostics here were previously entirely removed due to giving a misleading suggestion but if we instead provide an informative label in that same location it should better help the user understand the situation.

I included the example from the issue as it demonstrates an area where the diagnostics are still lacking.
Happy to remove that if its just adding noise atm.

Rollup merge of #89610 - guswynn:must_use_future, r=wesleywiser

warn on must_use use on async fn's

As referenced in #78149

This only works on `async` fn's for now, I can also look into if I can get `Box<dyn Future>` and `impl Future` working at this level (hir)

Auto merge of #90954 - Amanieu:fix-aarch64-asm, r=nikic

Update llvm submodule

- [DIArgList] Re-unique after changing operands to fix non-determinism
- [AArch64][GlobalISel] Fix an crash in RBS due to a new regclass being added.

Auto merge of #90966 - matthiaskrgr:rollup-4akzcrh, r=matthiaskrgr

Rollup of 7 pull requests

Successful merges:

 - #90733 (Build musl dist artifacts with debuginfo enabled)
 - #90787 (Add `#[inline]`s to `SortedIndexMultiMap`)
 - #90920 (:arrow_up: rust-analyzer)
 - #90933 (Fix await suggestion on non-future type)
 - #90935 (Alphabetize language features)
 - #90949 (update miri)
 - #90958 (Mark `<*const _>::align_offset` and `<*mut _>::align_offset` as `const fn`)

Failed merges:

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

Rollup merge of #90958 - WaffleLapkin:const_align_offset, r=oli-obk

Mark `<*const _>::align_offset` and `<*mut _>::align_offset` as `const fn`

This PR marks the following APIs as `const`:
```rust
impl<T> *const T {
    pub const fn align_offset(self, align: usize) -> usize;
}

impl<T> *mut T {
    pub const fn align_offset(self, align: usize) -> usize;
}
```

`const` implementation simply returns `usize::MAX`.

---

Previous discussion: https://github.com/rust-lang/rust/pull/90607#discussion_r743638164

---

r? `@oli-obk`

Rollup merge of #90949 - RalfJung:miri, r=RalfJung

update miri

This is needed to fix https://github.com/rust-lang/miri-test-libstd
r? ````@ghost````

Rollup merge of #90935 - jhpratt:alphabetize-features, r=joshtriplett

Alphabetize language features

This should significantly reduce the frequency of merge conflicts.

r? ````@joshtriplett````

````@rustbot```` label: +A-contributor-roadblock +S-waiting-on-review

Rollup merge of #90933 - compiler-errors:master, r=estebank

Fix await suggestion on non-future type

Remove a match block that would suggest to add `.await` in the case where the expected type's `Future::Output` equals the found type. We only want to suggest `.await`ing in the opposite case (the found type's `Future::Output` equals the expected type).

The code sample is here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=6ba6b83d4dddda263553b79dca9f6bcb

Before:
```
➜  ~ rustc --edition=2021 --crate-type=lib test.rs
error[E0308]: `match` arms have incompatible types
 --> test.rs:4:14
  |
2 |       let x = match 1 {
  |  _____________-
3 | |         1 => other(),
  | |              ------- this is found to be of type `impl Future`
4 | |         2 => other().await,
  | |              ^^^^^^^^^^^^^ expected opaque type, found enum `Result`
5 | |     };
  | |_____- `match` arms have incompatible types
  |
  = note: expected type `impl Future`
             found enum `Result<(), ()>`
help: consider `await`ing on the `Future`
  |
4 |         2 => other().await.await,
  |                           ++++++

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
```

After:
```
➜  ~ rustc +stage1 --edition=2021 --crate-type=lib test.rs
error[E0308]: `match` arms have incompatible types
 --> test.rs:4:14
  |
2 |       let x = match 1 {
  |  _____________-
3 | |         1 => other(),
  | |              ------- this is found to be of type `impl Future`
4 | |         2 => other().await,
  | |              ^^^^^^^^^^^^^ expected opaque type, found enum `Result`
5 | |     };
  | |_____- `match` arms have incompatible types
  |
  = note: expected type `impl Future`
             found enum `Result<(), ()>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
```

Fixes #90931

Rollup merge of #90920 - lnicola:rust-analyzer-2021-11-15, r=lnicola

:arrow_up: rust-analyzer

r? ``@ghost``

Rollup merge of #90787 - JohnTitor:inline-sorted-index-map, r=oli-obk

Add `#[inline]`s to `SortedIndexMultiMap`

They're small enough and good candidates to add `#[inline]` generally.

Rollup merge of #90733 - wesleywiser:musl_debuginfo, r=Mark-Simulacrum

Build musl dist artifacts with debuginfo enabled

Since our musl targets link to a version of musl we build and bundle
with the targets, if users need to debug into musl or generate
backtraces which contain parts of the musl library, they will be unable
to do so unless we enable and ship the debug info.

This patch changes our dist builds so they enabled debug info when
building musl. This patch also includes a fix for CFI detection in
musl's `configure` script which has been [posted upstream](https://www.openwall.com/lists/musl/2021/10/21/2).

The net effect of this is that we now ship debug info for musl in those
targets. This adds ~90kb to those artifacts but running `strip` on
binaries produced removes all of that. For a "hello world" Rust binary
on x86_64, the numbers are:

|                        | debug | release | release + strip |
|           -            |   -   |    -    |        -        |
| without musl debuginfo | 507kb |  495kb  |      410kb      |
| with musl debuginfo    | 595kb | 584kb | 410kb |

Once stripped, the final binaries are the same size (down to the byte).

Fixes #90103

r? `@Mark-Simulacrum`

Fix await suggestion better

Add emscripten to the "wasm" family of targets

Fill in tracking issue for feature `const_align_offset`

Mark `<*const _>::align_offset` and `<*mut _>::align_offset` as `const fn`

Update llvm submodule

Update compiler/rustc_passes/src/check_attr.rs

Co-authored-by: Yuki Okushi <jtitor@2k36.org>

update miri

Auto merge of #90919 - nnethercote:rm-DropArena, r=Mark-Simulacrum

Remove `DropArena`.

Most arena-allocate types that impl `Drop` get their own `TypedArena`, but a
few infrequently used ones share a `DropArena`. This sharing adds complexity
but doesn't help performance or memory usage. Perhaps it was more effective in
the past prior to some other improvements to arenas.

This commit removes `DropArena` and the sharing of arenas via the `few`
attribute of the `arena_types` macro. This change removes over 100 lines of
code and nine uses of `unsafe` (one of which affects the parallel compiler) and
makes the remaining code easier to read.

Auto merge of #90945 - JohnTitor:rollup-wc35xss, r=JohnTitor

Rollup of 8 pull requests

Successful merges:

 - #86455 (check where-clause for explicit `Sized` before suggesting `?Sized`)
 - #90801 (Normalize both arguments of `equate_normalized_input_or_output`)
 - #90803 (Suggest `&str.chars()` on attempt to `&str.iter()`)
 - #90819 (Fixes incorrect handling of TraitRefs when emitting suggestions.)
 - #90910 (fix getting the discriminant of a zero-variant enum)
 - #90925 (rustc_mir_build: reorder bindings)
 - #90928 (Use a different server for checking clock drift)
 - #90936 (Add a regression test for #80772)

Failed merges:

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

Increase tidy limit for parser by 1

Inline printable function

Remove debug output from test stderr

Suggest removing the non-printing characters

Print full char literal on error if any are non-printing

Rollup merge of #90936 - JohnTitor:issue-80772, r=Mark-Simulacrum

Add a regression test for #80772

Closes #80772

Rollup merge of #90928 - Mark-Simulacrum:fix-date-logging, r=pietroalbini

Use a different server for checking clock drift

The detectportal.firefox.com server seems to return a random-ish date; for
example I see the following across 5 curl's done consecutively locally, where
the real date is approximately 15 Nov 2021 06:36 UTC.

Date: Mon, 15 Nov 2021 13:34:53 GMT
Date: Mon, 15 Nov 2021 12:20:21 GMT
Date: Mon, 15 Nov 2021 00:06:47 GMT
Date: Mon, 15 Nov 2021 17:14:33 GMT
Date: Mon, 15 Nov 2021 13:33:21 GMT

Rollup merge of #90925 - krasimirgg:rustc_mir_build_fix, r=petrochenkov

rustc_mir_build: reorder bindings

No functional changes intended.

I'm playing around with building compiler components using nightly rust
(2021-11-02) in a non-standard way. I encountered the following error while
trying to build rustc_mir_build:

```
error[E0597]: `wildcard` does not live long enough
    --> rust/src/nightly/compiler/rustc_mir_build/src/build/matches/mod.rs:1767:82
     |
1767 |         let mut otherwise_candidate = Candidate::new(expr_place_builder.clone(), &wildcard, false);
     |                                                                                  ^^^^^^^^^ borrowed value does not live long enough
...
1799 |     }
     |     -
     |     |
     |     `wildcard` dropped here while still borrowed
     |     borrow might be used here, when `guard_candidate` is dropped and runs the destructor for type `Candidate<'_, '_>`
     |
     = note: values in a scope are dropped in the opposite order they are defined
```

I believe this flags an issue that may become an error in the future.
Swapping the order of `wildcard` and `guard_candidate` resolves it.

Rollup merge of #90910 - RalfJung:const-discriminant-empty-enum, r=petrochenkov

fix getting the discriminant of a zero-variant enum

Fixes https://github.com/rust-lang/rust/issues/89765

Rollup merge of #90819 - JakobDegen:issue-90804, r=petrochenkov

Fixes incorrect handling of TraitRefs when emitting suggestions.

Closes #90804 , although there were more issues here that were hidden by the thing that caused this ICE.

Underlying problem was that substitutions were being thrown out, which not only leads to an ICE but also incorrect diagnostics. On top of that, in some cases the self types from the root obligations were being mixed in with those from derived obligations.

This makes a couple diagnostics arguable worse ("`B<C>` does not implement `Copy`" instead of "`C` does not implement `Copy`") but the worse diagnostics are at least still correct and that downside is in my opinion clearly outweighed by the benefits of fixing the ICE and unambiguously wrong diagnostics.

Rollup merge of #90803 - TaKO8Ki:suggest-chars-on-attempt-to-iter, r=estebank

Suggest `&str.chars()` on attempt to `&str.iter()`

closes #90786

Rollup merge of #90801 - b-naber:missing_normalization_equate_inputs_output, r=jackh726

Normalize both arguments of `equate_normalized_input_or_output`

Fixes https://github.com/rust-lang/rust/issues/90638
Fixes https://github.com/rust-lang/rust/issues/90612

Temporary fix for a more complex underlying problem stemming from an inability to normalize closure substs during typecheck.

r? ````@jackh726````

Rollup merge of #86455 - tlyu:check-where-before-suggesting-unsized, r=estebank

check where-clause for explicit `Sized` before suggesting `?Sized`

Fixes #85945.

Based on #86454.

``@rustbot`` label +A-diagnostics +A-traits +A-typesystem +D-papercut +T-compiler

Auto merge of #90845 - JakobDegen:adt-drop-perf, r=Mark-Simulacrum

Address performance regression introduced by #90218

As part of the changes in #90218 , the `adt_drop_tys` and friends code stopped recursing through the query system, meaning that intermediate computations did not get cached. This change adds the recursions back in without re-introducing any of the old issues.

On local benchmarks this fixes the 5% regressions in #90504 ; the wg-grammar regressions didn't seem to move too much. I may take some time later to look into those.

Not sure who to request for review here, so will leave it up to whoever gets it.

refactor is_param_bound

check where clause before suggesting unsized

Suggest where feature should be placed

Alphabetize language features

This should significantly reduce the frequency of merge conflicts.

Auto merge of #90934 - JohnTitor:rollup-5soqo0j, r=JohnTitor

Rollup of 10 pull requests

Successful merges:

 - #85766 (Stabilize File::options())
 - #88601 (Implement `Termination` for `Result<Infallible, E>`)
 - #90058 (Stabilize -Z strip as -C strip)
 - #90790 (Fix standard library test with read_link)
 - #90834 (Android is not GNU)
 - #90835 (Rename WASI's `is_character_device` to `is_char_device`.)
 - #90837 (Move some tests to more reasonable directories - 9)
 - #90848 (Remove bigint_helper_methods for *signed* types)
 - #90892 (fix ICE on Miri/CTFE copy of half a pointer)
 - #90909 (disable portable SIMD tests in Miri)

Failed merges:

 - #90128 (Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0)

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

Add a regression test for #80772

Rollup merge of #90909 - RalfJung:miri-no-portable-simd, r=workingjubilee

disable portable SIMD tests in Miri

Until https://github.com/rust-lang/miri/issues/1912 is resolved, we'll have to skip these tests in Miri.

Rollup merge of #90892 - RalfJung:miri-partial-ptr-copy, r=oli-obk

fix ICE on Miri/CTFE copy of half a pointer

Fixes https://github.com/rust-lang/miri/issues/1910
r? `````@oli-obk`````

Rollup merge of #90848 - scottmcm:remove-signed-bigint-helpers, r=joshtriplett

Remove bigint_helper_methods for *signed* types

This PR inspired by `@cuviper's` comment @ https://github.com/rust-lang/rust/issues/90541#issuecomment-967309808

These are working well for *unsigned* types, so keep those, but for the the *signed* ones there are a bunch of questions about what the semantics and API should be.  For the main "helpers for big integer implementations" use, there's no need for the signed versions anyway.  There are plenty of other methods which exist for unsigned types but not signed ones, like `next_power_of_two`, so this isn't unusual.

Fixes #90541
Tracking issue #85532

Rollup merge of #90837 - c410-f3r:testsssssss, r=petrochenkov

Move some tests to more reasonable directories - 9

cc #73494
r? `@petrochenkov`

Rollup merge of #90835 - sunfishcode:sunfishcode/wasi-char-device, r=alexcrichton

Rename WASI's `is_character_device` to `is_char_device`.

Rename WASI's `FileTypeExt::is_character_device` to
`FileTypeExt::is_char_device`, for consistency with the Unix
`FileTypeExt::is_char_device`.

Also, add a `FileTypeExt::is_socket` function, for consistency with the
Unix `FileTypeExt::is_socket` function.

r? `@alexcrichton`

Rollup merge of #90834 - cuviper:android-gnu, r=petrochenkov

Android is not GNU

For a long time, the Android targets had `target_env=""`, but this changed to `"gnu"` in Rust 1.49.0. I tracked this down to #77729 which started setting `"gnu"` in the `linux_base` target options, and this was inherited by `android_base`. Then #78929 split the env into `linux_gnu_base`, but `android_base` was also changed to follow that. Android was not specifically mentioned in either pull request, so I believe this was an accident. Moving it back to `linux_base` will use an empty `env` again.

r? ````@Mark-Simulacrum````
cc ````@petrochenkov````

Rollup merge of #90790 - tamaroning:fix-lib-std-test, r=Mark-Simulacrum

Fix standard library test with read_link

closes #90669
resolve this issue by comparing between Paths instead of strs

Rollup merge of #90058 - joshtriplett:stabilize-strip, r=wesleywiser

Stabilize -Z strip as -C strip

Leave -Z strip available temporarily as an alias, to avoid breaking
cargo until cargo transitions to using -C strip.

Rollup merge of #88601 - ibraheemdev:termination-result-infallible, r=yaahc

Implement `Termination` for `Result<Infallible, E>`

As noted in #43301, `Result<!, E>` is not usable on stable.

Rollup merge of #85766 - workingjubilee:file-options, r=yaahc

Stabilize File::options()

Renames File::with_options to File::options, per consensus in
rust-lang/rust#65439, and stabilizes it.

Auto merge of #90827 - matthewjasper:assoc-item-cleanup-2, r=cjgillot

Assoc item cleanup Part 2

- Remove `AssocItem` from `RegionVariableOrigin::AutoRef`
- Use the `associated_item_def_ids` query instead of the `associated_items` query when possible

The change to `ObligationCauseCode` from #90639 is omitted because it caused a perf regression.

r? `@cjgillot`

Auto merge of #90821 - scottmcm:new-slice-reverse, r=Mark-Simulacrum

MIRI says `reverse` is UB, so replace it with something LLVM can vectorize

For small types with padding, the current implementation is UB because it does integer operations on uninit values.
```
error: Undefined Behavior: using uninitialized data, but this operation requires initialized memory
   --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5
    |
836 | /     uint_impl! { u32, u32, i32, 32, 4294967295, 8, "0x10000b3", "0xb301", "0x12345678",
837 | |     "0x78563412", "0x1e6a2c48", "[0x78, 0x56, 0x34, 0x12]", "[0x12, 0x34, 0x56, 0x78]", "", "" }
    | |________________________________________________________________________________________________^ using uninitialized data, but this operation requires initialized memory
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information

    = note: inside `core::num::<impl u32>::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13
    = note: inside `core::slice::<impl [Foo]>::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58
```
<https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=340739f22ca5b457e1da6f361768edc6>

But LLVM has gotten smarter since I wrote the previous implementation in 2017, so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize.  This code is much simpler and has very little `unsafe`, and is actually faster to boot!

If you're curious to see the codegen: <https://rust.godbolt.org/z/Pcn13Y9E3>

Before:
```
running 7 tests
test slice::reverse_simd_f64x4                           ... bench:      17,940 ns/iter (+/- 481) = 58448 MB/s
test slice::reverse_u128                                 ... bench:      17,758 ns/iter (+/- 205) = 59048 MB/s
test slice::reverse_u16                                  ... bench:     158,234 ns/iter (+/- 6,876) = 6626 MB/s
test slice::reverse_u32                                  ... bench:      62,047 ns/iter (+/- 1,117) = 16899 MB/s
test slice::reverse_u64                                  ... bench:      31,582 ns/iter (+/- 552) = 33201 MB/s
test slice::reverse_u8                                   ... bench:      81,253 ns/iter (+/- 1,510) = 12905 MB/s
test slice::reverse_u8x3                                 ... bench:     270,615 ns/iter (+/- 11,463) = 3874 MB/s
```

After:
```
running 7 tests
test slice::reverse_simd_f64x4                           ... bench:      17,731 ns/iter (+/- 306) = 59137 MB/s
test slice::reverse_u128                                 ... bench:      17,919 ns/iter (+/- 239) = 58517 MB/s
test slice::reverse_u16                                  ... bench:      43,160 ns/iter (+/- 607) = 24295 MB/s
test slice::reverse_u32                                  ... bench:      21,065 ns/iter (+/- 371) = 49778 MB/s
test slice::reverse_u64                                  ... bench:      21,118 ns/iter (+/- 482) = 49653 MB/s
test slice::reverse_u8                                   ... bench:      76,878 ns/iter (+/- 1,688) = 13639 MB/s
test slice::reverse_u8x3                                 ... bench:     264,723 ns/iter (+/- 5,544) = 3961 MB/s
```

Those are the existing benches, <https://github.com/rust-lang/rust/blob/14a2fd640e0df9ee8cc1e04280b0c3aff93c42da/library/alloc/benches/slice.rs#L322-L346>

Use a different server for checking clock drift

The detectportal.firefox.com server seems to return a random-ish date; for
example I see the following across 5 curl's done consecutively locally, where
the real date is approximaly 15 Nov 2021 06:36 UTC.

Date: Mon, 15 Nov 2021 13:34:53 GMT
Date: Mon, 15 Nov 2021 12:20:21 GMT
Date: Mon, 15 Nov 2021 00:06:47 GMT
Date: Mon, 15 Nov 2021 17:14:33 GMT
Date: Mon, 15 Nov 2021 13:33:21 GMT

Auto merge of #90473 - joshtriplett:stabilize-format-args-capture, r=Mark-Simulacrum

stabilize format args capture

Works as expected, and there are widespread reports of success with it, as well as interest in it.

RFC: rust-lang/rfcs#2795
Tracking issue: https://github.com/rust-lang/rust/issues/67984

Addressing items from the tracking issue:

- We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement, or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ).
- I've updated the documentation.
- `panic!` now supports capture as well.
- There are potentially opportunities to further improve diagnostics for invalid usage, such as if it looks like the user tried to use an expression rather than a variable. However, such cases are all already caught and provide reasonable syntax errors now, and we can always provided even friendlier diagnostics in the future.

rustc_mir_build: reorder bindings

No functional changes intended.

I'm playing around with building compiler components using nightly rust
(2021-11-02) in a non-standard way. I encountered the following error while
trying to build rustc_mir_build:

```
error[E0597]: `wildcard` does not live long enough
    --> rust/src/nightly/compiler/rustc_mir_build/src/build/matches/mod.rs:1767:82
     |
1767 |         let mut otherwise_candidate = Candidate::new(expr_place_builder.clone(), &wildcard, false);
     |                                                                                  ^^^^^^^^^ borrowed value does not live long enough
...
1799 |     }
     |     -
     |     |
     |     `wildcard` dropped here while still borrowed
     |     borrow might be used here, when `guard_candidate` is dropped and runs the destructor for type `Candidate<'_, '_>`
     |
     = note: values in a scope are dropped in the opposite order they are defined
```

I believe this flags an issue that may become an error in the future.
Swapping the order of `wildcard` and `guard_candidate` resolves it.

Auto merge of #90717 - kit-981:fix-ld64-flags, r=petrochenkov

Fix ld64 flags

- The `-exported_symbols_list` argument appears to be malformed for `ld64` (if you are not going through `clang`).
- The `-dynamiclib` argument isn't support for `ld64`. It should be guarded behind a compiler flag.

These problems are fixed by these changes. I have also refactored the way linker arguments are generated to be ld/compiler agnostic and therefore less error prone.

These changes are necessary to support cross-compilation to darwin targets.

:arrow_up: rust-analyzer

Stabilize -Z strip as -C strip

Leave -Z strip available temporarily as an alias, to avoid breaking
cargo until cargo transitions to using -C strip. (If the user passes
both, the -C version wins.)

Support having -Z and -C options with the same name

Tweak the `options!` macro to allow for -Z and -C options with the same
name without generating conflicting internal parsing functions.

Split out of the commit stabilizing -Z strip as -C strip.

Update test output

Stabilize format_args_capture

Works as expected, and there are widespread reports of success with it,
as well as interest in it.

Give examples of format args capture in the fmt module documentation

Remove `DropArena`.

Most arena-allocate types that impl `Drop` get their own `TypedArena`, but a
few infrequently used ones share a `DropArena`. This sharing adds complexity
but doesn't help performance or memory usage. Perhaps it was more effective in
the past prior to some other improvements to arenas.

This commit removes `DropArena` and the sharing of arenas via the `few`
attribute of the `arena_types` macro. This change removes over 100 lines of
code and nine uses of `unsafe` (one of which affects the parallel compiler) and
makes the remaining code easier to read.

Auto merge of #90645 - terrarier2111:master, r=estebank

Implement diagnostic for String conversion

This is my first real contribution to rustc, any feedback is highly appreciated.
This should fix https://github.com/rust-lang/rust/issues/89856

Thanks to `@estebank` for guiding me.

feedback

suggest `&str.chars()` on attempt to `&str.iter()`

check if `String` or `&String` or `&str`

Update compiler/rustc_typeck/src/check/method/suggest.rs

Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
remove some trailing whitespace

Auto merge of #90684 - jyn514:dist-aliases, r=Mark-Simulacrum

Change paths for `dist` command to match the components they generate

Before, you could have the confusing situation where the command to
generate a component had no relation to the name of that component (e.g.
the `rustc` component was generated with `src/librustc`). This changes
the name to make them match up.

Don't run the codegen test when `debug_assert` is enabled

expand comment

Auto merge of #88282 - Neutron3529:patch-4, r=Mark-Simulacrum

Optimize BinaryHeap::extend from Vec

This improves the performance of extending `BinaryHeap`s from vectors directly. Future work may involve extending this optimization to other, similar, cases where the length of the added elements is well-known, but this is not yet done in this PR.

fix getting the discriminant of a zero-variant enum

require full validity when determining the discriminant of a value