Don't build the compiler before building rust-demangler

[jyn514]

This saves a lot of time compiling, since rust-demangler doesn't actually use any unstable features.

This is not quite ideal because it uses ToolStd, not ToolBootstrap, so rust-demangler would be able to add unstable library features in the future. But it's a lot better than before, and builder.cargo doesn't currently know how to handle stages other than 0.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

At least tests should probably run with the new rustc, to make sure we're not shipping a broken binary. I'm not quite sure how Cargo detects the rustc though, so maybe that'll already happen with this PR - will take a closer look later. I think some Cargo tests exercise unstable rustc features, but those might be only run in their CI, not sure.

I'm not entirely opposed to moving these to bootstrap tools, but at least for Cargo I think it'd be better to build it with latest rustc. It's true it can build with stable, but I'd rather avoid problems during stage0-stepping and get the additional testing from building with a fresh compiler. Plus, per earlier point around tests, we would end up building Cargo twice. I think today RLS also directly links to Cargo and Clippy, so there's a must-build in toolrustc mode there.

[jyn514]

I think today RLS also directly links to Cargo and Clippy, so there's a must-build in toolrustc mode there.

ah, that's a good point - I'll come back to this once we stop shipping RLS in a few cycles. I think the test issues should be avoidable - we may have to pass a different sysroot to cargo or something, but that seems doable.

For now I'll change this to only move rust-demangler to a bootstrap tool.

@rustbot author

[bjorn3]

Won't this break building cargo and rust-demangler for a target other than the build system?

[jyn514]

@bjorn3 ah, you mean it should be possible to cross-compile rust-demangler? That makes sense, but they still shouldn't be ToolRustc tools, they don't depend on rustc_private. I'll try ToolStd and see if that works.

[jyn514]

Ok, I've updated this to be a significantly smaller and more targeted patch. It also only affects rust-demangler and not cargo. I think it should be possible to do something similar with cargo, but I'll avoid doing so while RLS depends on it (to avoid building cargo twice).

[Mark-Simulacrum]

r=me, if you don't want to investigate further

I am a little surprised by the need to avoid only compiling via ToolBootstrap -- is the problem with stage0 that we can't cross-compile in that stage? Otherwise it seems to me like it should be fine to be in stage 0 unless we're trying to save compile cycles (e.g., due to shared dep trees with other steps).

[jyn514]

I am a little surprised by the need to avoid only compiling via ToolBootstrap -- is the problem with stage0 that we can't cross-compile in that stage? Otherwise it seems to me like it should be fine to be in stage 0 unless we're trying to save compile cycles (e.g., due to shared dep trees with other steps).

Tried this out - yes, we don't have the target library available in stage 0. So we need to build the standard library anyway, and at that point I think it's equivalent to ToolStd.

I did notice that we currently have ONLY_HOSTS = true for all extended tools - that seems a bit odd? I would expect them to be fine to cross compile; I guess rustc would need to be cross-compiled too but that seems fine.

@bors r=Mark-Simulacrum rollup

[bors]

📌 Commit 37f9cdb has been approved by Mark-Simulacrum

[jyn514]

hmm, cross-compiling in stage 0 with ToolStd seems to also be broken

$ x b src/tools/rust-demangler --target x86_64-unknown-linux-musl --stage 0
thread 'main' panicked at 'src.symlink_metadata() failed with No such file or directory (os error 2)', src/bootstrap/lib.rs:1440:24

but I think that's a pre-existing bug.

never mind, this is because I was trying to compile a musl toolchain without a musl root

[Mark-Simulacrum]

FWIW, I've been thinking that we might want to push tools we ship to build in stage 1 or later, since that avoids needing to special case or wait a cycle for newly introduced targets. But in practice moving from non-existent to tier 2 in one cycle probably is pretty rare anyway, so it might not be that important.

[jyn514]

Yeah, I think there are a lot more obstacles to adding targets than just needing 6 weeks to build the tools. I've been meaning to try and document adding new targets at some point; that, #94829, downloading bootstrap from CI, and #97762 are my biggest priorities at the moment.