@mrmiywj Sure, sounds good.

I investigated how this could work. Overrides appear to be stored in ~/.multirust/overrides. So we can't just check one into the tree as I suggested before, unless rustup searches up the three until it finds .multirust like Cargo does.

An alternative implementation is to detect the presence of rustup on the system, and use that instead of our custom download logic. So this would mean we test for rustup and if present we use rust-nightly-date to set the toolchain override , and change our cargo and rust invocations to use the one in the PATH. I think as part of this work we should remove cargo-nightly-build and just use a single toolchain version.

The end result would be that if you have rustup installed, we would use that infrastructure to manage the toolchains and as a side benefit, raw cargo and rustc invocations would now work without having to go through mach.

There will need to be some care around cross compiling, assuming rustup can manage cross compile toolchains as well.

@larsbergstrom Does this strategy sound reasonable? Are we likely to need independent cargo and rust toolchains anymore?

Uh oh!

Use rustup to get nightly rust #11361

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions