Rollup of 10 pull requests

Successful merges:

 - #87052 (Optimize fmt::PadAdapter::wrap)
 - #87522 (Fix assert in diy_float)
 - #87553 (Fix typo in rustc_driver::version)
 - #87554 (2229: Discr should be read when PatKind is Range)
 - #87564 (min_type_alias_impl_trait is going to be removed in 1.56)
 - #87574 (Update the examples in `String` and `VecDeque::retain`)
 - #87583 (Refactor compression cache in v0 symbol mangler)
 - #87585 (Add missing links for core::char types)
 - #87594 (fs File get_path procfs usage for netbsd same as linux.)
 - #87602 ([backtraces]: look for the `begin` symbol only after seeing `end`)

Failed merges:

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

[backtraces]: look for the `begin` symbol only after seeing `end`

On `x86_64-pc-windows-msvc`, we often get backtraces which look like
    this:

    ```
    10:     0x7ff77e0e9be5 - std::panicking::rust_panic_with_hook
    11:     0x7ff77e0e11b4 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5769736bdb11136c
    12:     0x7ff77e0e116f - std::sys_common::backtrace::__rust_end_short_backtrace::h61c7ecb1b55338ae
    13:     0x7ff77e0f89dd - std::panicking::begin_panic::h8e60ef9f82a41805
    14:     0x7ff77e0e108c - d
    15:     0x7ff77e0e1069 - c
    16:     0x7ff77e0e1059 - b
    17:     0x7ff77e0e1049 - a
    18:     0x7ff77e0e1039 - core::ptr::drop_in_place<std::rt::lang_start<()>::{{closure}}>::h1bfcd14d5e15ba81
    19:     0x7ff77e0e1186 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5769736bdb11136c
    20:     0x7ff77e0e100c - std::rt::lang_start::{{closure}}::ha054184bbf9921e3
    ```

Notice that `__rust_begin_short_backtrace` appears on frame 11 before
    `__rust_end_short_backtrace` on frame 12. This is because in typical
    release binaries without debug symbols, dbghelp.dll, which we use to walk
    and symbolize the stack, does not know where CGU internal functions
    start or end and so the closure invoked by `__rust_end_short_backtrace`
    is incorrectly described as `__rust_begin_short_backtrace` because it
    happens to be near that symbol.

While that can obviously change, this has been happening quite
    consistently since #75048. Since this is a very small change to the std
    and the change makes sense by itself, I think this is worth doing.

This doesn't completely resolve the situation for release binaries on
    Windows, since without debug symbols, the stack printed can still show
    incorrect symbol names (this is why the test uses `#[no_mangle]`) but it
    does slightly improve the situation in that you see the same backtrace
    you would see with `RUST_BACKTRACE=full` or in a debugger (without the
    uninteresting bits at the top and bottom).

Fixes part of #87481

fs File get_path procfs usage for netbsd same as linux.

Add missing links for core::char types

Refactor compression cache in v0 symbol mangler

* Remove redundant option around compression caches (they are always present).
* Flatten compression caches into symbol mangler to avoid dynamic memory allocation.
* Implement printer for `&mut SymbolMangler` instead of `SymbolMangler` to avoid passing now slightly larger symbol mangler by value.

Update the examples in `String` and `VecDeque::retain`

The examples added in #60396 used a "clever" post-increment hack,
unrelated to the actual point of the examples. That hack was found
[confusing] in the users forum, and #81811 already changed the `Vec`
example to use a more direct iterator. This commit changes `String` and
`VecDeque` in the same way for consistency.

[confusing]: https://users.rust-lang.org/t/help-understand-strange-expression/62858

min_type_alias_impl_trait is going to be removed in 1.56

#87501 removed `min_type_alias_impl_trait` but meanwhile that PR was approved in homu queue, a new beta was cut so we need to bump the version because it won't be removed in 1.55.

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

```@bors``` rollup=always

2229: Discr should be read when PatKind is Range

This PR fixes an issue related to pattern matching in closures when Edition 2021 is enabled.

- If any of the patterns the discr is being matched on is `PatKind::Range` then the discr should be read

r? ```@nikomatsakis```

Closes https://github.com/rust-lang/rust/issues/87426

Fix typo in rustc_driver::version

This caused rustc `-Zcodegen-backend=foo.so -vV` to look for `oo.so` instead of `foo.so`

Fix assert in diy_float

The shifting should have gone the other way, the current incarnation is always true.

Optimize fmt::PadAdapter::wrap

After adding the first `write!` usage to my project and printing the result to the console, I noticed, that my binary contains the strings "called `Option::unwrap()` on a `None` value`" and more importantly "C:\Users\Patrick Fischer\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\core\src\fmt\builders.rs", with my release build being configured as follows:
```
[profile.release]
panic = "abort"
codegen-units = 1
strip = "symbols" # the important bit
lto = true
```
I am in a no_std environment and my custom panic handler is a simple `loop {}`. I did not expect the above information to be preserved. I heavily suspect the edited function to be the culprit. It contains the only direct use of `Option::unwrap` in the entire file and I tracked the symbols in the assembly to be used from the section `_ZN68_$LT$core..fmt..builders..PadAdapter$u20$as$u20$core..fmt..Write$GT$9write_str17ha1d5e5efe167202aE`.

Aside from me suspecting this function to be the culprit, the replaced code performs the same operation as `Option::insert`, but without the `unreachable_unchecked` optimization `Option::insert` provides. Therefore, it makes sense to me to use the more optimized version, instead.

As I don't change any semantics, I hope a simple pull request suffices.

Mir borrowck does not generate lifetime variables for 'static lifetimes during opaque type resolution

Fixes #87455

This situation was unreachable before #87287 as we used to just grab the resolved opaque type from typeck and replaced all regions with new inference vars. After #87287 we let the `InferCx` in mir borrowck figure out the opaque type all by itself (which it already did before, but it only used the result to sanity check with the typeck result).

Fix may not to appropriate might not or must not

I went through and changed occurrences of `may not` to be more explicit with `might not` and `must not`.

Improve intra doc errors display

#87169

`@jyn514` This is what I had in mind to avoid having duplicated backticks. I also gave a try to simply updating the span for the suggestion/help messages but I think this current one is better because less "noisy". Anyway, that allows you to see the result. ;)

Bufwriter disassembly tweaks

In #80690 `@BurntSushi` observed that `WriterPanicked` was erroneously not exported, and suggested renaming `into_raw_parts` to `into_parts`. (More info in my commit messages.)

r? `@BurntSushi`

On `x86_64-pc-windows-msvc`, we often get backtraces which look like
this:

```
10:     0x7ff77e0e9be5 - std::panicking::rust_panic_with_hook
11:     0x7ff77e0e11b4 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5769736bdb11136c
12:     0x7ff77e0e116f - std::sys_common::backtrace::__rust_end_short_backtrace::h61c7ecb1b55338ae
13:     0x7ff77e0f89dd - std::panicking::begin_panic::h8e60ef9f82a41805
14:     0x7ff77e0e108c - d
15:     0x7ff77e0e1069 - c
16:     0x7ff77e0e1059 - b
17:     0x7ff77e0e1049 - a
18:     0x7ff77e0e1039 - core::ptr::drop_in_place<std::rt::lang_start<()>::{{closure}}>::h1bfcd14d5e15ba81
19:     0x7ff77e0e1186 - std::sys_common::backtrace::__rust_begin_short_backtrace::h5769736bdb11136c
20:     0x7ff77e0e100c - std::rt::lang_start::{{closure}}::ha054184bbf9921e3
```

Notice that `__rust_begin_short_backtrace` appears on frame 11 before
`__rust_end_short_backtrace` on frame 12. This is because in typical
release binaries without debug symbols, dbghelp.dll, which we use to walk
and symbolize the stack, does not know where CGU internal functions
start or end and so the closure invoked by `__rust_end_short_backtrace`
is incorrectly described as `__rust_begin_short_backtrace` because it
happens to be near that symbol.

While that can obviously change, this has been happening quite
consistently since #75048. Since this is a very small change to the std
and the change makes sense by itself, I think this is worth doing.

This doesn't completely resolve the situation for release binaries on
Windows, since without debug symbols, the stack printed can still show
incorrect symbol names (this is why the test uses `#[no_mangle]`) but it
does slightly improve the situation in that you see the same backtrace
you would see with `RUST_BACKTRACE=full` or in a debugger (without the
uninteresting bits at the top and bottom).

Update Clippy

r? `@Manishearth`

As requested
  https://github.com/rust-lang/rust/pull/85901#pullrequestreview-698404772Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

I looked in stdlib and as @BurntSushi thought, `raw` is generally
used for raw pointers, or other hazardous kinds of thing.  stdlib does
not have `into_parts` apart from the one I added to `IntoInnerError`.

I did an ad-hoc search of the rustdocs for my current game project
Otter, which includes quite a large number of dependencies.
`into_parts` seems heavily used for things quite like this.

So change this name.
Suggested-by: NAndrew Gallant <jamslam@gmail.com>
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

I didn't notice the submodule, which means I failed to re-export this
to make it actually-public.
Reported-by: NAndrew Gallant <jamslam@gmail.com>
Signed-off-by: NIan Jackson <ijackson@chiark.greenend.org.uk>

to avoid passing the symbol mangler by value.

The compression caches currently don't have any dedicated functionality
that would benefit from being separated. Incorporating caches directly
into the symbol manger also avoids dynamic memory allocation.

The symbol mangler, which is often passed by value, is now slightly
larger. This aspect will be addressed by a follow-up commit.

Compression caches are always present. Remove unnecessary option.

Rename two lints to comply with our lint naming convention

self_named_constructor -> self_named_constructors
append_instead_of_extend -> extend_with_drain

We don't need to `register_renamed` those lints, since I'll backport them to beta, so the old names won't hit stable.

changelog: none
(I'll adapt the changelog before merging #7498)

self_named_constructor -> self_named_constructors
append_instead_of_extend -> extend_with_drain

Add #[track_caller] for some function in core::mem.

These functions can panic for some types. This makes the panic point to the code that calls e.g. mem::uninitialized(), instead of inside the definition of mem::uninitialized.

Rustup

r? `@ghost`

changelog: none

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

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

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

r? `@RalfJung`