Consider using the host beta toolchain if it already exists at the right version

[jyn514]

Currently, if you have beta installed via rustup, x.py will download it again when building for the first time. It would be great to avoid this needless download. It would also have the benefit that x.py clean wouldn't require redownloading things from the internet.

Possible implementation: try both rustc --version and rustc +beta --version; use the first that is the right version and download beta otherwise. The version should be an exact match (beta 1.xx.0, not just beta or 1.xx.0).

[tesuji]

Should nightly rustc newer than beta be considered too ?

[jyn514]

I would prefer not because that's a silent change in behavior and you might run into bugs. If you have rustc = "..." in config.toml, though, it definitely makes sense to use that version if it exists.

[cuviper]

I'm skeptical that this should be done automatically, but you can do it manually:

./configure --local-rust-root=$(rustc +beta --print=sysroot)

[jyn514]

It seems a waste to redownload the toolchain if it already exists, though. Glad to know it's so easy to implement!

[jyn514]

@matklad mentioned in https://matklad.github.io/2020/09/12/rust-in-2021.html that all of this - pinning the version and downloading automatically only if necessary - could be done by a rust-toolchain file in the root of the repository. That would make it easy to opt-out too: just delete the file.

[Mark-Simulacrum]

"Just delete the file" means a permanent problem for your git status, which isn't great - but do we know why people would want to opt-out? I think it's a pretty good solution to replace (most of) stage0.txt.

[jyn514]

I'm not sure, @cuviper mentioned it in #76419 (comment).

[jyn514]

One issue with rust-toolchain is I don't think it allows having separate toolchains for different components at the same time. stage0.txt uses a beta compiler but a nightly rustfmt - @kinnison, @rbtcollins, @workingjubilee is there any plan to support that? Would you take a PR implementing it?

[rbtcollins]

We also have a toml based overrides file coming in the next release; that documentation doesn't cover it though; I'm not sure where master docs are published at this time.

With regards the rustfmt and compiler toolchain variation; that seems like something we could discuss; though not until the toml structured overrides file has landed. I'd consider it a separate bug and something to design with thought to complications for other projects, support cost, cognitive load etc. But I suspect actually we could make a pretty nice general feature for it, as a number of rust tools rustup installs are indeed pretty separate to the toolchain as a whole.

[kinnison]

Another option is to invoke rustfmt +nightly if that is plausible.

[jyn514]

Another option is to invoke rustfmt +nightly if that is plausible.

The drawback to this is it assumes you're using rustup and gives a hard error otherwise. It should still be possible to bootstrap with a standalone toolchain, it will just be slightly less user friendly.

[jyn514]

One issue with rust-toolchain is I don't think it allows having separate toolchains for different components at the same time. stage0.txt uses a beta compiler but a nightly rustfmt

We'll be able to side-step this altogether if we download rustfmt on HEAD from CI like I suggested in #90672 (comment) (i.e. initial_rustfmt will go away completely).