Delete read_enum_variant names

Delete Decoder::read_enum

Remove support for JSON deserialization to Rust

This is no longer used by the compiler itself, and removing this support opens
the door to massively simplifying the Decodable/Decoder API by dropping the
self-describing deserialization support (necessary for JSON).

Auto merge of #93678 - steffahn:better_unsafe_diagnostics, r=nagisa

Improve `unused_unsafe` lint

I’m going to add some motivation and explanation below, particularly pointing the changes in behavior from this PR.

_Edit:_ Looking for existing issues, looks like this PR fixes #88260.

_Edit2:_ Now also contains code that closes #90776.

Improve `unused_unsafe` lint

Main motivation: Fixes some issues with the current behavior. This PR is
more-or-less completely re-implementing the unused_unsafe lint; it’s also only
done in the MIR-version of the lint, the set of tests for the `-Zthir-unsafeck`
version no longer succeeds (and is thus disabled, see `lint-unused-unsafe.rs`).

On current nightly,
```rs
unsafe fn unsf() {}

fn inner_ignored() {
    unsafe {
        #[allow(unused_unsafe)]
        unsafe {
            unsf()
        }
    }
}
```

doesn’t create any warnings. This situation is not unrealistic to come by, the
inner `unsafe` block could e.g. come from a macro. Actually, this PR even
includes removal of one unused `unsafe` in the standard library that was missed
in a similar situation. (The inner `unsafe` coming from an external macro hides
    the warning, too.)

The reason behind this problem is how the check currently works:
* While generating MIR, it already skips nested unsafe blocks (i.e. unsafe
  nested in other unsafe) so that the inner one is always the one considered
  unused
* To differentiate the cases of no unsafe operations inside the `unsafe` vs.
  a surrounding `unsafe` block, there’s some ad-hoc magic walking up the HIR to
  look for surrounding used `unsafe` blocks.

There’s a lot of problems with this approach besides the one presented above.
E.g. the MIR-building uses checks for `unsafe_op_in_unsafe_fn` lint to decide
early whether or not `unsafe` blocks in an `unsafe fn` are redundant and ought
to be removed.
```rs
unsafe fn granular_disallow_op_in_unsafe_fn() {
    unsafe {
        #[deny(unsafe_op_in_unsafe_fn)]
        {
            unsf();
        }
    }
}
```
```
error: call to unsafe function is unsafe and requires unsafe block (error E0133)
  --> src/main.rs:13:13
   |
13 |             unsf();
   |             ^^^^^^ call to unsafe function
   |
note: the lint level is defined here
  --> src/main.rs:11:16
   |
11 |         #[deny(unsafe_op_in_unsafe_fn)]
   |                ^^^^^^^^^^^^^^^^^^^^^^
   = note: consult the function's documentation for information on how to avoid undefined behavior

warning: unnecessary `unsafe` block
  --> src/main.rs:10:5
   |
9  | unsafe fn granular_disallow_op_in_unsafe_fn() {
   | --------------------------------------------- because it's nested under this `unsafe` fn
10 |     unsafe {
   |     ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

```
Here, the intermediate `unsafe` was ignored, even though it contains a unsafe
operation that is not allowed to happen in an `unsafe fn` without an additional `unsafe` block.

Also closures were problematic and the workaround/algorithms used on current
nightly didn’t work properly. (I skipped trying to fully understand what it was
supposed to do, because this PR uses a completely different approach.)
```rs
fn nested() {
    unsafe {
        unsafe { unsf() }
    }
}
```
```
warning: unnecessary `unsafe` block
  --> src/main.rs:10:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default
```

vs

```rs
fn nested() {
    let _ = || unsafe {
        let _ = || unsafe { unsf() };
    };
}
```
```
warning: unnecessary `unsafe` block
 --> src/main.rs:9:16
  |
9 |     let _ = || unsafe {
  |                ^^^^^^ unnecessary `unsafe` block
  |
  = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/main.rs:10:20
   |
10 |         let _ = || unsafe { unsf() };
   |                    ^^^^^^ unnecessary `unsafe` block
```

*note that this warning kind-of suggests that **both** unsafe blocks are redundant*

--------------------------------------------------------------------------------

I also dislike the fact that it always suggests keeping the outermost `unsafe`.
E.g. for
```rs
fn granularity() {
    unsafe {
        unsafe { unsf() }
        unsafe { unsf() }
        unsafe { unsf() }
    }
}
```
I prefer if `rustc` suggests removing the more-course outer-level `unsafe`
instead of the fine-grained inner `unsafe` blocks, which it currently does on nightly:
```
warning: unnecessary `unsafe` block
  --> src/main.rs:10:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/main.rs:11:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsafe { unsf() }
11 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block

warning: unnecessary `unsafe` block
  --> src/main.rs:12:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
...
12 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
```

--------------------------------------------------------------------------------

Needless to say, this PR addresses all these points. For context, as far as my
understanding goes, the main advantage of skipping inner unsafe blocks was that
a test case like
```rs
fn top_level_used() {
    unsafe {
        unsf();
        unsafe { unsf() }
        unsafe { unsf() }
        unsafe { unsf() }
    }
}
```
should generate some warning because there’s redundant nested `unsafe`, however
every single `unsafe` block _does_ contain some statement that uses it. Of course
this PR doesn’t aim change the warnings on this kind of code example, because
the current behavior, warning on all the inner `unsafe` blocks, makes sense in this case.

As mentioned, during MIR building all the unsafe blocks *are* kept now, and usage
is attributed to them. The way to still generate a warning like
```
warning: unnecessary `unsafe` block
  --> src/main.rs:11:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
10 |         unsf();
11 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
   |
   = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
  --> src/main.rs:12:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
...
12 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block

warning: unnecessary `unsafe` block
  --> src/main.rs:13:9
   |
9  |     unsafe {
   |     ------ because it's nested under this `unsafe` block
...
13 |         unsafe { unsf() }
   |         ^^^^^^ unnecessary `unsafe` block
```

in this case is by emitting a `unused_unsafe` warning for all of the `unsafe`
blocks that are _within a **used** unsafe block_.

The previous code had a little HIR traversal already anyways to collect a set of
all the unsafe blocks (in order to afterwards determine which ones are unused
afterwards). This PR uses such a traversal to do additional things including logic
like _always_ warn for an `unsafe` block that’s inside of another **used**
unsafe block. The traversal is expanded to include nested closures in the same go,
this simplifies a lot of things.

The whole logic around `unsafe_op_in_unsafe_fn` is a little complicated, there’s
some test cases of corner-cases in this PR. (The implementation involves
differentiating between whether a used unsafe block was used exclusively by
operations where `allow(unsafe_op_in_unsafe_fn)` was active.) The main goal was
to make sure that code should compile successfully if all the `unused_unsafe`-warnings
are addressed _simultaneously_ (by removing the respective `unsafe` blocks)
no matter how complicated the patterns of `unsafe_op_in_unsafe_fn` being
disallowed and allowed throughout the function are.

--------------------------------------------------------------------------------

One noteworthy design decision I took here: An `unsafe` block
with `allow(unused_unsafe)` **is considered used** for the purposes of
linting about redundant contained unsafe blocks. So while
```rs

fn granularity() {
    unsafe { //~ ERROR: unnecessary `unsafe` block
        unsafe { unsf() }
        unsafe { unsf() }
        unsafe { unsf() }
    }
}
```
warns for the outer `unsafe` block,
```rs

fn top_level_ignored() {
    #[allow(unused_unsafe)]
    unsafe {
        #[deny(unused_unsafe)]
        {
            unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
            unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
            unsafe { unsf() } //~ ERROR: unnecessary `unsafe` block
        }
    }
}
```
warns on the inner ones.

Auto merge of #94062 - Mark-Simulacrum:drop-print-cfg, r=oli-obk

Move ty::print methods to Drop-based scope guards

Primary goal is reducing codegen of the TLS access for each closure, which shaves ~3 seconds of bootstrap time over rustc as a whole.

Auto merge of #93934 - rusticstuff:inline_ensure_sufficient_stack, r=estebank

Allow inlining of `ensure_sufficient_stack()`

This functions is monomorphized a lot and allowing the compiler to inline it improves instructions count and max RSS significantly in my local tests.

Auto merge of #93816 - bjorn3:rlib_metadata_first, r=nagisa

Put crate metadata first in the rlib

This should make metadata lookup faster

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

Auto merge of #93605 - notriddle:notriddle/rustdoc-html-tags-resolve, r=GuillaumeGomez

rustdoc: resolve intra-doc links when checking HTML

Similar to #86451

CC #67799

Given this test case:

```rust
#![warn(rustdoc::invalid_html_tags)]
#![warn(rustdoc::broken_intra_doc_links)]

pub struct ExistentStruct<T>(T);

/// This [test][ExistentStruct<i32>] thing!
pub struct NoError;
```

This pull request silences the following, spurious warning:

```text
warning: unclosed HTML tag `i32`
 --> test.rs:6:31
  |
6 | /// This [test][ExistentStruct<i32>] thing!
  |                               ^^^^^
  |
note: the lint level is defined here
 --> test.rs:1:9
  |
1 | #![warn(rustdoc::invalid_html_tags)]
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^
help: try marking as source code
  |
6 | /// This [test][`ExistentStruct<i32>`] thing!
  |                 +                   +

warning: 1 warning emitted
```

Auto merge of #93387 - JakobDegen:improve_partialeq, r=tmiasko

Extend uninhabited enum variant branch elimination to also affect fallthrough

The `uninhabited_enum_branching` mir opt eliminates branches on variants where the data is uninhabited. This change extends this pass to also ensure that the `otherwise` case points to a trivially unreachable bb if all inhabited variants are present in the non-otherwise branches.

I believe it was `@scottmcm` who said that LLVM eliminates some of this information in its SimplifyCFG pass. This is unfortunate, but this change should still be at least a small improvement in principle (I don't think it will show up on any benchmarks)

Auto merge of #94174 - matthiaskrgr:rollup-snyrlhy, r=matthiaskrgr

Rollup of 14 pull requests

Successful merges:

 - #93580 (Stabilize pin_static_ref.)
 - #93639 (Release notes for 1.59)
 - #93686 (core: Implement ASCII trim functions on byte slices)
 - #94002 (rustdoc: Avoid duplicating macros in sidebar)
 - #94019 (removing architecture requirements for RustyHermit)
 - #94023 (adapt static-nobundle test to use llvm-nm)
 - #94091 (Fix rustdoc const computed value)
 - #94093 (Fix pretty printing of enums without variants)
 - #94097 (Add module-level docs for `rustc_middle::query`)
 - #94112 (Optimize char_try_from_u32)
 - #94113 (document rustc_middle::mir::Field)
 - #94122 (Fix miniz_oxide types showing up in std docs)
 - #94142 (rustc_typeck: adopt let else in more places)
 - #94146 (Adopt let else in more places)

Failed merges:

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

Rollup merge of #94146 - est31:let_else, r=cjgillot

Adopt let else in more places

Continuation of #89933, #91018, #91481, #93046, #93590, #94011.

I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This is the biggest of these PRs and handles the changes outside of rustdoc, rustc_typeck, rustc_const_eval, rustc_trait_selection, which were handled in PRs #94139, #94142, #94143, #94144.

Rollup merge of #94142 - est31:let_else_typeck, r=oli-obk

rustc_typeck: adopt let else in more places

Continuation of https://github.com/rust-lang/rust/pull/89933, https://github.com/rust-lang/rust/pull/91018, https://github.com/rust-lang/rust/pull/91481, https://github.com/rust-lang/rust/pull/93046, https://github.com/rust-lang/rust/pull/93590, https://github.com/rust-lang/rust/pull/94011.

I have extended my clippy lint to also recognize tuple passing and match statements. The diff caused by fixing it is way above 1 thousand lines. Thus, I split it up into multiple pull requests to make reviewing easier. This PR handles rustc_typeck.

Rollup merge of #94122 - GuillaumeGomez:miniz-oxide-std, r=notriddle

Fix miniz_oxide types showing up in std docs

Fixes #90526.

Thanks to ```````@camelid,``````` I rediscovered `doc(masked)`, allowing us to prevent `miniz_oxide` type to show up in std docs.

r? ```````@notriddle```````

Rollup merge of #94113 - Mizobrook-kan:issue-94025, r=estebank

document rustc_middle::mir::Field

cc #94025

Rollup merge of #94112 - digama0:patch-3, r=scottmcm

Optimize char_try_from_u32

The optimization was proposed by ```````@falk-hueffner``````` in https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Micro-optimizing.20char.3A.3Afrom_u32/near/272146171,  and I simplified it a bit and added an explanation of why the optimization is correct. The generated code is 2 instructions shorter and uses 2 registers instead of 4 on x86.

Rollup merge of #94097 - pierwill:doc-rustc-middle-query, r=cjgillot

Add module-level docs for `rustc_middle::query`

Rollup merge of #94093 - tmiasko:pp-no-variants, r=oli-obk

Fix pretty printing of enums without variants

92d20c4aaddea9507f8ad37fe37c551219153bbf removed no-variants special case from `try_destructure_const` with expectation that this case would be handled gracefully when `read_discriminant` returns an error.

Alas in that case `read_discriminant` succeeds while returning a non-existing variant, so the special case is still necessary.

Fixes #94073.

r? ````@oli-obk````

Rollup merge of #94091 - GuillaumeGomez:rustdoc-const-computed-value, r=oli-obk

Fix rustdoc const computed value

Fixes #85088.

It looks like this now (instead of hexadecimal):


r? ````@oli-obk````

Rollup merge of #94023 - krasimirgg:head-llvm-use-llvm-nm, r=Mark-Simulacrum

adapt static-nobundle test to use llvm-nm

No functional changes intended.

This updates the test case to use llvm-nm instead of the system nm.
This fixes an instance over at the experimental build of rustc with HEAD LLVM:
https://buildkite.com/llvm-project/rust-llvm-integrate-prototype/builds/8380#ef6f41b5-8595-49a6-be37-0eff80e0ccb5
It is related to https://github.com/rust-lang/rust/pull/94001.

The issue is that this test uses the system nm, which may not be recent
enough to understand the update to uwtable. This replaces the test to
use the llvm-nm that should be recent enough (consistent with the LLVM
sources we use to build rustc).

Rollup merge of #94019 - hermitcore:target, r=Mark-Simulacrum

removing architecture requirements for RustyHermit

RustHermit and HermitCore is able to run on aarch64 and x86_64. In the future these operating systems will also support RISC-V. Consequently, the dependency to a specific target should be removed.

The build process of `hermit-abi` fails if the architecture isn't supported.

Rollup merge of #94002 - GuillaumeGomez:duplicated-sidebar-macro, r=notriddle

rustdoc: Avoid duplicating macros in sidebar

Fixes #93912.

cc ``````@jsha`````` (for the GUI test)
r? ``````@camelid``````

Rollup merge of #93686 - dbrgn:trim-on-byte-slices, r=joshtriplett

core: Implement ASCII trim functions on byte slices

Hi ````````@rust-lang/libs!```````` This is a feature that I wished for when implementing serial protocols with microcontrollers. Often these protocols may contain leading or trailing whitespace, which needs to be removed. Because oftentimes drivers will operate on the byte level, decoding to unicode and checking for unicode whitespace is unnecessary overhead.

This PR adds three new methods to byte slices:

- `trim_ascii_start`
- `trim_ascii_end`
- `trim_ascii`

I did not find any pre-existing discussions about this, which surprises me a bit. Maybe I'm missing something, and this functionality is already possible through other means? There's https://github.com/rust-lang/rfcs/issues/2547 ("Trim methods on slices"), but that has a different purpose.

As per the [std dev guide](https://std-dev-guide.rust-lang.org/feature-lifecycle/new-unstable-features.html), this is a proposed implementation without any issue / RFC. If this is the wrong process, please let me know. However, I thought discussing code is easier than discussing a mere idea, and hacking on the stdlib was fun.

Tracking issue: https://github.com/rust-lang/rust/issues/94035

Rollup merge of #93639 - Mark-Simulacrum:relnotes, r=Mark-Simulacrum

Release notes for 1.59

cc `@rust-lang/release`
r? `@cuviper`

Rollup merge of #93580 - m-ou-se:stabilize-pin-static-ref, r=scottmcm

Stabilize pin_static_ref.

FCP finished here: https://github.com/rust-lang/rust/issues/78186#issuecomment-1024987221

Closes #78186

Auto merge of #92911 - nbdd0121:unwind, r=Amanieu

Guard against unwinding in cleanup code

Currently the only safe guard we have against double unwind is the panic count (which is local to Rust). When double unwinds indeed happen (e.g. C++ exception + Rust panic, or two C++ exceptions), then the second unwind actually goes through and the first unwind is leaked. This can cause UB. cc rust-lang/project-ffi-unwind#6

E.g. given the following C++ code:
```c++
extern "C" void foo() {
    throw "A";
}

extern "C" void execute(void (*fn)()) {
    try {
        fn();
    } catch(...) {
    }
}
```

This program is well-defined to terminate:
```c++
struct dtor {
    ~dtor() noexcept(false) {
        foo();
    }
};

void a() {
    dtor a;
    dtor b;
}

int main() {
    execute(a);
    return 0;
}
```

But this Rust code doesn't catch the double unwind:
```rust
extern "C-unwind" {
    fn foo();
    fn execute(f: unsafe extern "C-unwind" fn());
}

struct Dtor;

impl Drop for Dtor {
    fn drop(&mut self) {
        unsafe { foo(); }
    }
}

extern "C-unwind" fn a() {
    let _a = Dtor;
    let _b = Dtor;
}

fn main() {
    unsafe { execute(a) };
}
```

To address this issue, this PR adds an unwind edge to an abort block, so that the Rust example aborts. This is similar to how clang guards against double unwind (except clang calls terminate per C++ spec and we abort).

The cost should be very small; it's an additional trap instruction (well, two for now, since we use TrapUnreachable, but that's a different issue) for each function with landing pads; if LLVM gains support to encode "abort/terminate" info directly in LSDA like GCC does, then it'll be free. It's an additional basic block though so compile time may be worse, so I'd like a perf run.

r? `@ghost`
`@rustbot` label: F-c_unwind

Auto merge of #94165 - Mark-Simulacrum:bump-version, r=Mark-Simulacrum

Bump version to 1.61

r? `@Mark-Simulacrum`

Bump version to 1.61

Fix codegen test for MSVC

rustc_typeck: adopt let else in more places

Adopt let else in more places

Fix pretty printing of enums without variants

92d20c4aaddea9507f8ad37fe37c551219153bbf removed no-variants special
case from try_destructure_const with expectation that this case would be
handled gracefully when read_discriminant returns an error.

Alas in that case read_discriminant succeeds while returning a
non-existing variant, so the special case is still necessary.

Add rustdoc test for const computed value

Don't render Const computed values in hexadecimal for Display

Auto merge of #94148 - matthiaskrgr:rollup-jgea68f, r=matthiaskrgr

Rollup of 7 pull requests

Successful merges:

 - #92902 (Improve the documentation of drain members)
 - #93658 (Stabilize `#[cfg(panic = "...")]`)
 - #93954 (rustdoc-json: buffer output)
 - #93979 (Add debug assertions to validate NUL terminator in c strings)
 - #93990 (pre #89862 cleanup)
 - #94006 (Use a `Field` in `ConstraintCategory::ClosureUpvar`)
 - #94086 (Fix ScalarInt to char conversion)

Failed merges:

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

Rollup merge of #94086 - tmiasko:char-try-from-scalar-int, r=davidtwco

Fix ScalarInt to char conversion

to avoid panic for invalid Unicode scalar values

Rollup merge of #94006 - pierwill:upvar-field, r=nikomatsakis

Use a `Field` in `ConstraintCategory::ClosureUpvar`

As part of #90317, we do not want `HirId` to implement `Ord`, `PartialOrd`. This line of code has made that difficult

https://github.com/rust-lang/rust/blob/1b27144afc77031ba9c05d86c06c64485589775a/compiler/rustc_borrowck/src/region_infer/mod.rs#L2184

since it sorts a [`ConstraintCategory::ClosureUpvar(HirId)`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/enum.ConstraintCategory.html#variant.ClosureUpvar).

This PR makes that variant take a [`Field`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/mir/struct.Field.html) instead.

r? `@nikomatsakis`

Rollup merge of #93990 - lcnr:pre-89862-cleanup, r=estebank

pre #89862 cleanup

changes used in #89862 which can be landed without the rest of this PR being finished.

r? `@estebank`

Rollup merge of #93979 - SUPERCILEX:debug_check, r=dtolnay

Add debug assertions to validate NUL terminator in c strings

The `unchecked` variants from the stdlib usually perform the check anyway if debug assertions are on (for example, `unwrap_unchecked`). This PR does the same thing for `CStr` and `CString`, validating the correctness for the NUL byte in debug mode.

Rollup merge of #93954 - aDotInTheVoid:json-buffer, r=Mark-Simulacrum

rustdoc-json: buffer output

It turns out we were doing syscalls for each part of the json syntax

Before:
```
...
[pid 1801267] write(5, "\"", 1)         = 1
[pid 1801267] write(5, ",", 1)          = 1
[pid 1801267] write(5, "\"", 1)         = 1
...
```

After:

```
[pid 1974821] write(5, "{\"root\":\"0:0\",\"crate_version\":nu"..., 1575) = 1575
```

In one benchmark (one struct, almost all time in `std`), this gives ~2x perf

r? `@CraftSpider`

`@rustbot` modify labels: +A-rustdoc-json +T-rustdoc -A-testsuite

Rollup merge of #93658 - cchiw:issue-77443-fix, r=joshtriplett

Stabilize `#[cfg(panic = "...")]`

[Stabilization PR](https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr) for #77443

Rollup merge of #92902 - ssomers:docter_drain, r=yaahc

Improve the documentation of drain members

hopefully fixes #92765

Auto merge of #94105 - 5225225:destabilise-entry-insert, r=Mark-Simulacrum

Destabilise entry_insert

See: https://github.com/rust-lang/rust/pull/90345

I didn't revert the rename that was done in that PR, I left it as `entry_insert`.

Additionally, before that PR, `VacantEntry::insert_entry` seemingly had no stability attribute on it? I kept the attribute, just made it an unstable one, same as the one on `Entry`.

There didn't seem to be any mention of this in the RELEASES.md, so I don't think there's anything for me to do other than this?

Auto merge of #94134 - matthiaskrgr:rollup-b132kjz, r=matthiaskrgr

Rollup of 10 pull requests

Successful merges:

 - #89892 (Suggest `impl Trait` return type when incorrectly using a generic return type)
 - #91675 (Add MemTagSanitizer Support)
 - #92806 (Add more information to `impl Trait` error)
 - #93497 (Pass `--test` flag through rustdoc to rustc so `#[test]` functions can be scraped)
 - #93814 (mips64-openwrt-linux-musl: correct soft-foat)
 - #93847 (kmc-solid: Use the filesystem thread-safety wrapper)
 - #93877 (asm: Allow the use of r8-r14 as clobbers on Thumb1)
 - #93892 (Only mark projection as ambiguous if GAT substs are constrained)
 - #93915 (Implement --check-cfg option (RFC 3013), take 2)
 - #93953 (Add the `known-bug` test directive, use it, and do some cleanup)

Failed merges:

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

Collections: improve the documentation of drain members

Auto merge of #94050 - michaelwoerister:fix-unsized-tuple-debuginfo, r=pnkfelix

debuginfo: Support fat pointers to unsized tuples.

This PR makes fat pointer debuginfo generation handle the case of unsized tuples.

Fixes #93871

Rollup merge of #93953 - jackh726:known_bug, r=Mark-Simulacrum

Add the `known-bug` test directive, use it, and do some cleanup

cc rust-lang/compiler-team#476

Now tests can be annotated with `known-bug`, which should indicate that the test *should* pass (or at least that the current output is a bug). Adding it relaxes the requirement to add error annotations to the test (though it is still allowed). In the future, this could be extended with further relaxations - with the goal to make adding these tests need minimal effort.

I've used this attribute for the GAT tests added in #93757.

Finally, I've also cleaned up `header.rs` in compiletest a bit, by extracting out a bit of common logic. I've also split out some of the directives into their own consts. This removes a lot of very similar functions from `Config` and makes `TestProps::load_from` read nicer.

I've split these into separate commits, so I in theory could split these into separate PRs if they're controversial, but I think they're pretty straightforward.

r? ``@Mark-Simulacrum``

Rollup merge of #93915 - Urgau:rfc-3013, r=petrochenkov

Implement --check-cfg option (RFC 3013), take 2

This pull-request implement RFC 3013: Checking conditional compilation at compile time (https://github.com/rust-lang/rfcs/pull/3013) and is based on the previous attempt https://github.com/rust-lang/rust/pull/89346 by `@mwkmwkmwk` that was closed due to inactivity.

I have address all the review comments from the previous attempt and added some more tests.

cc https://github.com/rust-lang/rust/issues/82450
r? `@petrochenkov`

Rollup merge of #93892 - compiler-errors:issue-92917, r=jackh726,nikomatsakis

Only mark projection as ambiguous if GAT substs are constrained

A slightly more targeted version of #92917, where we only give up with ambiguity if we infer something about the GATs substs when probing for a projection candidate.

fixes #93874
also note (but like the previous PR, does not fix) #91762

r? `@jackh726`
cc `@nikomatsakis` who reviewed #92917

Rollup merge of #93877 - Amanieu:asm_fixes, r=nagisa

asm: Allow the use of r8-r14 as clobbers on Thumb1

Previously these were entirely disallowed, except for r11 which was allowed by accident.

cc `@hudson-ayers`

Rollup merge of #93847 - solid-rs:fix-kmc-solid-fs-ts, r=yaahc

kmc-solid: Use the filesystem thread-safety wrapper

Fixes the thread unsafety of the `std::fs` implementation used by the [`*-kmc-solid_*`](https://doc.rust-lang.org/nightly/rustc/platform-support/kmc-solid.html) Tier 3 targets.

Neither the SOLID filesystem API nor built-in filesystem drivers guarantee thread safety by default. Although this may suffice in general embedded-system use cases, and in fact the API can be used from multiple threads without any problems in many cases, this has been a source of unsoundness in `std::sys::solid::fs`.

This commit updates the implementation to leverage the filesystem thread-safety wrapper (which uses a pluggable synchronization mechanism) to enforce thread safety. This is done by prefixing all paths passed to the filesystem API with `\TS`. (Note that relative paths aren't supported in this platform.)

Rollup merge of #93814 - Itus-Shield:mips64-openwrt, r=bjorn3

mips64-openwrt-linux-musl: correct soft-foat

MIPS64 targets under OpenWrt require soft-float fpu support.

Rust-lang requires soft-float defined in tuple definition and
isn't over-ridden by toolchain compile-time CFLAGS/LDFLAGS

Set explicit soft-float for tuple.

Signed-off-by: Donald Hoskins <grommish@gmail.com>

Rollup merge of #93497 - willcrichton:rustdoc-scrape-test, r=GuillaumeGomez

Pass `--test` flag through rustdoc to rustc so `#[test]` functions can be scraped

As a part of stabilizing the scrape examples extension in Cargo, I uncovered a bug where examples cannot be scraped from tests. See this test: https://github.com/rust-lang/cargo/pull/10343/files#diff-27aa4f012ebfebaaee61498d91d2370de460628405d136b05e77efe61e044679R2496

The issue is that when rustdoc is run on a test file, because `--test` is not passed as a rustc option, then functions annotated with `#[test]` are ignored by the compiler. So this PR changes rustdoc so when `--test` is passed in conjunction with a `--scrape-example-<suffix>` flag, then the `test` field of `rustc_interface::Config` is true.

r? `@camelid`

Rollup merge of #92806 - compiler-errors:better-impl-trait-deny, r=estebank

Add more information to `impl Trait` error

Fixes #92458

Let me know if I went overboard here, or if the suggestions could use some refinement.

r? `@estebank`
Feel free to reassign to someone else

Rollup merge of #91675 - ivanloz:memtagsan, r=nagisa

Add MemTagSanitizer Support

Add support for the LLVM [MemTagSanitizer](https://llvm.org/docs/MemTagSanitizer.html).

On hardware which supports it (see caveats below), the MemTagSanitizer can catch bugs similar to AddressSanitizer and HardwareAddressSanitizer, but with lower overhead.

On a tag mismatch, a SIGSEGV is signaled with code SEGV_MTESERR / SEGV_MTEAERR.

# Usage

`-Zsanitizer=memtag -C target-feature="+mte"`

# Comments/Caveats

* MemTagSanitizer is only supported on AArch64 targets with hardware support
* Requires `-C target-feature="+mte"`
* LLVM MemTagSanitizer currently only performs stack tagging.

# TODO

* Tests
* Example

Rollup merge of #89892 - Nilstrieb:suggest-return-impl-trait, r=jackh726

Suggest `impl Trait` return type when incorrectly using a generic return type

Address #85991

When there is a type mismatch error and the return type is generic, and that generic parameter is not used in the function parameters, suggest replacing that generic with the `impl Trait` syntax.

r? `@estebank`

Release notes for 1.59

asm: Allow the use of r8-r14 as clobbers on Thumb1

Previously these were entirely disallowed, except for r11 which was
allowed by accident.

Suggest `impl Trait` return type

Address #85991

Suggest the `impl Trait` return type syntax if the user tried to return a generic parameter and we get a type mismatch

The suggestion is not emitted if the param appears in the function parameters, and only get the bounds that actually involve `T: ` directly

It also checks whether the generic param is contained in any where bound (where it isn't the self type), and if one is found (like `Option<T>: Send`), it is not suggested.

This also adds `TyS::contains`, which recursively vistits the type and looks if the other type is contained anywhere

Auto merge of #94121 - matthiaskrgr:rollup-6ps95da, r=matthiaskrgr

Rollup of 6 pull requests

Successful merges:

 - #92683 (Suggest copying trait associated type bounds on lifetime error)
 - #92933 (Deny mixing bin crate type with lib crate types)
 - #92959 (Add more info and suggestions to use of #[test] on invalid items)
 - #93024 (Do not ICE when inlining a function with un-satisfiable bounds)
 - #93613 (Move `{core,std}::stream::Stream` to `{core,std}::async_iter::AsyncIterator`)
 - #93634 (compiler: clippy::complexity fixes)

Failed merges:

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

Fix miniz_oxide types showing up in std

Rollup merge of #93634 - matthiaskrgr:clippy_complexity_jan_2022, r=oli-obk

compiler: clippy::complexity fixes

useless_format
map_flatten
useless_conversion
needless_bool
filter_next
clone_on_copy
needless_option_as_deref

Rollup merge of #93613 - crlf0710:rename_to_async_iter, r=yaahc

Move `{core,std}::stream::Stream` to `{core,std}::async_iter::AsyncIterator`

Following amendments in https://github.com/rust-lang/rfcs/pull/3208/.

cc #79024
cc ``@yoshuawuyts`` ``@joshtriplett``

Rollup merge of #93024 - compiler-errors:inline-mir-bad-bounds, r=estebank

Do not ICE when inlining a function with un-satisfiable bounds

Fixes #93008
This is kinda a hack... but it's the fix I thought had the least blast-radius.

We use `normalize_param_env_or_error` to verify that the predicates in the param env are self-consistent, since with RevealAll, a bad predicate like `<&'static () as Clone>` will be evaluated with an empty ParamEnv (since it references no generics), and we'll raise an error for it.

Rollup merge of #92959 - asquared31415:test-non-fn-help, r=estebank

Add more info and suggestions to use of #[test] on invalid items

This pr changes the diagnostics for using `#[test]` on an item that can't be used as a test to explain that the attribute has no meaningful effect on non-functions and suggests the use of `#[cfg(test)]` for conditional compilation instead.

Example change:
```rs
#[test]
mod test {}
```
previously output
```
error: only functions may be used as tests
 --> src/lib.rs:2:1
  |
2 | mod test {}
  | ^^^^^^^^^^^
  ```
  now outputs
  ```
error: the `#[test]` attribute may only be used on a non-associated function
  --> $DIR/test-on-not-fn.rs:3:1
     |
LL | #[test]
     | ^^^^^^^
LL | mod test {}
     | ----------- expected a non-associated function, found a module
     |
     = note: the `#[test]` macro causes a a function to be run on a test and has no effect on non-functions
help: replace with conditional compilation to make the item only exist when tests are being run
     |
LL | #[cfg(test)]
     | ~~~~~~~~~~~~
   ```

Rollup merge of #92933 - bjorn3:no_bin_lib_mixing, r=estebank

Deny mixing bin crate type with lib crate types

The produced library would get a main shim too which conflicts with the
main shim of the executable linking the library.

```
$ cat > main1.rs <<EOF
fn main() {}
pub fn bar() {}
EOF
$ cat > main2.rs <<EOF
extern crate main1;
fn main() {
    main1::bar();
}
EOF
$ rustc --crate-type bin --crate-type lib main1.rs
$ rustc -L. main2.rs
error: linking with `cc` failed: exit status: 1
[...]
  = note: /usr/bin/ld: /tmp/crate_bin_lib/libmain1.rlib(main1.main1.707747aa-cgu.0.rcgu.o): in function `main':
          main1.707747aa-cgu.0:(.text.main+0x0): multiple definition of `main'; main2.main2.02a148fe-cgu.0.rcgu.o:main2.02a148fe-cgu.0:(.text.main+0x0): first defined here
          collect2: error: ld returned 1 exit status
```

Rollup merge of #92683 - jackh726:issue-92033, r=estebank

Suggest copying trait associated type bounds on lifetime error

Closes #92033

Kind of the most simple suggestion to make - we don't try to be fancy. Turns out, it's still pretty useful (the couple existing tests that trigger this error end up fixed - for this error - upon applying the fix).

r? ``@estebank``
cc ``@nikomatsakis``

Add test checking that fallthrough branches are correctly identified as dead

Extend uninhabited match branch optimization to also work on fallthrough.

The `uninhabited_enum_branch` miropt now also checks whether the fallthrough
case is inhabited, and if not will ensure that it points to an unreachable
block.

Put crate metadata first in the rlib when possible

This should make metadata lookup faster

Auto merge of #93766 - petrochenkov:doclinkregr, r=camelid,GuillaumeGomez

rustdoc: Collect traits in scope for lang items

Inherent impls on primitive types are not included in the list of all inherent impls in the crate (`inherent_impls_in_crate_untracked`), they are taken from the list of lang items instead, but such impls can also be inlined by rustdoc, e.g. if something derefs to a primitive type.

r? `@camelid`
Fixes https://github.com/rust-lang/rust/issues/93698

rustdoc: Collect traits in scope for lang items

fix some typos

Auto merge of #94088 - oli-obk:revert, r=jackh726

Revert #91403

fixes #94004

r? `@pnkfelix` `@cjgillot`

fix

document rustc_middle::mir::Field

Optimize char_try_from_u32

The optimization was proposed by @falk-hueffner in https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Micro-optimizing.20char.3A.3Afrom_u32/near/272146171,  and I simplified it a bit and added an explanation of why the optimization is correct.

Auto merge of #94095 - Amanieu:update_stdarch, r=dtolnay

Fix documentation for is_X_feature_detected!

These are now properly documented for all architectures and the
stability attributes in the docs are now correctly displayed.

This addresses this comment by `@ehuss:` https://github.com/rust-lang/rust/pull/90271#issuecomment-1038400916

cc `@adamgemmell`

fix impl trait message, bless tests

Add more information to `impl Trait` deny error

Auto merge of #94103 - matthiaskrgr:rollup-cd70ofn, r=matthiaskrgr

Rollup of 9 pull requests

Successful merges:

 - #93337 (Update tracking issue numbers for inline assembly sub-features)
 - #93758 (Improve comments about type folding/visiting.)
 - #93780 (Generate list instead of div items in sidebar)
 - #93976 (Add MAIN_SEPARATOR_STR)
 - #94011 (Even more let_else adoptions)
 - #94041 (Add a `try_collect()` helper method to `Iterator`)
 - #94043 (Fix ICE when using Box<T, A> with pointer sized A)
 - #94082 (Remove CFG_PLATFORM)
 - #94085 (Clippy: Don't lint `needless_borrow` in method receiver positions)

Failed merges:

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

Destabilise entry_insert

Rollup merge of #94085 - flip1995:clippy_needless_borrow_temp_fix, r=Manishearth

Clippy: Don't lint `needless_borrow` in method receiver positions

r? `@Manishearth`

cc `@camsteffen` `@Jarcho`

cc rust-lang/rust-clippy#8441

Let's get this fix in before the beta branching tomorrow.

Rollup merge of #94082 - bjorn3:remove_cfg_platform, r=Mark-Simulacrum

Remove CFG_PLATFORM

It seems to be unused and it is incorrect for arm/aarch64 anyway.

Rollup merge of #94043 - DrMeepster:box_alloc_ice, r=oli-obk

Fix ICE when using Box<T, A> with pointer sized A

Fixes #78459

Note that using `Box<T, A>` with a more than pointer sized `A` or using a pointer sized `A` with a Box of a DST will produce a different ICE (#92054) which is not fixed by this PR.

Rollup merge of #94041 - a-lafrance:try-collect, r=scottmcm

Add a `try_collect()` helper method to `Iterator`

Implement `Iterator::try_collect()` as a helper around `Iterator::collect()` as discussed [here](https://internals.rust-lang.org/t/idea-fallible-iterator-mapping-with-try-map/15715/5?u=a.lafrance).

First time contributor so definitely open to any feedback about my implementation! Specifically wondering if I should open a tracking issue for the unstable feature I introduced.

As the main participant in the internals discussion: r? `@scottmcm`

Rollup merge of #94011 - est31:let_else, r=lcnr

Even more let_else adoptions

Continuation of #89933, #91018, #91481, #93046, #93590.

Rollup merge of #93976 - SUPERCILEX:separator_str, r=yaahc

Add MAIN_SEPARATOR_STR

Currently, if someone needs access to the path separator as a str, they need to go through this mess:

```rust
unsafe {
    std::str::from_utf8_unchecked(slice::from_ref(&(MAIN_SEPARATOR as u8)))
}
```

This PR just re-exports an existing path separator str API.

Rollup merge of #93780 - GuillaumeGomez:links-in-sidebar, r=jsha

Generate list instead of div items in sidebar

Fixes #92986.

Surprisingly, we didn't have much CSS for this...

[Demo](https://rustdoc.crud.net/imperio/links-in-sidebar/std/index.html).

r? `@jsha`

Rollup merge of #93758 - nnethercote:improve-folding-comments, r=BoxyUwU

Improve comments about type folding/visiting.

I have found this code confusing for years. I've always roughly
understood it, but never exactly. I just made my fourth(?) attempt and
finally cracked it.

This commit improves the comments. In particular, it explicitly
describes how you can't do a custom fold/visit of any type; there are
actually a handful of "types of interest" (e.g. `Ty`, `Predicate`,
`Region`, `Const`) that can be custom folded/visted, and all other types
just get a generic traversal. I think this was the part that eluded me
on all my prior attempts at understanding.

The commit also updates comments to account for some newer changes such
as the fallible/infallible folding distinction, does some minor
reorderings, and moves one `impl` to a better place.

r? `@BoxyUwU`

Rollup merge of #93337 - Amanieu:asm_tracking, r=tmiasko

Update tracking issue numbers for inline assembly sub-features

The main tracking issue for inline assembly is [closed](https://github.com/rust-lang/rust/issues/72016#issuecomment-1022332954), further tracking of the remaining sub-features has been moved to separate tracking issues.

core: Implement trim functions on byte slices

Co-authored-by: Jubilee Young <workingjubilee@gmail.com>

Suggest copying trait associated type bounds on lifetime error

Add module-level docs for `rustc_middle::query`

Fix documentation for is_X_feature_detected!

These are now properly documented for all architectures and the
stability attributes in the docs are now correctly displayed.

Revert "Auto merge of #91403 - cjgillot:inherit-async, r=oli-obk"

This reverts commit 3cfa4def7c87d571bd46d92fed608edf8fad236e, reversing
changes made to 5d8767cb229b097fedb1dd4bd9420d463c37774f.

Fix ScalarInt to char conversion

to avoid panic for invalid Unicode scalar values

Don't lint `needless_borrow` in method receiver positions

Remove CFG_PLATFORM

It seems to be unused and it is incorrect for arm/aarch64 anyway.

Auto merge of #93577 - nikic:llvm-14, r=nagisa

Upgrade to LLVM 14

LLVM patch state:
 * [x] https://github.com/llvm/llvm-project/commit/a55727f334b39600bfc71144b11b42aae6b94e0b Backported.
 * [x] https://github.com/rust-lang/llvm-project/commit/c3c82dc12402dd41441180c0c6cf7aed7e330c53 Backported as https://github.com/llvm/llvm-project/commit/917c47b3bf0dfc45a2a5ba12c1397d647ecf4017.
 * [x] https://github.com/rust-lang/llvm-project/commit/6e8f9ab632d12271355d10d34c9835a7ba14e4b9 No plan to upstream.
 * [x] https://github.com/llvm/llvm-project/commit/319f4b2d52e31b000db75a0a2484b5f2ab90534a Backported.
 * [x] https://github.com/rust-lang/llvm-project/commit/8b2c25d321f877161f85218479e2d1317d770e18 No plan to upstream.
 * [x] https://github.com/rust-lang/llvm-project/commit/75fef2efd427362c8f16b2d09e6ebf44069e3919 No plan to upstream.
 * [ ] https://github.com/rust-lang/llvm-project/commit/adef757547de5a570d9f6a00d3e6ac16c666ab79 Upstreamed as https://github.com/llvm/llvm-project/commit/2d2ef384b2f6e723edb793d08f52e7f4dc94ba3a. Needs backport.
 * [x] https://github.com/rust-lang/llvm-project/commit/4b7c1b4910e9fa9e04f23f06be078e168ef4c0ee No plan to upstream.
 * [x] https://github.com/rust-lang/llvm-project/commit/3f5ab0c061adb723f25b94243828b6b5407720c8 No plan to upstream.
 * [x] https://github.com/rust-lang/llvm-project/commit/514d05500e0e15e358f05f5c4cec78a805858f8e No plan to upstream.
 * [ ] https://github.com/rust-lang/llvm-project/commit/54c586958564582b3341d1838a5de86541e5fecf Under review at https://reviews.llvm.org/D119695 and https://reviews.llvm.org/D119856.

Release timeline:
 * LLVM 14.0.0 final planned for Mar 15.
 * Rust 1.60.0 planned for Apr 7.

Compile-time:
  * https://perf.rust-lang.org/compare.html?start=250384edc5d78533e993f38c60d64e42b21684b2&end=b87df8d2c7c5d9ac448c585de10927ab2ee1b864
  * A slight improvement on average, though no big changes either way.
  * There are some larger max-rss improvements.

r? `@ghost`