Rollup merge of #72446 - dtolnay:ord, r=petrochenkov

Impl Ord for proc_macro::LineColumn

```rust
impl Ord for LineColumn {...}
impl PartialOrd for LineColumn {...}
```

for https://doc.rust-lang.org/nightly/proc_macro/struct.LineColumn.html.

The ordering is the natural one you would get by writing one line after another, where we compare line first, then compare columns within the same line.

Rollup merge of #72431 - RalfJung:ub-warning, r=shepmaster

add warning sign to UB examples

Just to make it less likely that people miss the fact that these are examples for how to *not* do it.

Rollup merge of #72292 - ldm0:derefsteps, r=estebank

Replace obligation construction with deref_steps()

1. Use `probe()` to avoid unwanted binding committing during `deref_steps()`.
2. Fixes #59819 again by using `deref_steps()`, make the code cleaner. And if we want to suggest multiple dereferences (like: `consider dereferencing the borrow: "****a"`) in the future, this change will make it easier to achieve.

add warning sign to UB examples

Auto merge of #72478 - Dylan-DPC:rollup-vval8du, r=Dylan-DPC

Rollup of 7 pull requests

Successful merges:

 - #71289 (Allow using `Self::` in doc)
 - #72375 (Improve E0599 explanation)
 - #72385 (Add some teams to prioritization exclude_labels)
 - #72395 (Allow rust-highfive to label issues it creates.)
 - #72453 (Add flag to open docs:  x.py doc --open)
 - #72459 (Add core::future::IntoFuture)
 - #72461 (Clean up E0600 explanation)

Failed merges:

r? @ghost

Auto merge of #72256 - ecstatic-morse:once-cell, r=Mark-Simulacrum

Use `once_cell` crate instead of custom data structure

Internally, we use the [`Once`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_data_structures/sync/struct.Once.html) type for shared data that is initialized exactly once and only read from afterwards. `Once` uses a `parking_lot::Mutex` when the parallel compiler is enabled and a `RefCell` when it is not. This PR switches to the [`once_cell`](https://crates.io/crates/once_cell) crate, which also uses a `parking_lot::Mutex` for its `sync` version (because we enable the `parking_lot` feature) but has zero overhead for its `unsync` one.

This PR adds `once_cell` to the list of whitelisted dependencies. I think this is acceptable because it is already used in `rustc_driver`, is owned by a well-known community member (cc @matklad), and has a stable release. cc @rust-lang/compiler

`once_cell` has a slightly more minimal API than `Once`, which allows for initialization to be either optimistic (evaluate the initializer and then synchronize) or pessimistic (synchronize and then evaluate the initializer). `once_cell`'s `get_or_init` is always pessimistic. The optimistic version is only used once in the current `master`.

r? @Mark-Simulacrum

Switch to non-doc comment

Use `OnceCell` for predecessor cache

Use `OnceCell` instead of `Once`

Replace `rustc_data_structures::sync::Once` with `OnceCell`

Rollup merge of #72461 - GuillaumeGomez:cleanup-e0600, r=Dylan-DPC

Clean up E0600 explanation

r? @Dylan-DPC

Rollup merge of #72459 - yoshuawuyts:into-future, r=nikomatsakis

Add core::future::IntoFuture

This patch reintroduces the `core::future::IntoFuture` trait. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering since that lead to performance regressions. By introducing the trait separately from the integration, the integration PR can be more narrowly scoped, and people can start trying out the `IntoFuture` trait today. Thanks heaps!

cc/ @rust-lang/wg-async-foundations

## References
- Original PR adding `IntoFuture` https://github.com/rust-lang/rust/pull/65244
- Open issue to re-land `IntoFuture` (assigned to me) https://github.com/rust-lang/rust/issues/67982
- Tracking issue for `IntoFuture` https://github.com/rust-lang/rust/issues/67644

Rollup merge of #72453 - dtolnay:open, r=Mark-Simulacrum

Add flag to open docs:  x.py doc --open

This aligns with Cargo's flag `cargo doc --open`.

Tested with:

```bash
   # opens doc/index.html
x.py doc --stage 0 --open
x.py doc --stage 0 --open src/doc

   # opens doc/book/index.html
x.py doc --stage 0 --open src/doc/book

   # opens doc/std/index.html
x.py doc --stage 0 --open src/libstd

   # opens doc/proc_macro/index.html
x.py doc --stage 0 --open src/libproc_macro

   # opens both
x.py doc --stage 0 --open src/libstd src/libproc_macro
```

Rollup merge of #72395 - Elinvynia:highfive, r=Mark-Simulacrum

Allow rust-highfive to label issues it creates.

This is my first meaningful PR, I am unsure how to test this code so any pointers would be welcome!

I am about 50% sure it works.

Rollup merge of #72385 - spastorino:add-exclude-labels, r=Mark-Simulacrum

Add some teams to prioritization exclude_labels

r? @Mark-Simulacrum @LeSeulArtichaut

Rollup merge of #72375 - GuillaumeGomez:cleanup-e0599, r=Dylan-DPC

Improve E0599 explanation

r? @Dylan-DPC

Rollup merge of #71289 - xliiv:70802-intra-self, r=GuillaumeGomez

Allow using `Self::` in doc

Closes #70802

Report error from opener in bootstrap

On my machine, an error looks like:

    Finished release [optimized] target(s) in 0.29s
    Opening doc /git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html
    command 'xdg-open (internal)' did not execute successfully; exit code: 4
    command stderr:
    gio: file:///git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html: Error when getting information for file “/git/rust/build/x86_64-unknown-linux-gnu/doc/std/index.html”: No such file or directory

    Build completed successfully in 0:00:08

Auto merge of #72464 - RalfJung:rollup-xhm7w7u, r=RalfJung

Rollup of 7 pull requests

Successful merges:

 - #71829 (Fix suggestion to borrow in struct)
 - #72123 (Stabilize process_set_argv0 feature for Unix)
 - #72235 (Clean up E0590 explanation)
 - #72345 (Clean up E0593 explanation)
 - #72376 ([self-profling] Record the cgu name when doing codegen for a module)
 - #72399 (Add fast-path optimization for Ipv4Addr::fmt)
 - #72435 (rustllvm: Fix warnings about unused function parameters)

Failed merges:

r? @ghost

Allow rust-highfive to label issues it creates.

Replace sets with lists.

Rollup merge of #72435 - petrochenkov:cratetypesopt, r=Mark-Simulacrum

rustllvm: Fix warnings about unused function parameters

And then perform corresponding cleanups on Rust side.

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

Rollup merge of #72399 - Lucretiel:ipv4-display-fast, r=kennytm

Add fast-path optimization for Ipv4Addr::fmt

Don't use an intermediary buffer when writing an IPv4 address without any specific alignment options

Rollup merge of #72376 - wesleywiser:record_cgu_name, r=Mark-Simulacrum

[self-profling] Record the cgu name when doing codegen for a module

Rollup merge of #72345 - GuillaumeGomez:cleanup-e0593, r=Dylan-DPC

Clean up E0593 explanation

r? @Dylan-DPC

Rollup merge of #72235 - GuillaumeGomez:cleanup-E0590, r=Dylan-DPC

Clean up E0590 explanation

r? @Dylan-DPC

Rollup merge of #72123 - jsgf:stabilize-arg0, r=sfackler

Stabilize process_set_argv0 feature for Unix

This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.

The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.

Tracking issue: #66510

Rollup merge of #71829 - kper:issue71136, r=matthewjasper

Fix suggestion to borrow in struct

The corresponding issue is #71136.
The compiler suggests that borrowing `the_foos` might solve the problem. This is obviously incorrect.
```
struct Foo(u8);

#[derive(Clone)]
struct FooHolster {
    the_foos: Vec<Foo>,
}
```

I propose as fix to check if there is any colon in the span. However, there might a case where `my_method(B { a: 1, b : foo })` would be appropriate to show a suggestion for `&B ...`.  To fix that too, we can simply check if there is a bracket in the span. This is only possible because both spans are different.
Issue's span: `the_foos: Vec<Foo>`
other's span: `B { a : 1, b : foo }`

Allow using `Self::` in doc

Clean up E0590 explanation

Clean up E0600 explanation

Auto merge of #72460 - RalfJung:rollup-28fs06y, r=RalfJung

Rollup of 4 pull requests

Successful merges:

 - #71610 (InvalidUndefBytes: Track size of undef region used)
 - #72161 (Replace fcntl-based file lock with flock)
 - #72306 (Break tokens before checking if they are 'probably equal')
 - #72325 (Always generated object code for `#![no_builtins]`)

Failed merges:

r? @ghost

Rollup merge of #72325 - alexcrichton:ignore-linker-plugin-lto, r=nnethercote

Always generated object code for `#![no_builtins]`

This commit updates the code generation for `#![no_builtins]` to always
produce object files instead of conditionally respecting
`-Clinker-plugin-lto` and sometimes producing bitcode. This is intended
to address rust-lang/cargo#8239.

The issue at hand here is that Cargo has tried to get "smarter" about
codegen in whole crate graph scenarios. When LTO is enabled it attempts
to avoid codegen on as many crates as possible, opting to pass
`-Clinker-plugin-lto` where it can to only generate bitcode. When this
is combined with `-Zbuild-std`, however, it means that
`compiler-builtins` only generates LLVM bitcode instead of object files.
Rustc's own LTO passes then explicitly skip `compiler-builtins` (because
it wouldn't work anyway) which means that LLVM bitcode gets sent to the
linker, which chokes most of the time.

The fix in this PR is to not actually respect `-Clinker-plugin-lto` for
`#![no_builtins]` crates. These crates, even if slurped up by the linker
rather than rustc, will not work with LTO. They define symbols which are
only referenced as part of codegen, so LTO's aggressive internalization
would trivially remove the symbols only to have the linker realize later
that the symbol is undefined. Since pure-bitcode never makes sense for
these libraries, the `-Clinker-plugin-lto` flag is silently ignored.

Rollup merge of #72306 - Aaron1011:feature/turbo-spacing, r=petrochenkov

Break tokens before checking if they are 'probably equal'

Fixes #68489
Fixes #70987

When checking two `TokenStreams` to see if they are 'probably equal',
we ignore the `IsJoint` information associated with each `TokenTree`.
However, the `IsJoint` information determines whether adjacent tokens
will be 'glued' (if possible) when construction the `TokenStream` - e.g.
`[Gt Gt]` can be 'glued' to `BinOp(Shr)`.

Since we are ignoring the `IsJoint` information, 'glued' and 'unglued'
tokens are equivalent for determining if two `TokenStreams` are
'probably equal'. Therefore, we need to 'unglue' all tokens in the
stream to avoid false negatives (which cause us to throw out the cached
tokens, losing span information).

Rollup merge of #72161 - nbdd0121:master, r=cuviper

Replace fcntl-based file lock with flock

WSL1 does not support `fcntl`-based lock and will always report success,
therefore creating a race condition when multiple rustc processes are
modifying shared data such as `search-index.js`. WSL1 does however
support `flock`.

`flock` is supported by all unix-like platforms. The only caveat is that
Linux 2.6.11 or earlier does not support `flock` on NFS mounts, but as
the minimum supported Linux version is 2.6.18, it is not an issue.

Fixes #72157

Rollup merge of #71610 - divergentdave:InvalidUndefBytes-range, r=RalfJung

InvalidUndefBytes: Track size of undef region used

This PR adds a size to `UndefinedBehaviorInfo::InvalidUndefBytes`, to keep track of how many undefined bytes in a row were accessed, and changes a few methods to pass this information through. This additional information will eventually be used in Miri to improve diagnostics for this UB error. See also rust-lang/miri#1354 for prior discussion.

I expect Miri will break the next time its submodule is updated, due to this change to the `InvalidUndefBytes`. (The current commit for src/tools/miri predates rust-lang/miri#1354, and thus does not try to destructure the `InvalidUndefBytes` variant) I have a corresponding change prepared for that repository.

r? @RalfJung

Add core::future::IntoFuture

This patch adds `core::future::IntoFuture`. However unlike earlier PRs this patch does not integrate it into the `async/.await` lowering. That integration should be done in a follow-up PR.

Using `!span.from_expansion()` instead of snippets

Auto merge of #72458 - RalfJung:rollup-g1w1vws, r=RalfJung

Rollup of 6 pull requests

Successful merges:

 - #71607 (clarify interaction of pin drop guarantee and panics)
 - #72125 (remove broken link)
 - #72133 (Add target thumbv7a-uwp-windows-msvc)
 - #72304 (rustc_target: Avoid an inappropriate use of `post_link_objects`)
 - #72309 (Some renaming and minor refactoring for `NativeLibraryKind`)
 - #72438 (Enable ARM TME (Transactional Memory Extensions))

Failed merges:

r? @ghost

Rollup merge of #72438 - vertexclique:vcq/aarch64-tme-features, r=Amanieu

Enable ARM TME (Transactional Memory Extensions)

Enables ARM TME coming up with LLVM 10. Related ARM TME intrinsics are included by the merge of #67900.

Enables: https://github.com/rust-lang/stdarch/pull/855

Rollup merge of #72309 - petrochenkov:linkunspec, r=matthewjasper

Some renaming and minor refactoring for `NativeLibraryKind`

Rollup merge of #72304 - petrochenkov:sgxunwind, r=nikomatsakis,jethrogb,dingelish

rustc_target: Avoid an inappropriate use of `post_link_objects`

It isn't supposed to be used for linking libraries.
Also linking libunwind unconditionally (and not together with the `src/libunwind` crate) is suspicious.

@jethrogb @VardhanThigle
Could you verify that it works as expected?

Rollup merge of #72133 - bdbai:master, r=joshtriplett

Add target thumbv7a-uwp-windows-msvc

Add target spec for thumbv7a-uwp-windows-msvc, so that libraries written in Rust will have a chance to run on ARM-based devices with Windows 10.

So far I managed to create a proof-of-concept library for Universal Windows Platform apps to consume and it worked on a Windows Phone. However, building a standalone executable seemed troublesome due to `LLVM ERROR: target does not implement codeview register mapping` stuff (see also https://github.com/rust-lang/rust/issues/52659#issuecomment-408233322 ).

Steps to test:
1. Clone and build this version
```sh
git clone https://github.com/bdbai/rust.git
cd rust
python x.py build -i --target thumbv7a-uwp-windows-msvc --stage 1 src/libstd
rustup toolchain link arm-uwp-stage1 .\build\x86_64-pc-windows-msvc\stage1\
```
2. Create a new library crate
```sh
cargo new --lib arm-uwp-test
cd arm-uwp-test
```
3. Change `crate-type` in `Cargo.toml` to `staticlib`
```toml
[lib]
crate-type=["staticlib"]
```
4. Replace the following code in `src/lib.rs`
```rust
#[no_mangle]
pub extern "system" fn call_rust() -> i32 {
    2333
}
```
5. Build the crate
```sh
cargo +arm-uwp-stage1 build -v --target thumbv7a-uwp-windows-msvc
```
6. `arm-uwp-test.lib` should appear in `target\thumbv7a-uwp-windows-msvc\debug`

To consume this library:
1. Make sure Visual Studio 2017 and Windows 10 SDK (10.0.17134 or above) are installed
2. Create a new Blank App (C++/WinRT) in Visual Studio 2017 (Visual Studio 2019 cannot deploy UWP apps to Windows Phone)
3. Go to Property Pages, and then Linker->Input->Additional Dependencies, add `arm-uwp-test.lib` produced just now
4. Manually declare function prototypes in `MainPage.h`
```c++
extern "C" {
    int call_rust();
}
```
5. Replace the `ClickHandler` part in `MainPage.cpp`
```c++
myButton().Content(box_value(std::to_wstring(call_rust())));
```
6. Build and deploy this app to an ARM device running Windows 10. The app should run and show `2333` when the button is clicked.

Rollup merge of #72125 - tshepang:broken-link, r=nikomatsakis

remove broken link

Not sure why this is broken @Marwes

Rollup merge of #71607 - RalfJung:pin-drop-panic, r=nikomatsakis

clarify interaction of pin drop guarantee and panics

Cc https://github.com/rust-lang/unsafe-code-guidelines/issues/232
@Diggsey would this have helped?

Replace obligation construction with deref_steps()

Auto merge of #72000 - cuviper:dist-llvm, r=Mark-Simulacrum

Move the target libLLVM to llvm-tools-preview

For running the compiler, we usually only need LLVM from `$sysroot/lib`,
which rustup will make available with `LD_LIBRARY_PATH`. We've also been
shipping LLVM in the `$target/lib` directory, which bloats the download
and installed size. The only times we do need the latter are for the
RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev`
libraries. We'll move it to the `llvm-tools-preview` component directly,
and `rustc-dev` will have an implicit dependency on it.

Here are the dist sizes that I got before and after this change:

    llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz     1.3M   24M
    llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz     748K   17M
    rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz          83M    61M
    rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz          56M    41M

The installed size should reduce by exactly one `libLLVM.so` (~70-80M),
unless you also install `llvm-tools`, and then it should be identical.

Resolves #70838.

Add flag to open docs:  x.py doc --open

Tested with:

       # opens doc/index.html
    x.py doc --stage 0 --open
    x.py doc --stage 0 --open src/doc

       # opens doc/book/index.html
    x.py doc --stage 0 --open src/doc/book

       # opens doc/std/index.html
    x.py doc --stage 0 --open src/libstd

       # opens doc/proc_macro/index.html
    x.py doc --stage 0 --open src/libproc_macro

       # opens both
    x.py doc --stage 0 --open src/libstd src/libproc_macro

Auto merge of #71956 - ecstatic-morse:remove-requires-storage-analysis, r=tmandry

Clean up logic around live locals in generator analysis

Resolves #69902. Requires #71893.

I've found it difficult to make changes in the logic around live locals in `generator/transform.rs`. It uses a custom dataflow analysis, `MaybeRequiresStorage`, that AFAICT computes whether a local is either initialized or borrowed. That analysis is using `before` effects, which we should try to avoid if possible because they are harder to reason about than ones only using the unprefixed effects. @pnkfelix has suggested removing "before" effects entirely to simplify the dataflow framework, which I might pursue someday.

This PR replaces `MaybeRequiresStorage` with a combination of the existing `MaybeBorrowedLocals` and a new `MaybeInitializedLocals`. `MaybeInitializedLocals` is just `MaybeInitializedPlaces` with a coarser resolution: it works on whole locals instead of move paths. As a result, I was able to simplify the logic in `compute_storage_conflicts` and `locals_live_across_suspend_points`.

This is not exactly equivalent to the old logic; some generators are now smaller than before. I believe this was because the old logic was too conservative, but I'm not as familiar with the constraints as the original implementers were, so I could be wrong. For example, I don't see a reason the size of the `mixed_sizes` future couldn't be 5K. It went from 7K to 6K in this PR.

r? @jonas-schievink @tmandry

Add test for proc_macro::LineColumn

Impl Ord for proc_macro::LineColumn

Auto merge of #72433 - RalfJung:rollup-srft8nx, r=RalfJung

Rollup of 7 pull requests

Successful merges:

 - #72055 (Intern predicates)
 - #72149 (Don't `type_of` on trait assoc ty without default)
 - #72347 (Make intra-link resolve links for both trait and impl items)
 - #72350 (Improve documentation of `slice::from_raw_parts`)
 - #72382 (Show default values for debug-assertions & debug-assertions-std)
 - #72421 (Fix anchor display when hovering impl)
 - #72425 (fix discriminant_value sign extension)

Failed merges:

r? @ghost

Enable ARM TME (Transactional Memory Extensions)

Add some teams to prioritization exclude_labels

Rollup merge of #72425 - RalfJung:discr-sign-ext, r=nikomatsakis

fix discriminant_value sign extension

Fixes a regression introduced in https://github.com/rust-lang/rust/pull/70705
r? @nikomatsakis Cc @lcnr @oli-obk

Rollup merge of #72421 - GuillaumeGomez:fix-impl-hover-anchor, r=kinnison

Fix anchor display when hovering impl

A little gif for the fixed behaviour:


r? @kinnison

Rollup merge of #72382 - tmiasko:config-toml-debug-assertions, r=nikomatsakis

Show default values for debug-assertions & debug-assertions-std

Rollup merge of #72350 - danielhenrymantilla:doc_warn_against_adjacent_slice_concat, r=RalfJung

Improve documentation of `slice::from_raw_parts`

This is to provide a more explicit statement against a code pattern that
many people end up coming with, since the reason of it being unsound
comes from the badly known single-allocation validity rule.

Providing that very pattern as a counter-example could help mitigate that.

See also: https://internals.rust-lang.org/t/pre-rfc-add-join-seq-method-to-slices-and-strs/11936/13

r? @RalfJung

Rollup merge of #72347 - xliiv:72340-impl-for-default, r=GuillaumeGomez

Make intra-link resolve links for both trait and impl items

Closes #72340

Rollup merge of #72149 - estebank:icemation, r=eddyb

Don't `type_of` on trait assoc ty without default

Fix #72076.

Rollup merge of #72055 - lcnr:predicate-kind, r=nikomatsakis

Intern predicates

Implements the first step of https://github.com/rust-lang/compiler-team/issues/285

Renames `ty::Predicate` to `ty::PredicateKind`, which is now interned.
To ease the transition, `ty::Predicate` is now a struct containing a reference
to `ty::PredicateKind`.

r? @ghost

rustllvm: Fix warnings about unused function parameters

Auto merge of #71930 - Nadrieril:exhaustiveness-remove-tyerr, r=varkor

De-abuse TyKind::Error in exhaustiveness checking

Replaces https://github.com/rust-lang/rust/pull/71074. Context: https://github.com/rust-lang/rust/issues/70866.

In order to remove the use of `TyKind::Error`, I had to make sure we skip over those fields whose inhabitedness should not be observed. This is potentially error-prone however, since we must be careful not to mix filtered and unfiltered lists of patterns. I managed to hide away most of the filtering behind a new `Fields` struct, that I used everywhere relevant. I quite like the result; I think the twin concepts of `Constructor` and `Fields` make a good mental model.

As usual, I tried to separate commits that shuffle code around from commits that require more thought to review.

cc @varkor @Centril

Typo

Improve documentation of `slice::from_raw_parts`

This is to provide a more explicit statement against a code pattern that
many people end up coming with, since the reason of it being unsound
comes from the badly known single-allocation validity rule.

Providing that very pattern as a counter-example could help mitigate that.

Co-authored-by: Ralf Jung <post@ralfj.de>

Auto merge of #71718 - NeoRaider:ffi_const_pure, r=Amanieu

Experimentally add `ffi_const` and `ffi_pure` extern fn attributes

Add FFI function attributes corresponding to clang/gcc/... `const` and `pure`.

Rebased version of #58327 by @gnzlbg with the following changes:

- Switched back from the `c_ffi_const` and `c_ffi_pure` naming to `ffi_const` and `ffi_pure`, as I agree with https://github.com/rust-lang/rust/pull/58327#issuecomment-462718772 and this nicely aligns with `ffi_returns_twice`
- (Hopefully) took care of all of @hanna-kruppe's change requests in the original PR

r? @hanna-kruppe

fix discriminant sign extension

Auto merge of #72422 - RalfJung:rollup-u81z4mw, r=RalfJung

Rollup of 7 pull requests

Successful merges:

 - #71854 (Make `std::char` functions and constants associated to `char`.)
 - #72111 (rustc-book: Document `-Z strip=val` option)
 - #72272 (Fix going back in history to a search result page on firefox)
 - #72296 (Suggest installing VS Build Tools in more situations)
 - #72365 (Remove unused `StableHashingContext::node_to_hir_id` method)
 - #72371 (FIX - Char documentation for unexperienced users)
 - #72397 (llvm: Expose tiny code model to users)

Failed merges:

r? @ghost

Rollup merge of #72397 - petrochenkov:tiny, r=Amanieu

llvm: Expose tiny code model to users

This model is relevant to embedded AArch64 targets and was added to LLVM relatively recently (https://reviews.llvm.org/D49673, mid 2018), so rustc frontend didn't provide access to it with `-C code-model`. The gcc analogue is [`-mcmodel=tiny`](https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html).
(This is one of the options that are passed directly to LLVM without being interpreted by rustc.)

Follow up to https://github.com/rust-lang/rust/pull/72248.

Rollup merge of #72371 - Elrendio:char_documentation, r=steveklabnik

FIX - Char documentation for unexperienced users

This is my first PR on rust and even if I've read [CONTRIBUTING.md](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests) I'm ensure everything is perfect. Sorry if I didn't follow the exact procedure.

**What it does:**
- Add an example in the char documentation

**Explanation**
Unexperienced users might not know that punctuation is `Case_Ignorable` and not `Uppercase` and `Lowercase` which mean that when checking if a string is uppercase one might be tempted to write:
```rust
my_string.chars().all(char::is_uppercase)
```

However this will return false for `"HELLO WORLD"` which is not intuitive. Since the function `is_case_ignorable` doesn't exists I believe the correct way to check is:
```rust
!my_string.chars().any(char::is_lowercase)
```

The aim of this example is to prevent unexperienced users to make an error which punctuation chars.

Rollup merge of #72365 - marmeladema:remove-node_to_hir_id, r=ecstatic-morse

Remove unused `StableHashingContext::node_to_hir_id` method

cc #50928

Rollup merge of #72296 - ChrisDenton:msvc-link-check, r=petrochenkov

Suggest installing VS Build Tools in more situations

When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be [impenetrable](https://pastebin.com/MRMCr7HM) to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.

This only applies when Microsoft's link tool is expected.

Rollup merge of #72272 - GuillaumeGomez:fix-back-on-page-with-search-behaviour, r=kinnison

Fix going back in history to a search result page on firefox

This bug was actually firefox not re-running JS script when you go back in history. To trigger it on the current docs:

 * Make a search
 * Pick an element (which isn't on the same page as the current element!)
 * Go back in history

Instead of having the search results, you'll see the normal doc page. You can find a small explanation about it [here](http://web.archive.org/web/20100428053932/http://www.firefoxanswer.com/firefox/672-firefoxanswer.html).

r? @kinnison

cc @ollie27

Rollup merge of #72111 - petrochenkov:docstrip, r=ehuss

rustc-book: Document `-Z strip=val` option

cc https://github.com/rust-lang/rust/issues/72110

Rollup merge of #71854 - eduardosm:assoc-char-funcs-and-consts, r=Amanieu

Make `std::char` functions and constants associated to `char`.

First step to fix https://github.com/rust-lang/rust/issues/71763.

Fix anchor display when hovering impl

Auto merge of #72205 - ecstatic-morse:nrvo, r=oli-obk

Dumb NRVO

This is a very simple version of an NRVO pass, which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place, we bail out. This avoids running a full "reaching definitions" dataflow analysis.

I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges.

r? @ghost

Bail out if new return place has different type than old

Auto merge of #70705 - lcnr:generic_discriminant, r=nikomatsakis

Use `T`'s discriminant type in `mem::Discriminant<T>` instead of `u64`.

fixes #70509

Adds the lang-item `discriminant_kind`.
Updates the function signature of `intrinsics::discriminant_value`.
Adds the *probably permanently unstable* trait `DiscriminantKind`.
`mem::Discriminant` should now be smaller in some cases.

r? @ghost

Comment flock usage on Linux

Move the target libLLVM to llvm-tools-preview

For running the compiler, we usually only need LLVM from `$sysroot/lib`,
which rustup will make available with `LD_LIBRARY_PATH`. We've also been
shipping LLVM in the `$target/lib` directory, which bloats the download
and installed size. The only times we do need the latter are for the
RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev`
libraries. We'll move it to the `llvm-tools-preview` component directly,
and `rustc-dev` will have an implicit dependency on it.

Here are the dist sizes that I got before and after this change:

    llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz     1.3M   24M
    llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz     748K   17M
    rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz          83M    61M
    rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz          56M    41M

The installed size should reduce by exactly one `libLLVM.so` (~70-80M),
unless you also install `llvm-tools`, and then it should be identical.

Auto merge of #67759 - nikic:llvm-10, r=Mark-Simulacrum

Update to LLVM 10

LLVM 10 is going to be branched soon, so it's a good time to start finding all those tasty new miscompiles and performance regressions ;)

Status:

 * Preparation split off into #67900.
 * Optimization regressions:
   * [x] https://bugs.llvm.org/show_bug.cgi?id=44419 => https://reviews.llvm.org/D72048 has landed.
   * [x] https://bugs.llvm.org/show_bug.cgi?id=44423 => https://reviews.llvm.org/D72060 has landed.
   * [x] https://reviews.llvm.org/D72169 submitted.
   * [ ] https://bugs.llvm.org/show_bug.cgi?id=44461 reported. https://reviews.llvm.org/D72420 submitted, but unlikely eligible for LLVM 10.
 * Compile-time regressions:
   * [x] GlobalOpt regression identified. ~~fhahn proposed https://reviews.llvm.org/D72214.~~ fhahn has [reverted](https://github.com/llvm/llvm-project/commit/192cce10f67e4f22be6d9b8c0975f78ad246d1bd) the patch.
   * [ ] Even with the revert, there are [large regressions](https://perf.rust-lang.org/compare.html?start=760ce94c69ca510d44087291c311296f6d9ccdf5&end=4e84f97d76e694bb9f59039f5bdeb6d8bca46d14).
 * Assertion failures / infinite loops:
   * [x] https://bugs.llvm.org/show_bug.cgi?id=44600 => https://reviews.llvm.org/D73135, https://reviews.llvm.org/D73854 and https://reviews.llvm.org/D73908 have landed and been cherry-picked to the 10.x branch.
   * [x] https://bugs.llvm.org/show_bug.cgi?id=44835 => https://reviews.llvm.org/D74278 has landed and been cherry-picked.

Add fast-path optimization for Ipv4Addr::fmt

llvm: Expose tiny code model to users

Fix tests

Auto merge of #72378 - Dylan-DPC:rollup-m87bp2d, r=Dylan-DPC

Rollup of 6 pull requests

Successful merges:

 - #71863 (Suggest fixes and add error recovery for `use foo::self`)
 - #72139 (Make `fold` standalone.)
 - #72275 (Continue lowering for unsupported async generator instead of returning an error.)
 - #72361 (split_inclusive: add tracking issue number (72360))
 - #72364 (Remove unused dependencies)
 - #72366 (Adjust the zero check in `RawVec::grow`.)

Failed merges:

r? @ghost

Eliminate some `Option<NativeLibKind>`s

Factor out `NativeLibKind::Dylib` from `NativeLibKind::Unspecified`

Rename some types describing native libraries

NativeLibrary(Kind) -> NativeLib(Kind)
NativeStatic -> StaticBundle
NativeStaticNobundle -> StaticNoBundle
NativeFramework -> Framework
NativeRawDylib -> RawDylib
NativeUnknown -> Unspecified

rustc_target: Avoid an inappropriate use of `post_link_objects`

Set CMAKE_CXX_STANDARD when compiling LLD

Update LLVM submodule

Auto merge of #72384 - mati865:ci-fix, r=pietroalbini

Workaround MSYS2/chocolatey issue again

Workaround MSYS2/chocolatey issue again

Show default values for debug-assertions & debug-assertions-std

Suggest installing VS Build Tools in more situations

When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be impenetrable to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.

This only applies when Microsoft's link tool is expected. Not `lld-link` or other MSVC compatible linkers.

ptr eq for `Predicate`

change `Predicate::kind` to return a reference

intern `PredicateKind`

introduce newtype'd `Predicate<'tcx>`

make `to_predicate` take a `tcx` argument