…etrochenkov

check lld version to choose correct option to disable multi-threading in tests

Testing compiler with 'use-lld = true' may be incorrect with old lld.
Flag, disabling multi-threading, should consider lld version.

r? `@petrochenkov`

…etrochenkov

check lld version to choose correct option to disable multi-threading in tests

Testing compiler with 'use-lld = true' may be incorrect with old lld.
Flag, disabling multi-threading, should consider lld version.

r? `@petrochenkov`

Rollup of 8 pull requests

Successful merges:

 - rust-lang#97971 (Enable varargs support for calling conventions other than C or cdecl )
 - rust-lang#101428 (Add mir building test directory)
 - rust-lang#101944 (rustdoc: clean up `#toggle-all-docs`)
 - rust-lang#102101 (check lld version to choose correct option to disable multi-threading in tests)
 - rust-lang#102689 (Add a tier 3 target for the Sony PlayStation 1)
 - rust-lang#103746 (rustdoc: add support for incoherent impls on structs and traits)
 - rust-lang#103758 (Add regression test for reexports in search results)
 - rust-lang#103764 (All verbosity checks in `PrettyPrinter` now go through `PrettyPrinter::should_print_verbose`)

Failed merges:

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

…arsan68,petrochenkov

Generalize LLD usage in bootstrap

The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed:

> Indicates whether LLD will be used to link Rust crates during bootstrap on
> supported platforms. The LLD from the bootstrap distribution will be used
> and not the LLD compiled during the bootstrap.

What it did:
1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang#102101), therefore it wouldn't work if `lld` wasn't available.
2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail.

This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH.

In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap.

To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets.

Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`.

Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler).

Best reviewed commit by commit.

CC `@petrochenkov`

…arsan68,petrochenkov

Generalize LLD usage in bootstrap

The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed:

> Indicates whether LLD will be used to link Rust crates during bootstrap on
> supported platforms. The LLD from the bootstrap distribution will be used
> and not the LLD compiled during the bootstrap.

What it did:
1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang#102101), therefore it wouldn't work if `lld` wasn't available.
2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail.

This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH.

In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap.

To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets.

Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`.

Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler).

Best reviewed commit by commit.

CC `@petrochenkov`

…arsan68,petrochenkov

Generalize LLD usage in bootstrap

The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed:

> Indicates whether LLD will be used to link Rust crates during bootstrap on
> supported platforms. The LLD from the bootstrap distribution will be used
> and not the LLD compiled during the bootstrap.

What it did:
1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang#102101), therefore it wouldn't work if `lld` wasn't available.
2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail.

This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH.

In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap.

To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets.

Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`.

Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler).

Best reviewed commit by commit.

CC `@petrochenkov`

…etrochenkov

Generalize LLD usage in bootstrap

The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed:

> Indicates whether LLD will be used to link Rust crates during bootstrap on
> supported platforms. The LLD from the bootstrap distribution will be used
> and not the LLD compiled during the bootstrap.

What it did:
1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang/rust#102101), therefore it wouldn't work if `lld` wasn't available.
2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail.

This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH.

In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap.

To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets.

Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`.

Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler).

Best reviewed commit by commit.

CC `@petrochenkov`

…etrochenkov

Generalize LLD usage in bootstrap

The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed:

> Indicates whether LLD will be used to link Rust crates during bootstrap on
> supported platforms. The LLD from the bootstrap distribution will be used
> and not the LLD compiled during the bootstrap.

What it did:
1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang/rust#102101), therefore it wouldn't work if `lld` wasn't available.
2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail.

This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH.

In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap.

To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets.

Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`.

Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler).

Best reviewed commit by commit.

CC `@petrochenkov`

…etrochenkov

Generalize LLD usage in bootstrap

The current usage of using LLD (`rust.use-lld = true`) in bootstrap is a bit messy. What it claimed:

> Indicates whether LLD will be used to link Rust crates during bootstrap on
> supported platforms. The LLD from the bootstrap distribution will be used
> and not the LLD compiled during the bootstrap.

What it did:
1) On MSVC, it did indeed use the snapshot compiler's `rust-lld`, but at the same time it was invoking a global `lld` binary (since rust-lang/rust#102101), therefore it wouldn't work if `lld` wasn't available.
2) On other targets, it was just straight up using a global `lld` linker. If it wasn't available, it would fail.

This PR (hopefully) cleans up handling of LLD in bootstrap. It introduces a new enum called `LldMode`, which explicitly distinguishes between no LLD, external LLD and self-contained LLD. Since it's non-trivial to provide a custom path to LLD, if an external `lld` is used, the linker binary has to be named exactly `lld` and it has to be available in PATH.

In addition, this PR also dog-foods [MCP510](rust-lang/compiler-team#510) in bootstrap.

To keep backwards compatibility somewhat, I kept the original `use-lld` flag and mapped the `true` value to `"external"`, which is how it behaved before on Linux and other non-MSVC targets.

Having the option to use an external `lld` on Linux should come in handy for testing on CI once MCP510 sets the default linker on Linux to `lld`.

Note that thanks to MCP510, currently "self-contained" means that `lld` is used from the stage N-1 compiler (before, we always used `lld` from the snapshot/stage0 compiler).

Best reviewed commit by commit.

CC `@petrochenkov`