-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow bootstrapping without a key. Fixes #36548 #37265
Conversation
Nominating to get this convenience for packagers in their hand sooner. The backport will require changing the transitionary key. |
cc @nagisa |
Oh I see a problem with this patch that makes me wonder how it's building successfully... |
This will make it easier for packagers to bootstrap rustc when they happen to have a bootstrap compiler with a slightly different version number. It's not ok for anything other than the build system to set this environment variable.
OK, fixed. The answer to how it was building successfully is that there are two build systems. |
@bors: r+ p=1 Higher priority as we're likely to backport this. |
📌 Commit d3c5905 has been approved by |
cmd.env("RUSTC_BOOTSTRAP_KEY", bootstrap_key); | ||
fn add_bootstrap_key(&self, cmd: &mut Command) { | ||
cmd.env("RUSTC_BOOTSTRAP", ""); | ||
// FIXME: Transitionary measure to bootstrap using the old bootstrap logic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be SNAP, I think? I don’t think anybody looks at FIXMEs on a rollover (though I suspect nobody looks at SNAPs either anymore?)
Seems good to me. |
Allow bootstrapping without a key. Fixes rust-lang#36548 This will make it easier for packagers to bootstrap rustc when they happen to have a bootstrap compiler with a slightly different version number. It's not ok for anything other than the build system to set this environment variable. r? @alexcrichton
⌛ Testing commit d3c5905 with merge 2918ab8... |
Allow bootstrapping without a key. Fixes rust-lang#36548 This will make it easier for packagers to bootstrap rustc when they happen to have a bootstrap compiler with a slightly different version number. It's not ok for anything other than the build system to set this environment variable. r? @alexcrichton
⛄ The build was interrupted to prioritize another pull request. |
A new point-release shouldn't change any language semantics, so a local stage0 that matches MAJOR.MINOR version should still be considered a local-rebuild as far as `--cfg stageN` features go. e.g. `1.14.0` should be considered a local-rebuild for any `1.14.X`. (Bootstrap keys used to be an issue too, until rust-lang#37265.)
Detect local-rebuild by just the MAJOR.MINOR version A new point-release shouldn't change any language semantics, so a local stage0 that matches MAJOR.MINOR version should still be considered a local-rebuild as far as `--cfg stageN` features go. e.g. `1.14.0` should be considered a local-rebuild for any `1.14.X`. (Bootstrap keys used to be an issue too, until #37265.)
Newer nightlies check a new environment variable that if set will loosen restrictions on which compiler version can be used for bootstrapping. Upstream issue is at rust-lang/rust#37265
This will make it easier for packagers to bootstrap rustc when they happen
to have a bootstrap compiler with a slightly different version number.
It's not ok for anything other than the build system to set this environment variable.
r? @alexcrichton