Manish Goregaokar

https://github.com/unicode-org/icu4x/pull/2170 this confirms it, for whatever reason rustup has decided to use the stable compiler there

@kinnison @pietroalbini Given that there are no easy ways to "select" a rustup version at this time, would it be a good idea to roll back the release until we...

What we know so far: https://github.com/rust-lang/rustup/issues/2958 is a part of this The problem is that when you call `cargo make`, `cargo` sets the RUSTC/etc environment variables based on the current...

from @kinnison > ... anything which runs under cargo and expects to invoke cargo on something other than the host toolchain, they should clean up the environment properly before invoking...

Thinking about it more the `+nightly-foo` issue on windows may also be due to the same kind of bug, if the RUSTC variable ends up with rustc getting called directly...

@sagiegurari no, the problem is that when you run `cargo make`, what happens is that `cargo` is run (under the default toolchain), which then calls `cargo-make` with the environment variables...

That may not be the only problem however. cargo-make setting CARGO when needed also seems correct (maybe it should be setting more things?)

@sagiegurari I don't think that's the problem. This is in part _cargo_ behavior, and how cargo calls custom subcommands. In general I think the following can be taken as an...

I suspect on cargo-make's side, the answer is that it should unset RUSTC and RUSTDOC, and it should _either_ unset CARGO _or_ set it to a toolchain, if specified.

(note that rustup updates are done via `rustup self update`)