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

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.

Add some teams to prioritization exclude_labels

r? @Mark-Simulacrum @LeSeulArtichaut

Improve E0599 explanation

r? @Dylan-DPC

Allow using `Self::` in doc

Closes #70802

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

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

Replace sets with lists.

rustllvm: Fix warnings about unused function parameters

And then perform corresponding cleanups on Rust side.

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

Add fast-path optimization for Ipv4Addr::fmt

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

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

Clean up E0593 explanation

r? @Dylan-DPC

Clean up E0590 explanation

r? @Dylan-DPC

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

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

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

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.

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).

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

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

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

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

Some renaming and minor refactoring for `NativeLibraryKind`

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?

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.

remove broken link

Not sure why this is broken @Marwes

clarify interaction of pin drop guarantee and panics

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

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.

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

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

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

fix discriminant_value sign extension

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

Fix anchor display when hovering impl

A little gif for the fixed behaviour:

![hover-anchor](https://user-images.githubusercontent.com/3050060/82549808-cfdf4080-9b5d-11ea-9495-2b1d90b2a791.gif)

r? @kinnison

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

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