Fix ice tests when librustc-driver is linked dynamically

Running `dump-ice-to-disk`and `short-ice` tests on Linux targeting `x86_64-fortanix-unknown-sgx` platform results in:
```
jenkins@31cf43196355:~/workspace/rust-sgx-ci/Raoul/rust$ cat /home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/test/run-make/dump-ice-to-disk/dump-ice-to-disk/*
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
/home/jenkins/workspace/rust-sgx-ci/Raoul/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: librustc_driver-fa98927b935b2881.so: cannot open shared object file: No such file or directory
```
Setting the LD_LIBRARY_PATH explicitly to `$(HOST_RPATH_DIR)` in these tests Makefiles resolves the issue. The `thumb-none-qemu` and `thumb-none-cortex-m` run-make tests do something similar.

cc: ```@jethrogb``` ```@vn971``` ```@mkaynov```

Update `.gitmodules` to use shallow submodule clones

This change makes submodule checkouts shallow by default. This significantly reduces the time needed to do a recursive checkout when `--shallow-submodules` is not specified, such as when `x` is not being used.

Move MinGW linker dist option to proper section

Using this option currently results in the error:
```
failed to parse TOML configuration 'config.toml': unknown field `include-mingw-linker`, expected one of `optimize`, `debug`, `codegen-units`, `codegen-units-std`, `debug-assertions`, `debug-assertions-std`, `overflow-checks`, `overflow-checks-std`, `debug-logging`, `debuginfo-level`, `debuginfo-level-rustc`, `debuginfo-level-std`, `debuginfo-level-tools`, `debuginfo-level-tests`, `split-debuginfo`, `run-dsymutil`, `backtrace`, `incremental`, `parallel-compiler`, `default-linker`, `channel`, `description`, `musl-root`, `rpath`, `verbose-tests`, `optimize-tests`, `codegen-tests`, `omit-git-hash`, `dist-src`, `save-toolstates`, `codegen-backends`, `lld`, `use-lld`, `llvm-tools`, `deny-warnings`, `backtrace-on-ice`, `verify-llvm-ir`, `thin-lto-import-instr-limit`, `remap-debuginfo`, `jemalloc`, `test-compare-mode`, `llvm-libunwind`, `control-flow-guard`, `new-symbol-mangling`, `profile-generate`, `profile-use`, `download-rustc`, `lto`, `validate-mir-opts` for key `rust`
```
That's because the option [belongs to `dist` section](https://github.com/rust-lang/rust/blob/bef6ff618f17398775e9d8cd23a6f47d983869dc/src/bootstrap/config.rs#L861).

cc #108581

remove repetitive words

Update Android system definitions and add riscv-linux-android as tier 3 target

This PR includes the following:
* Corrected Android system definitions for some types
* Support for the riscv64-linux-android target

The authoritative types for the system definitions can be found here: https://cs.android.com/android/platform/superproject/+/master:bionic/libc/include/sys/stat.h

Fixes rust-lang/compiler-team#640

Rollup of 9 pull requests

Successful merges:

 - #114111 (Improve test case for experimental API remove_matches)
 - #114169 (refactor builtin unsize handling, extend comments)
 - #114182 (clean up after 113312)
 - #114193 (Update lexer emoji diagnostics to Unicode 15.0)
 - #114200 (Detect trait upcasting through struct tail unsizing in new solver select)
 - #114228 (Check lazy type aliases for well-formedness)
 - #114267 (Map RPITIT's opaque type bounds back from projections to opaques)
 - #114269 (Migrate GUI colors test to original CSS color format)
 - #114286 (Add missing feature gate in multiple_supertrait_upcastable doc)

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

Add missing feature gate in multiple_supertrait_upcastable doc

Fix #112424

Migrate GUI colors test to original CSS color format

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

r? `@notriddle`

Map RPITIT's opaque type bounds back from projections to opaques

An RPITIT in a program's AST is eventually translated into both a projection GAT and an opaque. The opaque is used for default trait methods, like:

```
trait Foo {
  fn bar() -> impl Sized { 0i32 }
}
```

The item bounds for both the projection and opaque are identical, and both have a *projection* self ty. This is mostly okay, since we can normalize this projection within the default trait method body to the opaque, but it does two things:
1. it leads to bugs in places where we don't normalize item bounds, like `deduce_future_output_from_obligations`
2. it leads to extra match arms that are both suspicious looking and also easy to miss

This PR maps the opaque type bounds of the RPITIT's *opaque* back to the opaque's self type to avoid this quirk. Then we can fix the UI test for #108304 (1.) and also remove a bunch of match arms (2.).

Fixes #108304

r? `@spastorino`

Check lazy type aliases for well-formedness

Previously we didn't check if `T: Mul` holds given lazy `type Alias<T> = <T as Mul>::Output;`.
Now we do. It only makes sense.

`@rustbot` label F-lazy_type_alias

r? `@oli-obk`

refactor builtin unsize handling, extend comments

r? `@compiler-errors`

Move BOLT from `bootstrap` to `opt-dist`

Currently, we use BOLT to optimize LLVM for x64 Linux. The BOLT instrumentation and optimization step is implemented in `bootstrap`, but it was always quite hacky, because BOLT works quite differently than PGO. Rather than building an instrumented artifact, it takes an already built artifact and instruments it in-place. This is not a good fit for the bootstrap caching mechanism, and it meant that we had to run BOLT "on-the-fly" when packaging LLVM artifacts into the created sysroot.

The BOLT code was also really only used by the PGO script (now called `opt-dist`) and nothing else, so it was quite hardcoded for this one single usage. And even if someone wanted to use the `--llvm-bolt-profile-[use/generate]` bootstrap flags outside of the PGO script, they would also need to implement profile gathering, as this is not performed by bootstrap anyway.

I think that it could be more practical to move the BOLT logic to the `opt-dist` tool instead. This simplifies bootstrap, removes unneeded implementation of BOLT caching (we will now do it exactly once - no need to check if it has been performed already when bootstrap copies `libLLVM.so` around multiple times) and removes two BOLT-specific bootstrap flags, and also one special case for building LLVM (instead I pass the linker flags with `--set llvm.ldflags` from `opt-dist` now).

There are also a few disadvantages to this new approach:
- We have to guess/find the path to the built `libLLVM.so` file (but currently this is quite easy, it's just in `stage2/lib`).
- We have to provide the BOLT profile externally to bootstrap, so that it is packaged into the reproducible artifacts archive. Doesn't seem like a big deal to me.
- We are depending on some inner behavior of boostrap in `opt-dist` (namely, that `libLLVM.so` is hardlinked). But we do that for many other things in the `opt-dist` tool anyway, it's tied quite closely to bootstrap.

I would like to go back to my attempts to also use BOLT for `librustc_driver.so`, and I think that it might be a bit simpler if I also do it from the `opt-dist` tool, so this is the first step towards that.

Anyway, let me know what you think about this. It's just a refactoring in a way, no big deal.

r? bootstrap

Update cargo

14 commits in 7ac9416d82cd4fc5e707c9ec3574d22dff6466e5..c91a693e7977e33a1064b63a5daf5fb689f01651
2023-07-24 14:29:38 +0000 to 2023-07-31 00:26:46 +0000
- fix: align `cargo --help` text (rust-lang/cargo#12418)
- fix: normalize relative git submodule urls with `ssh://` (rust-lang/cargo#12411)
- test: relax help text assertion (rust-lang/cargo#12416)
- test: relax assertions of panic handler message format (rust-lang/cargo#12413)
- fix(package): Recognize and normalize `cargo.toml` (rust-lang/cargo#12399)
- Clarify `lto` setting passing `-Clinker-plugin-lto` (rust-lang/cargo#12407)
- doc: add missing reference to `CARGO_PROFILE_<name>_STRIP` in environment variables docs (rust-lang/cargo#12408)
- Update curl-sys to pull in curl 8.2.1 (rust-lang/cargo#12406)
- docs: raise awareness of resolver used inside workspace (rust-lang/cargo#12388)
- chore: update `home` to 0.5.7 (rust-lang/cargo#12401)
- Update curl-sys to pull in curl 8.2.0 (rust-lang/cargo#12400)
- test(cli): Track --help output (rust-lang/cargo#11912)
- refactor(test): Move cargo-config into a dir (rust-lang/cargo#12398)
- refactor(tests): Name init ui tests more consistently (rust-lang/cargo#12397)

r? `@ghost`

`codegen_ssa` cleanups

Some clarifications I made when reading this code closely.

r? `@tmiasko`

Signed-off-by: Ncui fliter <imcusg@gmail.com>

Only golden arches

A number of tests in the test suite have applied the somewhat comedic practice of ignoring *every* single target architecture that rustc has ever supported. This is silly, when they are clearly tests built around certain assumptions, primarily of the x86-64 architecture, or in one case when they are only relevant for a handful of 32-bit targets. This has even resulted, in one case, in the same architecture being ignored twice!

Document these better, and use a "revision + only-arch" idiom in the test headers to denote the "golden arches" that actually pass these tests.

This function has some shared code for the thin LTO and fat LTO cases,
but those cases have so little in common that it's actually clearer to
treat them fully separately.

PR #112946 tweaked the naming of LLVM threads, but messed things up
slightly, resulting in threads on Windows having names like `optimize
module {} regex.f10ba03eb5ec7975-cgu.0`.

This commit removes the extraneous `{} `.

It makes things a little clearer.

The main loop has a *very* complex condition, which includes two
mentions of `codegen_state`. The body of the loop then immediately
switches on the `codegen_state`.

I find it easier to understand if it's a `loop` and we check for exit
conditions after switching on `codegen_state`. We end up with a tiny bit
of code duplication, but it's clear that (a) we never exit in the
`Ongoing` case, (b) we exit in the `Completed` state only if several
things are true (and there's interaction with LTO there), and (c) we
exit in the `Aborted` state if a couple of things are true. Also, the
exit conditions are all simple conjunctions.

This loop condition involves `codegen_state`, `work_items`, and
`running_with_own_token`. But the body of the loop cannot modify
`codegen_state`, so repeatedly checking it is unnecessary.

The two functions are alway called together. This commit factors out the
repeated code.

`CodegenContext` is immutable except for the `worker` field - we clone
`CodegenContext` in multiple places, changing the `worker` field each
time. It's simpler to move the `worker` field out of `CodegenContext`.

Because it's usefulness wasn't clear to me, and I initially wondered if
it could be removed. The text is based on the text in #50972, the PR
that added the flag.

Make it match the corresponding comment at the start of the unstable
options.

It's no longer used, and `spawn_named_thread` is preferable, because
naming threads is helpful when profiling.

This is useful when profiling with a profiler like Samply.

The `Worker` is unnecessary, and just makes it longer than necessary.

It took me some time to understand how the main thread can lend a
jobserver token to an LLVM thread. This commit renames a couple of
things to make it clearer.

- Rename the `LLVMing` variant as `Lending`, because that is a clearer
  description of what is happening.
- Rename `running` as `running_with_own_token`, which makes it clearer
  that there might be one additional LLVM thread running (with a loaned
  token). Also add a comment to its definition.

- Thin and fat LTO can't happen together.
- `NeedsLink` and (non-allocator) `Compiled` work item results can't
  happen together.

And rename the `Compiled` variant as `Finished`, because that name makes
it clearer there is nothing left to do, contrasting nicely with the
`Needs*` variants.