Bootstrap key logic is too strict

[brson]

Right now the bootstrap key is a hash of CFG_RELEASE (and also CFG_EXTRA_FILENAME if that's set). CFG_RELEASE contains the channel label and the prerelease version. So today the master compiler will build with a compiler called 1.12.0-beta.1 and that's it.

One place where this is problematic is when trying to build master from a local copy of the stable release. To do this you need to bootstrap beta, then bootstrap master. But today beta is 1.12.0-beta.3 - and it can't bootstrap master because they keycheck fails. Furthermore, if you were to build beta with --release-channel=stable you again create a mismatched bootstrap key.

This is frustrating. The logic is too strict for no particular reason. The scheme for deriving the bootstrap key is quite trivial now, and nobody is abusing it. We may just want to turn on the bootstrap whenever the env var is set at all and not worry about this any more.

cc @alexcrichton this caused @glandium quite a bit of pain recently and I think we should solve it relatively soon.

[brson]

Hm in light of #36544, mysterious errors when bootstrapping with the wrong compiler, I think we should be defensive about which compiler we bootstrap from. So actually I think we should loosen the value of the key, but we might also put checks in the build system that the compiler has a version number with a chance of building stage0 correctly. Probably just a warning, e.g. rustbuild could do a semver comparison of the stage0 compiler and warn if it's old.

[nagisa]

cough #32812 cough

[brson]

@nagisa That looks about right. Nice.

[nagisa]

@alexcrichton @nrc you both expressed negativeness towards the PR linked 2 comments above. Does/would your opinion change in the light of this issue, or are you still convinced that we need a bumpier so called “speed bump”?

[brson]

Another scheme that would discourage abuse but not be so troublesome: have two random compile-time values, CFG_CURRENT_BOOTSTRAP_KEY, CFG_NEXT_BOOTSTRAP_KEY; the compiler disables gating when either are provided; the build system sets RUSTC_BOOTSTRAP_KEY=CFG_CURRENT_BOOTSTRAP_KEY; every 6 months or so we promote CFG_NEXT_BOOTSTRAP_KEY to CFG_CURRENT_BOOTSTRAP_KEY and redefine CFG_NEXT_BOOTSTRAP_KEY.

So there's a long, overlapping window where either key is valid, and rotating them discourages anyone from getting in the habit of setting them to work around problems. Not very tricky or prone to error, and doesn't require much maintenance.

[glandium]

Another scheme would be to keep the key and have the build system figure out the key from the output of rustc -v -V (assuming all the required info is in there ; it is for stable compilers, I don't know if a beta compiler prints out beta.n).

[nrc]

I still think that just having a env var will lead to people using unstable features on stable/beta and that would be bad (it is a real slippery slope thing - "I just want this one feature that will be stable soon anyway") and we'll suffer for getting locked in to unstable features. So I still want a speed bump. However, I don't want to cause unnecessary pain, so I'm open to different speedbumps.

[cuviper]

Perhaps the hash should be of just the version, and not include the channel? The level of dev/beta/stable is not really relevant here.

For that matter, the RUSTC_BOOTSTRAP_KEY could even be the unhashed version number. That's still a minor speedbump since it changes every release; it just wouldn't be MD5-obfuscated.

[brson]

Tools team discussed this some and agreed it's fine to just set it to a boolean and see what happens; though @alexcrichton was not present. If people start to abuse it we can tighten it up again. The makefiles will need to continue using the current scheme for the stage0 bootstrap while also supporting the new scheme for --enable-local-rebuild.

[nagisa]

To anybody who wants to tackle this bug: taking #32812 and rebasing it on current master is a good starting point. You will have to add some extra logic to pass beta the bootstrap key calculated using current method for a cycle, as beta will be still using the old bootstrap key approach.

[alexcrichton]

#36548 (comment) sounds reasonable to me. I'd prefer to stick with the current scheme if possible, but if it causes pain unnecessarily it's not worth it.