While it's not bad to have a loud error, we shouldn't stop refreshing repositories when one of them fails to load.

This should help producing better backtraces in production.

While it's not bad to have a loud error, we shouldn't stop refreshing repositories when one of them fails to load.

Great! I have wanted to include some kind of interpreter in the suite, an emulator should do nicely.

I wanted to avoid the git dependency, but then I noticed that we already have a few of them in compile benchmarks, so it's probably not such a big deal.

I wonder if in the benchmark loop, the framebuffer has to be written out? Couldn't we just benchmark the emulation of instructions itself?

Found you an typo trying to "yoink" your code. 👀

:D Thanks.

Btw, I don't think that this codebase should be taken as a source of inspiration :)

I think that it should be done unconditionally. We should copy the things required by the snapshot compiler to stage0-sysroot, so that it can Do its thing™. Especially if it will eventually use rust-lld by default, because in that case rust-lld needs to be there, so that rustup link stage0 ... continues to work.

rust.lld = true specifies whether lld should appear in stage1/2/N compiler's sysroot, which is an orthogonal decision, IMO.

https://github.com/rust-lang/rust/pull/102101 has introduced a check for passing some thread flags to lld. However, it was invoking a (globally available) binary called lld, which I'm pretty sure we never want to do in bootstrap. If you enable use-lld and don't have a lld binary available, this will crash the build.

This PR fixes that by invoking the lld coming from the snapshot compiler instead.

Closing in favour of https://github.com/rust-lang/rust/pull/116278.

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 https://github.com/rust-lang/rust/pull/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.

One slightly annoying thing is that bootstrap supports using a different linker and linker flags for the host compilation, which means that the rustc and rustdoc shims had to be also modified, and the LLD dispatching logic is basically duplicated in bootstrap and in the shim binaries. With MCP510, it should become a bit easier.

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.

After https://github.com/rust-lang/rust/pull/116276, we could remove the manual lld flag passing and switch some of it to MCP510 flags (-Clinker-flavor and -Clink-self-contained).

Best reviewed commit by commit.

CC @petrochenkov

It is causing problems when the program output… contains whitespace :)

This is the cachegrind diff:

604,061,067  ???:rustc_mir_build::thir::pattern::usefulness::is_useful::{closure#0}
 -1,551,859  ???:<rustc_parse::parser::Parser>::bump
  1,441,085  ???:<rustc_parse::parser::Parser>::parse_block_common
  1,061,248  ???:<rustc_query_system::ich::hcx::StableHashingContext as rustc_span::HashStableContext>::def_path_hash
   -893,206  ???:rustc_ast::visit::walk_enum_def::<rustc_lint::early::EarlyContextAndPass<rustc_lint::BuiltinCombinedEarlyLintPass>>
    806,224  ???:<rustc_lint::early::EarlyContextAndPass<rustc_lint::BuiltinCombinedEarlyLintPass> as rustc_ast::visit::Visitor>::visit_variant
    795,623  ???:<rustc_ast::ptr::P<rustc_ast::ast::Expr> as core::clone::Clone>::clone
   -742,328  ???:<rustc_ast::ast::Expr as core::clone::Clone>::clone
    657,211  ???:<rustc_lint::early::EarlyContextAndPass<rustc_lint::BuiltinCombinedEarlyLintPass> as rustc_ast::visit::Visitor>::visit_variant_data

600M more instructions in is_useful.

It is causing problems when the program output… contains whitespace :)

Ok. I'll requeue this into bors once that happens.

• Do you use Cargo?
• Do you use some other build system?
• Do you combine Cargo and some other build system?
  • Which system drives the compilation?