Closed upsuper closed 4 years ago
I don't think that it's a good idea to set the unstable RUSTC_BOOTSTRAP
environment variable because it is an implementation detail and might change at any time. By setting it automatically, users might think that their project is stable since it builds with a stable compiler. However, any change to the bootstrap process and the unstable environment variable can cause the project to fail.
I would be fine if the user themselves needs to set the RUSTC_BOOTSTRAP
environment variable. So maybe we can check for the variable when a stable/beta toolchain is used and display only a warning instead of a "switch to nightly" error message. This way, users that really want to build the sysroot with a stable compiler can set the environment variable (hopefully after learning about its unstability), but there is no danger that someone accidentally thinks that their project builds on stable.
What do you think?
It's not more unstable than any unstable features, but yeah I agree that making users think they are using stable might not be a good idea.
I don't think this flag is going away in foreseeable future, and even if it does, there would likely be a replacement mechanism, as rustc would always need some mechanism to compile its std full of unstable features, and I would argue that it's unlikely to be too hard to embrace such new mechanism if there would ever be.
And hopefully it can give you more relief that, Firefox is also relying on this flag.
So although I agree that conceptually this is unstable, and rustc provides no guarantee that it will exist and work the same way forever, I would suggest that in practice this may not really be a problem.
But to be honest, I'm fine either way, so feel free to close it if you are not comfortable with this. For what I'm doing, nightly is still required for other dependencies anyway. I'm just hoping that we can move towards an all-stable world :)
I agree that the flag likely won't go away anytime soon. However, I still think that setting the flag automatically is not a good idea.
Some related discussion I found: https://github.com/rust-lang/cargo/issues/7088. This is a bit different than what we do here, but the general recommendation seems to be that RUSTC_BOOTSTRAP
should be avoided in third-party crates.
I'm open to make this project work with RUSTC_BOOTSTRAP
, as long as the users set it themselves.
I'm just hoping that we can move towards an all-stable world :)
Me too! :)
Someone just proposed the same thing for the xargo
project: https://github.com/japaric/xargo/pull/275. The maintainer is also opposed to setting the RUSTC_BOOTSTRAP
flag automatically.
RUSTC_BOOTSTRAP=1
is what the Rust itself uses to build itself (because otherwise it wouldn't build on any channel other than nightly).The justification that std can use unstable features is that it's always bundled with rustc, and whenever an unstable feature changes, std would be updated at the same time.
Since for sysroot we are literally building src from Rust, I think the same justification applies as well.