Rollup merge of #94220 - GuillaumeGomez:miniz-oxide-decl, r=Amanieu

Correctly handle miniz_oxide extern crate declaration

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

Follow-up of https://github.com/rust-lang/rust/pull/94122.

The `miniz_oxide` dependency is optional and therefore should allow be "imported" when it makes sense.

r? `@ivmarkov`

Rollup merge of #94215 - lcnr:leak-check, r=jackh726

trait system: comments and small nonfunctional changes

r? `@nikomatsakis` because of the leak-check check removal

Rollup merge of #94211 - est31:let_else_destructuring_error, r=matthewjasper

Better error if the user tries to do assignment ... else

If the user tries to do assignment ... else, we now issue a more comprehensible error in the parser.

closes #93995

Rollup merge of #94203 - RalfJung:to_sized_int, r=oli-obk

CTFE engine: Scalar: expose size-generic to_(u)int methods

This matches the size-generic constructors `Scalar::from_(u)int`, and it would have helped in https://github.com/rust-lang/miri/pull/1978.

r? `@oli-obk`

Rollup merge of #94190 - bjorn3:less_filetime, r=Mark-Simulacrum

Use Metadata::modified instead of FileTime::from_last_modification_ti…

…me in run_cargo

Metadata::modified works in all platforms supported by the filetime
crate. This changes brings rustbuild a tiny bit closer towards dropping
the filetime dependency.

Rollup merge of #94189 - GuillaumeGomez:scalar-lower-hex, r=RalfJung

Implement LowerHex on Scalar to clean up their display in rustdoc

Follow-up of https://github.com/rust-lang/rust/pull/94091.

r? ````@RalfJung````

Rollup merge of #94186 - ehuss:pin-stable-1.61, r=m-ou-se

Update pin_static_ref stabilization version.

#93580 slipped into 1.61

cc `@m-ou-se`

Rollup merge of #94156 - tmiasko:pp-str, r=petrochenkov

Gracefully handle non-UTF-8 string slices when pretty printing

Fixes #78520.

Rollup merge of #94143 - est31:let_else_const_eval, r=lcnr

rustc_const_eval: 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 PR handles rustc_const_eval.

Rollup merge of #91192 - r00ster91:futuredocs, r=GuillaumeGomez

Some improvements to the async docs

The goal here is to make the docs overall a little bit more comprehensive and add more links between the things.

One thing that's not working yet is the links to the keywords. Somehow I couldn't get them to work.

r? ````@GuillaumeGomez```` do you know how I could get the keyword links to work?

Correctly handle miniz_oxide extern crate declaration

Auto merge of #94205 - Mark-Simulacrum:revert-93800, r=oli-obk

Revert #93800, fixing CI time regression

This reverts commit a240ccd81c74c105b6f5fe84c46f8d36edb7e306 (merge commit of #93800), reversing
changes made to 393fdc10483da930cdbb00eabc3635030d2e776f.

This PR was likely responsible for a relatively large regression in
dist-x86_64-msvc-alt builder times, from approximately 1.7 to 2.8 hours,
bringing that builder into the pool of the slowest builders we currently have.

This seems to be limited to the alt builder due to needing parallel-compiler
enabled, likely leading to slow LLVM compilation for some reason. See some
investigation in [this Zulip stream](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/msvc.28.3F.29.20builders.20running.20much.20slower).

cc `@lcnr` `@oli-obk` `@b-naber` (per original PRs review/author)

We can re-apply this PR once the regression is fixed, but it is sufficiently large that I don't think keeping this on master is viable in the meantime unless there's a very strong case to be made for it. Alternatively, we can disable that builder (it's not critical since it's an alt build), but that obviously carries its own costs.

obligation forest docs

don't check for the leak_check twice

Auto merge of #94108 - compiler-errors:just-confirmation-normalization, r=jackh726

Normalize obligation and expected trait_refs in confirm_poly_trait_refs

Consolidate normalization the obligation and expected trait refs in `confirm_poly_trait_refs`. Also, _always_ normalize these trait refs -- we were already normalizing the obligation trait ref when confirming closure and generator candidates, but this does it for fn pointer confirmation as well.

This presumably does more work in the case that the obligation's trait ref is already normalized, but we can see from the perf runs in #94070, it actually (paradoxically, perhaps) improves performance when paired with logic that normalizes projections in fulfillment loop.

rename function

add comment

Better error if the user tries to do assignment ... else

Fix typo

Co-authored-by: lcnr <rust@lcnr.de>

Auto merge of #94066 - Mark-Simulacrum:factor-out-simple-def-kind, r=davidtwco

Remove SimpleDefKind

Now that rustc_query_system depends on rustc_hir, we can just directly make use of the regular DefKind.

Revert "Auto merge of #93800 - b-naber:static-initializers-mir-val, r=oli-obk"

This reverts commit a240ccd81c74c105b6f5fe84c46f8d36edb7e306, reversing
changes made to 393fdc10483da930cdbb00eabc3635030d2e776f.

This PR was likely responsible for a relatively large regression in
dist-x86_64-msvc-alt builder times, from approximately 1.7 to 2.8 hours,
bringing that builder into the pool of the slowest builders we currently have.

This seems to be limited to the alt builder due to needing parallel-compiler
enabled, likely leading to slow LLVM compilation for some reason.

CTFE engine: Scalar: expose size-generic to_(u)int methods

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.

Use Metadata::modified instead of FileTime::from_last_modification_time in run_cargo

Metadata::modified works in all platforms supported by the filetime
crate. This changes brings rustbuild a tiny bit closer towards dropping
the filetime dependency.

Implement LowerHex on Scalar to clean up their display in rustdoc

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.

Update pin_static_ref stabilization version.

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
```

Gracefully handle non-UTF-8 string slices when pretty printing

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`

Bless up

Consolidate normalization in confirm_poly_trait_refs

Bump version to 1.61

Fix codegen test for MSVC

rustc_typeck: adopt let else in more places

Adopt let else in more places

Some improvements to the async docs

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

rustc_const_eval: adopt let else in more places

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