This implements support for applying PGO to the rustc compilation step (not
standard library or any tooling, including rustdoc). Expanding PGO to more tools
is not terribly difficult but will involve more work and greater CI time
commitment.

For the same reason of avoiding greater time commitment, this currently avoids
implementing for platforms outside of x86_64-unknown-linux-gnu, though in
practice it should be quite simple to extend over time to more platforms. The
initial implementation is intentionally minimal here to avoid too much work
investment before we start seeing wins for a subset of Rust users.

The choice of workloads to profile here is somewhat arbitrary, but the general
rationale was to aim for a small set that largely avoided time regressions on
perf.rust-lang.org's full suite of crates. The set chosen is libcore, cargo (and
its dependencies), and a few ad-hoc stress tests from perf.rlo. The stress tests
are arguably the most controversial, but they benefit those cases (avoiding
regressions) and do not really remove wins from other benchmarks.

The primary next step after this PR lands is to implement support for PGO in
LLVM. It is unclear whether we can afford a full LLVM rebuild in CI, though, so
the approach taken there may need to be more staggered. rustc-only PGO seems
well affordable on linux at least, giving us up to 20% wall time wins on some
crates for 15 minutes of extra CI time (1 hour up from 45 minutes).

The PGO data is uploaded to allow others to reuse it if attempting to reproduce
the CI build or potentially, in the future, on other platforms where an
off-by-one strategy is used for dist builds at minimal performance cost.

bootstrap: include llvm-dwp in CI LLVM

Fixes #80086.

This PR includes the `llvm-dwp` tool in the CI LLVM (which rustc developers can download instead of building LLVM locally) - `llvm-dwp` is required by Split DWARF which landed in PR #77117.

r? `@Mark-Simulacrum`

This commit includes the `llvm-dwp` tool in the CI LLVM (which rustc
developers can download instead of building LLVM locally) - `llvm-dwp`
is required by Split DWARF which landed in PR #77117.
Signed-off-by: NDavid Wood <david@davidtw.co>

cg_llvm: split dwarf support

cc #34651

This PR adds initial support for Split DWARF to rustc, based on the implementation in Clang.

##### Current Status
This PR currently has functioning split-dwarf, running rustc with `-Zsplit-dwarf=split` when compiling a binary will produce a `dwp` alongside the binary, which contains the linked dwarf objects.

```shell-session
$ rustc -Cdebuginfo=2 -Zsplit-dwarf=split -C save-temps ./foo.rs
$ ls foo*
foo
foo.belfx9afw9cmv8.rcgu.dwo
foo.belfx9afw9cmv8.rcgu.o
foo.foo.7rcbfp3g-cgu.0.rcgu.dwo
foo.foo.7rcbfp3g-cgu.0.rcgu.o
foo.foo.7rcbfp3g-cgu.1.rcgu.dwo
foo.foo.7rcbfp3g-cgu.1.rcgu.o
foo.foo.7rcbfp3g-cgu.2.rcgu.dwo
foo.foo.7rcbfp3g-cgu.2.rcgu.o
foo.foo.7rcbfp3g-cgu.3.rcgu.dwo
foo.foo.7rcbfp3g-cgu.3.rcgu.o
foo.foo.7rcbfp3g-cgu.4.rcgu.dwo
foo.foo.7rcbfp3g-cgu.4.rcgu.o
foo.foo.7rcbfp3g-cgu.5.rcgu.dwo
foo.foo.7rcbfp3g-cgu.5.rcgu.o
foo.foo.7rcbfp3g-cgu.6.rcgu.dwo
foo.foo.7rcbfp3g-cgu.6.rcgu.o
foo.foo.7rcbfp3g-cgu.7.rcgu.dwo
foo.foo.7rcbfp3g-cgu.7.rcgu.o
foo.dwp
foo.rs
$ readelf -wi foo.foo.7rcbfp3g-cgu.0.rcgu.o
# ...
  Compilation Unit @ offset 0x90:
   Length:        0x2c (32-bit)
   Version:       4
   Abbrev Offset: 0x5b
   Pointer Size:  8
 <0><9b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <9c>   DW_AT_stmt_list   : 0xe8
    <a0>   DW_AT_comp_dir    : (indirect string, offset: 0x13b): /home/david/Projects/rust/rust0
    <a4>   DW_AT_GNU_dwo_name: (indirect string, offset: 0x15b): foo.foo.7rcbfp3g-cgu.0.rcgu.dwo
    <a8>   DW_AT_GNU_dwo_id  : 0x357472a2b032d7b9
    <b0>   DW_AT_low_pc      : 0x0
    <b8>   DW_AT_ranges      : 0x40
    <bc>   DW_AT_GNU_addr_base: 0x0
# ...
```

##### To-Do
I've opened this PR as a draft to get feedback and work out how we'd expect rustc to work when Split DWARF is requested. It might be easier to read the PR commit-by-commit.

- [ ] Add error when Split DWARF is requested on platforms where it doesn't make sense.
- [x] Determine whether or not there should be a single `dwo` output from rustc, or one per codegen-unit as exists currently.
- [x] Add tests.
- [x] Fix `single` mode - currently single mode doesn't change the invocation of `addPassesToEmitFile`, which is correct, but it also needs to change the split dwarf path provided to `createCompileUnit` and `createTargetMachine` so that it's just the final binary (currently it is still a non-existent `dwo` file).

r? `@nagisa`
cc `@michaelwoerister` `@EddyB` `@alexcrichton` `@rust-lang/wg-incr-comp`

llvm-dwp concatenates `DW_AT_comp_dir` with `DW_AT_GNU_dwo_name` (only
when `DW_AT_comp_dir` exists), which can result in it failing to find
the DWARF object files.

In earlier testing, `DW_AT_comp_dir` wasn't present in the final
object and the current directory was the output directory.

When running tests through compiletest, the working directory of the
compilation is different from output directory and that resulted in
`DW_AT_comp_dir` being in the object file (and set to the current
working directory, rather than the output directory), and
`DW_AT_GNU_dwo_name` being set to the full path (rather than just
the filename), so llvm-dwp was failing.

This commit changes the compilation directory provided to LLVM to match
the output directory, where DWARF objects are output; and ensures that
only the filename is used for `DW_AT_GNU_dwo_name`.
Signed-off-by: NDavid Wood <david@davidtw.co>

This commit adds a Split DWARF compare mode to compiletest so that
debuginfo tests are also tested using Split DWARF in split mode (and
manually in single mode).
Signed-off-by: NDavid Wood <david@davidtw.co>

This commit adds a run-make-fulldeps test which checks that a DWARF
package file is emitted.
Signed-off-by: NDavid Wood <david@davidtw.co>

This commit makes minor changes to the cranelift backend so that it can
build given changes in cg_ssa for Split DWARF.
Signed-off-by: NDavid Wood <david@davidtw.co>

This commit implements Split DWARF support, wiring up the flag (added in
earlier commits) to the modified FFI wrapper (also from earlier
commits).
Signed-off-by: NDavid Wood <david@davidtw.co>

`llvm-dwp` is required for linking the DWARF objects into DWARF packages
when using Split DWARF, especially given that rustc produces multiple
DWARF objects (one for each codegen unit).
Signed-off-by: NDavid Wood <david@davidtw.co>

This commit removes the `TargetMachineFactory` struct and adds a
`TargetMachineFactoryFn` type alias which is used everywhere that the
previous, long type was used.
Signed-off-by: NDavid Wood <david@davidtw.co>

This commit changes some comments to documentation comments so that
they can be read on the generated rustdoc.
Signed-off-by: NDavid Wood <david@davidtw.co>

This commit adds a flag for Split DWARF, which enables debuginfo to be
split into multiple files.
Signed-off-by: NDavid Wood <david@davidtw.co>

This commit modifies the FFI bindings to LLVM required for Split DWARF
support in rustc. In particular:

- `addPassesToEmitFile`'s wrapper, `LLVMRustWriteOutputFile` now takes
  a `DwoPath` `const char*`. When disabled, `nullptr` should be provided
  which will preserve existing behaviour. When enabled, the path to the
  `.dwo` file should be provided.
- `createCompileUnit`'s wrapper, `LLVMRustDIBuilderCreateCompileUnit`
  now has two additional arguments, for the `DWOId` and to enable
  `SplitDebugInlining`. `DWOId` should always be zero.
- `createTargetMachine`'s wrapper, `LLVMRustCreateTargetMachine` has an
  additional argument which should be provided the path to the `.dwo`
  when enabled.
Signed-off-by: NDavid Wood <david@davidtw.co>

Don't look for blanket impls in intra-doc links

This never worked and has been causing severe performance problems.
Hopefully it will be re-landed at some point in the future when it
actually works, but in the meantime it makes no sense to have the code
around when it does nothing and actively makes rustdoc harder to use.

Closes https://github.com/rust-lang/rust/issues/78761. Does *not* affect https://github.com/rust-lang/rust/issues/78800.

r? `@Manishearth`
cc `@seeplusplus`

MaybeUninit::copy/clone_from_slice

This PR adds 2 new methods to MaybeUninit under the feature of `maybe_uninit_write_slice`: `copy_from_slice` and `clone_from_slice`.

These are useful for initializing uninitialized buffers (such as the one returned by `Vec::spare_capacity_mut` for example) with initialized data.

The methods behave similarly to the methods on slices, but the destination is uninitialized and they return the destination slice as an initialized slice.

Get rid of `clean::Deprecation`

This brings the size of `item.deprecation` from 56 to 16 bytes. Helps with #79103 and https://github.com/rust-lang/rust/issues/76382, in the same vein as https://github.com/rust-lang/rust/pull/79957.

r? `@GuillaumeGomez`

Refactor and fix `parse_prefix` on Windows

This PR is an extension of #78692 as well as a general refactor of `parse_prefix`:

**Fixes**:
There are two errors in the current implementation of `parse_prefix`:

Firstly, in the current implementation only `\` is recognized as a separator character in device namespace prefixes. This behavior is only correct for verbatim paths; `"\\.\C:/foo"` should be parsed as `"C:"` instead of `"C:/foo"`.

Secondly, the current implementation only handles single separator characters. In non-verbatim paths a series of separator characters should be recognized as a single boundary, e.g. the UNC path `"\\localhost\\\\\\C$\foo"` should be parsed as `"\\localhost\\\\\\C$"` and then `UNC(server: "localhost", share: "C$")`, but currently it is not parsed at all, because it starts being parsed as `\\localhost\` and then has an invalid empty share location.

Paths like `"\\.\C:/foo"` and `"\\localhost\\\\\\C$\foo"` are valid on Windows, they are equivalent to just `"C:\foo"`.

**Refactoring**:
All uses of `&[u8]` within `parse_prefix` are extracted to helper functions and`&OsStr` is used instead. This reduces the number of places unsafe is used:
- `get_first_two_components` is adapted to the more general `parse_next_component` and used in more places
- code for parsing drive prefixes is extracted to `parse_drive`

This never worked and has been causing severe performance problems.
Hopefully it will be re-landed at some point in the future when it
actually works, but in the meantime it makes no sense to have the code
around when it does nothing and actively makes rustdoc harder to use.

make MIR graphviz generation use gsgdt

gsgdt [https://crates.io/crates/gsgdt] is a crate which provides an
interface for stringly typed graphs. It also provides generation of
graphviz dot format from said graph.

This is the first in a series of PRs on moving graphviz code out of rustc into normal crates and then implementating graph diffing on top of these crates.

r? `@oli-obk`

[rustdoc] Switch to Symbol for item.name

This decreases the size of `Item` from 680 to 616 bytes. It also does a
lot less work since it no longer has to copy as much.

Helps with #79103.

r? `@GuillaumeGomez`

Rollup of 6 pull requests

Successful merges:

 - #79379 (Show hidden elements by default when JS is disabled)
 - #79796 (Hide associated constants too when collapsing implementation)
 - #79958 (Fixes reported bugs in Rust Coverage)
 - #80008 (Fix `cargo-binutils` link)
 - #80016 (Use imports instead of rewriting the type signature of `RustcOptGroup::stable`)
 - #80025 (Replace some `println!` with `tidy_error!` to simplify)

Failed merges:

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

Replace some `println!` with `tidy_error!` to simplify

Use imports instead of rewriting the type signature of `RustcOptGroup::stable`

This was an adventure; see https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/'higher.20ranked.20subtype.20error'

r? `@GuillaumeGomez`

Fix `cargo-binutils` link

Fixes reported bugs in Rust Coverage

Fixes: #79569

Fixes: #79566
Fixes: #79565

For the first issue (#79569), I got hit a `debug_assert!()` before
encountering the reported error message (because I have `debug = true`
enabled in my config.toml).

The assertion showed me that some `SwitchInt`s can have more than one
target pointing to the same `BasicBlock`.

I had thought that was invalid, but since it seems to be possible, I'm
allowing this now.

I added a new test for this.

----

In the last two cases above, both tests (intentionally) fail to compile,
but the `InstrumentCoverage` pass is invoked anyway.

The MIR starts with an `Unreachable` `BasicBlock`, which I hadn't
encountered before. (I had assumed the `InstrumentCoverage` pass
would only be invoked with MIRs from successful compilations.)

I don't have test infrastructure set up to test coverage on files that
fail to compile, so I didn't add a new test.

r? `@tmandry`
FYI: `@wesleywiser`

Hide associated constants too when collapsing implementation

Fixes #71849.

r? `@jyn514`

Show hidden elements by default when JS is disabled

Fixes  #79301.

A lot of things are hidden by default which shouldn't when JS is disabled. This PR fixes it.

Before:

![Screenshot from 2020-11-24 14-10-16](https://user-images.githubusercontent.com/3050060/100099361-a16d5580-2e5f-11eb-891b-a4c005aeb1d0.png)

After:

![after](https://user-images.githubusercontent.com/3050060/100099382-a6caa000-2e5f-11eb-8190-14f330aff9a2.png)

r? `@jyn514`

consider assignments of union field of ManuallyDrop type safe

Assigning to `Copy` union fields is safe because that assignment will never drop anything. However, with https://github.com/rust-lang/rust/pull/77547, unions may also have `ManuallyDrop` fields, and their assignments are currently still unsafe. That seems unnecessary though, as assigning `ManuallyDrop` does not drop anything either, and is thus safe even for union fields.

I assume this will at least require FCP.

[mir-opt] Allow debuginfo to be generated for a constant or a Place

Prior to this commit, debuginfo was always generated by mapping a name
to a Place. This has the side-effect that `SimplifyLocals` cannot remove
locals that are only used for debuginfo because their other uses have
been const-propagated.

To allow these locals to be removed, we now allow debuginfo to point to
a constant value. The `ConstProp` pass detects when debuginfo points to
a local with a known constant value and replaces it with the value. This
allows the later `SimplifyLocals` pass to remove the local.

Do not inline finish_grow

Fixes #78471.

Looking at libgkrust.a in Firefox, the sizes for the `gkrust.*.o` file is:
- 18584816 (text) 582418 (data) with unmodified master
- 17937659 (text) 582554 (data) with #72227 reverted
- 17968228 (text) 582858 (data) with `#[inline(never)]` on `grow_amortized` and `grow_exact`, but that has some performance consequences
- 17927760 (text) 582322 (data) with this change

So in terms of size, at least in the case of Firefox, this patch more than undoes the regression. I don't think it should affect performance, but we'll see.

Rustdoc: Cache resolved links in current module

A step towards #77681

This decreases the size of `Item` from 680 to 616 bytes. It also does a
lot less work since it no longer has to copy as much.

This brings the size of `item.deprecation` from 56 to 16 bytes.

This was always questionable, and removing it doesn't fail any tests, so
I think this was not affecting the behavior. It dates all the way back
to the very first commit of rustdoc: 268f3f0f

Lower `discriminant_value` intrinsic

This allows const propagation to evaluate comparisons involving
field-less enums using derived implementations of `PartialEq` (after
inlining `eq`).

This ensures consistent handling of default values for options that are
None if not specified on the command line.

It doesn't work correctly on *-pc-windows-gnu

Update stdarch submodule

Changes included:

* Use a bootstrap guard for modules with new target features
* Avoid calling intrinsics with invalid const arguments
* Avx512bw
* Avx512cd
* Add AVX512BITALG
* Add GFNI Intrinsics
* Add AVX512VPOPCNTDQ Intrinsics
* Add VPCLMULQDQ Intrinsics
* Avx512bw
* Reimplement `_xgetbv` with LLVM intrinsics
* Avx512bw
* Add reamained vmax and vmin via auto-generated code
* Add VAES intrinsics

Fixes #56483.