This commit replaces the mirrors base URL contained in the MINGW_URL
with a CUSTOM_MINGW=1 environment variable. The mirrors base URL will be
fetched instead through the MIRRORS_BASE environment variable, defined
in src/ci/shared.sh.

The task was already run just there, so this cleans things up.

CentOS 5 only supports SSLv3 without SNI, and to get newer protocols
working we need to download and compile OpenSSL and cURL from our
mirror. Because of that, we can't use the CDN, as CloudFront requires
TLSv1 with SNI.

This commit changes the dist-x86_64-linux image to bypass the CDN for
OpenSSL and cURL.

When using an async closure as a value in a place that expects a future,
suggest calling the closure.

Fix rust-lang#65923.

Also update org names of some books

remove Copy from Iterator as per comment
rust-lang#58520 (comment)

The wasm targets don't support gdb anyway so there's no need for this
section there.

Related: rust-lang#66426

This commit adds handling for opaque types during inference variable
fallback. Type variables generated from the instantiatino of opaque
types now fallback to the opque type itself.

Normally, the type variable for an instantiated opaque type is either
unified with the concrete type, or with the opaque type itself (e.g when
a function returns an opaque type by calling another function).

However, it's possible for the type variable to be left completely
unconstrained. This can occur in code like this:

```rust
pub type Foo = impl Copy;
fn produce() -> Option<Foo> {
    None
}
```

Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type
variable, but we will never unify it with anything due to the fact
that we return a `None`.

This results in the error message:

`type annotations needed: cannot resolve `_: std::marker::Copy``

pointing at `pub type Foo = impl Copy`.

This message is not only confusing, it's incorrect. When an opaque type
inference variable is completely unconstrained, we can always fall back
to using the opaque type itself. This effectively turns that particular
use of the opaque type into a non-defining use, even if it appears in a
defining scope.

This allows argv[0] to be overridden on the executable's command-line. This also makes the program
executed independent of argv[0].

Does Fuchsia have the same semantics?

Addresses: rust-lang#66510

Because it's the only file that uses it, and removes the need for
importing it.

…xcrichton

Misc CI improvements

This PR contains some misc improvements to our CI configuration:

* The environment variables for MinGW builders were greatly simplified, with just `CUSTOM_MINGW=1` to tell the install scripts to install the vendored copy. All the others (`MINGW_URL`, `MINGW_DIR`, `MINGW_ARCHIVE` and `MSYS_BITS`) are detected either from the builder name or the environment.
* Collecting CPU stats and running the build were moved into scripts.
* Toolstate scripts validation was previously a separate step, ran just when `IMAGE=mingw-check`. This moves the validation code inside the actual image.
* Vendored copies are now fetched from https://ci-mirrors.rust-lang.org instead of directly from the bucket.

r? @alexcrichton

…, r=Centril

Suggest calling async closure when needed

When using an async closure as a value in a place that expects a future,
suggest calling the closure.

Fix rust-lang#65923.

…andler, r=GuillaumeGomez

[doc] Fix the source code highlighting on source comments

The code would always forget the previous selection.

r? @GuillaumeGomez

…varkor

Fix 'type annotations needed' error with opaque types

Related: rust-lang#66426

This commit adds handling for opaque types during inference variable
fallback. Type variables generated from the instantiation of opaque
types now fallback to the opaque type itself.

Normally, the type variable for an instantiated opaque type is either
unified with the concrete type, or with the opaque type itself (e.g when
a function returns an opaque type by calling another function).

However, it's possible for the type variable to be left completely
unconstrained. This can occur in code like this:

```rust
pub type Foo = impl Copy;
fn produce() -> Option<Foo> {
    None
}
```

Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type
variable, but we will never unify it with anything due to the fact
that we return a `None`.

This results in the error message:
```
type annotations needed: cannot resolve `_: std::marker::Copy
```

pointing at `pub type Foo = impl Copy`.

This message is not only confusing, it's incorrect. When an opaque type
inference variable is completely unconstrained, we can always fall back
to using the opaque type itself. This effectively turns that particular
use of the opaque type into a non-defining use, even if it appears in a
defining scope.

Add explanation message for E0641

Part of rust-lang#61137

Cleanup Miri SIMD intrinsics

r? @oli-obk @eddyb Cc @gnzlbg

rustc_plugin: Remove the compatibility shim

The compatibility crate was introduced in rust-lang#62727 to migrate Cargo and some other tools, but now it's no longer necessary.

…astorino

Add JohnTitor to rustc-guide toolstate notification list

Add JohnTitor to rustc-guide toolstate notification list
Also, update org names of some books

r? @spastorino

std::error::Chain: remove Copy

remove Copy from Iterator as per comment
rust-lang#58520 (comment)

Tracker: rust-lang#58520

Add unix::process::CommandExt::arg0

This allows argv[0] to be overridden on the executable's command-line. This also makes the program
executed independent of argv[0].

Does Fuchsia have the same semantics? I'm assuming so.

Addresses: rust-lang#66510

Disable gdb pretty printer global section on wasm targets

The wasm targets don't support gdb anyway so there's no need for this
section there.

resolve: Give derive helpers highest priority during resolution

So they just shadow everything else and don't create ambiguity errors.
This matches the old pre-rust-lang#64694 behavior most closely.

---
The change doesn't apply to this "compatibility" case
```rust
#[trait_helper] // The helper attribute is used before it introduced.
                        // Sadly, compiles on stable, supported via hacks.
                        // I plan to make a compatibility warning for this.
#[derive(Trait)]
struct S;
```
, such attributes still create ambiguities, but rust-lang#64694 didn't change anything for this case.

Fixes rust-lang#66508
Fixes rust-lang#66525

Move the definition of `QueryResult` into `plumbing.rs`.

Because it's the only file that uses it, and removes the need for importing it.

r? @Centril