Uh oh!
There was an error while loading. Please reload this page.
Allow bootstrapping without a key. Fixes #36548 - #37265
Conversation
brson
commented
Oct 19, 2016
Nominating to get this convenience for packagers in their hand sooner. The backport will require changing the transitionary key. |
brson
commented
Oct 19, 2016
cc @nagisa |
brson
commented
Oct 19, 2016
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.
brson
commented
Oct 19, 2016
OK, fixed. The answer to how it was building successfully is that there are two build systems. |
alexcrichton
commented
Oct 19, 2016
@bors: r+ p=1 Higher priority as we're likely to backport this. |
bors
commented
Oct 19, 2016
📌 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.
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?)
nagisa
commented
Oct 19, 2016
Seems good to me. |
Allow bootstrapping without a key. Fixesrust-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
bors
commented
Oct 19, 2016
⌛ Testing commit d3c5905 with merge 2918ab8... |
Allow bootstrapping without a key. Fixesrust-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
bors
commented
Oct 19, 2016
⛄ 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