Fix cargo run tidy

[jyn514]

When I implemented rust-only bootstrapping in #92260,
I neglected to test stage0 tools - it turns out they were broken because
they couldn't find the sysroot of the initial bootstrap compiler.

This fixes stage0 tools by using rustc --print sysroot instead of assuming rustc is already in a
sysroot and hard-coding the relative directory.

Fixes #94797 (properly, without having to change rustup).

[rust-highfive]

r? @Mark-Simulacrum

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

[Mark-Simulacrum]

The rustfmt initialization (for x.py fmt) may also need similar-ish treatment in config.rs -- I suspect the current logic there will just replace ~/.cargo/bin/rustc with ~/.cargo/bin/rustfmt which will be similarly ineffective.

[Mark-Simulacrum]

But I'm a little confused: does this actually work? ~/.cargo/bin/rustc --print sysroot would give you the default toolchains sysroot, not the one that you were actually running in the parent process, no? Or is that somehow magically being handled already?

[jyn514]

Or is that somehow magically being handled already?

It's magically handled by the rustup proxy - it sets RUSTUP_TOOLCHAIN in the environment to make sure rustc does the right thing when cargo calls it. See around https://github.com/rust-lang/rustup/blob/d080411224dca896dbff18b02feabea16a95d9ed/src/toolchain.rs#L402.

[Mark-Simulacrum]

Ok, great. @rustbot author. once the two nits are fixed, likely r=me

[rustbot]

Error: Parsing shortcut command in comment failed: ...'bot author' | error: expected end of command at >| ' -- once t'...

Please let @rust-lang/release know if you're having trouble with this bot.

[jyn514]

I suspect the current logic there will just replace ~/.cargo/bin/rustc with ~/.cargo/bin/rustfmt which will be similarly ineffective.

This should be ok I think - it's just the sysroot detection that was broken, using the rustup proxy instead of rustfmt itself should work fine.

[jyn514]

Yup, looks fine:

$ cargo run -q fmt src/bootstrap
skip untracked path config.toml.bak during rustfmt invocations
skip untracked path empty.rs during rustfmt invocations
skip untracked path fds-local-no-requests.txt during rustfmt invocations
skip untracked path fds-local.txt during rustfmt invocations
skip untracked path src/build/ during rustfmt invocations
skip untracked path src/test/rustdoc/intra-doc/private-macro.rs during rustfmt invocations

@rustbot ready

[Mark-Simulacrum]

Presumably that will not work with RUSTUP_TOOLCHAIN, since while Cargo and rustc are sourced from the same sysroot (beta) rustfmt needs to be from a different one presumably (nightly-XXXX) - doesn't necessarily need to block this PR, but I would like to understand if this will be a problem down the line or not.

[jyn514]

while Cargo and rustc are sourced from the same sysroot (beta) rustfmt needs to be from a different one presumably (nightly-XXXX) - doesn't necessarily need to block this PR, but I would like to understand if this will be a problem down the line or not.

Yes, this popped up in another PR, it's an existing issue: #94830 (comment)

Do you mind if I leave it for later? I think the logic for fixing this will be very similar to what's needed for download-rustc (i.e. fairly involved, using curl and such to download/unpack things) so I would rather wait until that infrastructure is in place.

[jyn514]

@rustbot ready

[Mark-Simulacrum]

Sure, that works for me.

@bors r+

[bors]

📌 Commit 25a7d2d has been approved by Mark-Simulacrum