Require stabilizations to use a placeholder instead of writing out stabilization version

[est31]

Implements the idea from this zulip stream.

It's a common phenomenon that feature stabilizations don't make it into a particular release, but the version is still inaccurate. Often this is caught in the PR, but it can also require subsequent changes to adjust/correct the version. A list with examples of such PRs is given in #100577, but it's far from complete.

This PR requires stabilization PRs to use the placeholder CURRENT_RUSTC_VERSION, enforced via tidy tooling. The PR also adds a tool that replaces the placeholder with the version number. It can be invoked via ./x.py run src/tools/replace-version-placeholder and is supposed to be ran upon beta branching as well as version bumping and any backports to the beta branch. I filed PRs to the dev guide and forge to document these changes in the release and stabilization workflows:

• The dev guide PR: Update the stabilization guide to refer to the new placeholder system rustc-dev-guide#1443
• The std dev guide PR: Update the library stabilization guide to refer to the new placeholder system std-dev-guide#43
• The forge PR: Changes reflecting the new placeholder system for stabilizations rust-forge#643

Alternative to #100577 which added checking.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[est31]

cc @pietroalbini @yaahc

[Mark-Simulacrum]

Add the sed tooling to replace the placeholder to the nightly -> beta tooling (if present), and the version bumping tooling (if present). I would like to have help with this.

We don't currently have version bump tooling or nightly/beta tooling. There's src/tools/bump-stage0, but that's not quite right: it can be run mid-cycle if we (for example) fix a beta regression.

I think we can add a src/tools/bump-version which will for now just do this replacement -- I'm not sure if by "have help" you mean that you'd like someone else to do it or provide guidance on how? I also think we can leave this out of scope for now, and merge this PR as an immediate improvement (once the dev-guide is adjusted or has a PR up to do so).

The difficulty is that there's not an obvious time to run the tool (as a human), but I think we can do it twice and that will work fine:

• When the newly promoted beta branch is created, we currently just adjust src/ci/channel to be beta; now we'll also run a tool that does this replacement. It will have all the stabilization PRs merged into the beta and so is easy to make correct.
• For master, we have a more difficult story, since we can't easily run the tool as part of bors merge or similar. I think the best option there is to have the tool automatically move itself back in "time" by checking out (maybe virtually via git commands, rather than on the filesystem) the pre-version bump merge repository and making its edits based on contents then. The hardest part here is applying the changes to the local copy, since the line numbers will have changed. The easy way to do that would probably be to actually checkout that just-before-merge commit and run the tool then; that's probably my recommendation, and just change files on disk and use git's natural merging functionality to take care of re-associating them.
  • The future implementation here probably looks something like generating a patch or similar that's applied to create a commit, but that seems like more moving parts at little benefit.

Those times should be added to https://forge.rust-lang.org/release/process.html.

[est31]

I'm not sure if by "have help" you mean that you'd like someone else to do it or provide guidance on how?

I'd mostly like guidance/a design discussion, and your comment already provided great help. I didnt know well how the mechanism works in the detail, and how much tooling there is. It seems that a lot of the process is still manual. I guess then the easiest way would be to add a new tool, update the docs with the times when that tool is supposed to be ran, and notify the people who are doing the bumping/branching currently so that they know about the change.

That tool would literally just be a glorified sed wrapper: it would read the version from src/version, remove any newlines from that string, and then walk recursively over the entire source tree, replacing all occurences (in rs and stdout files) of CURRENT_RUSTC_VERSION with that version number.

My idea/understanding was that glorified sed tool would run in three scenarios:

• Right before src/version is updated to the next Rust version. Currently documented here. Order is important here: It needs to be before the upgrade because the replacement tool reads from the src/version file.

• Whenever a PR that contains CURRENT_RUSTC_VERSION for whatever reason is backported to beta (say a backported stabilization, usually doesn't happen any more). Currently documented here. The person doing the backport has to run that tool locally and add the commit to their backport PR, otherwise tidy will fail (due to the checks added by this PR), so people will be notified if this is forgotten.

• During creation of the beta branch. Currently documented here. There is master-to-beta.sh but I don't know whether it's still being used or not.

I don't think if it's integrated into workflows like that, it won't have to do anything diff based, which would be an advantage of this approach over #100577.

Do you think the tool should be written in Rust, python, or in shell?

[Mark-Simulacrum]

The creation of the beta branch is done by rust-lang/promote-release, but as you can see by those instructions (which are kept up to date and followed during every release), it's still a manual step afterwards to bump the channel, so it's reasonable to run a tool too.

Yes, as part of these workflows shouldn't require diffing, just careful commit checkouts. I think your first point in particular misses that the src/version file is updated by humans and doesn't necessarily (or typically) land as the next PR, so our process should be intentional about "cleaning up" once it actually lands. That can probably be done as part of cfg(bootstrap) removal, which is the other task I'd like us to automate with this script (at least the easy cfg_attr part).

I think the tool should be written in Rust; that'll make extending it to do more interesting things easier - for example, the cfg bootstrap changing.

[Mark-Simulacrum]

I'll also add that in general we're trying to automate where easy/worthwhile, I think the tradeoffs here are towards writing the code as a tool in this repository, but we should be thinking about moving it to promote-release eventually. That mostly means not for example expecting files to be on disk for sed -i but instead reading them in and then writing them back out with Rust APIs, I think.

[est31]

Yes, as part of these workflows shouldn't require diffing, just careful commit checkouts. I think your first point in particular misses that the src/version file is updated by humans and doesn't necessarily (or typically) land as the next PR, so our process should be intentional about "cleaning up" once it actually lands.

Oh right I missed that. master-to-beta.sh currently obtains a commit hash that is the last bors commit before the src/version bump landed. It does not obtain the bors commit that the src/version bump bases upon itself. Which causes a problem with running the sed tool in that PR, as that would only consider the things the bump PR bases on, while it should consider all things upon merge. Running the sed tool after the src/version bump also causes problems though, even if you reduce the number by one, as there is the danger of stabilizations slipping in that will only appear in the next release. I'm getting where you are coming from now, especially that it can be integrated into the PR that does the cfg(bootstrap) removal.

I think the "right before src/version is bumped" approach can be salvaged though: what about adjusting tidy to extend the CURRENT_RUSTC_VERSION ban to not just non-nightly, but also src/version bumping PRs? Then if that PR races a stabilization, CI for the src/version PR will fail, and the bumping person will have to rebase interactively and re-run the tool.

[Mark-Simulacrum]

Just as an fyi, the master to beta script isn't used anymore (logic is moved to promote-release), but it's the same logic so talking about it is fine.

danger of stabilizations slipping in that will only appear in the next release

I don't think I follow this point. So long as we compute the parent of src/version bump by the bors history (--first-parent), there's a linear history of commits on master. The next release branches precisely when src/version merges, not when the PR is created, so I don't think we need to do anything particularly fancy here.

FWIW, we actually also want the same behavior for cfg(bootstrap) which also today sometimes runs into this "actually we stabilized/changed in the next release, so this cfg shouldn't be removed", which is solved in the same way - by looking at state just before src/version merges.

I think the approach should work without the additional tidy restrictions, which seems better. We typically want to avoid any of the release related PRs having conflicts or other reasons they're not going to cleanly land - those are all done on a schedule, and while following the schedule for master or (next) beta related things isn't too critical, slipping or having to rebase means there's an undue load on the people running the release (Pietro or I, today, though I hope to automate more and eventually drop the requirement for super privileges to run it). Ideally all of these PRs are post, r+, done.

[est31]

danger of stabilizations slipping in that will only appear in the next release

[...] there's a linear history of commits on master. The next release branches precisely when src/version merges, not when the PR is created, so I don't think we need to do anything particularly fancy here.

By that I meant that if a stabilization is merged after the src/version bump, and before the cfg(bootstrap) update, then if someone runs the sed script, it will set the number for the prior release, but the stabilization obviously won't make it into the prior release any more but will only appear in the next release.

FWIW, we actually also want the same behavior for cfg(bootstrap) which also today sometimes runs into this "actually we stabilized/changed in the next release, so this cfg shouldn't be removed", which is solved in the same way - by looking at state just before src/version merges.

The issue is the different error conditions: if a cfg(bootstrap) is gone wrong, it will result in a build error. If a stabilization got misattributed for a different release, it won't cause any errors. This is why I suggested that tidy error. I understand that it makes the release process harder, but this entire change is about moving the hard part of attributing stabilization versions to the release process. Personally, I feel it's harder to get the version numbers right if the replacement is done in the cfg(bootstrap) PR than it is to re-run an automatted tool upon a rebase. Plus, if there is really a danger, the PR src/version bump can be merged with a high priority (say 15), so it won't do any races. It's also easier to automate this than some check that runs during cfg(bootstrap) removal.

[Mark-Simulacrum]

I think my suggestion for avoiding that is to run the sed script not on latest master but rather checking out src/version bors merge parent, which should be precisely the list of things that gets stabilized. Now that I think about it, cherry picking the commit made on the beta branch would work too.

Either of these adds ~zero complexity (definitely zero to the script) and decouples the change from beta-destined parts of the process.

[est31]

Hmm yeah I like the cherry-pick idea (I was afraid that it's too complicated to first base the cfg(version) PR on the state that the beta branched from, run the tool, and then rebase it, and not run the tool). Cherry-picking is easier to describe and follow I think. Also I like the fact how both beta and master have a single "source of truth" so to say. So the updated list of what should be done is:

• The sed tool shall be ran during creation of the beta branch, in the PR that changes src/ci/channel, but in a separate commit so that it can be cherry picked later. Currently the beta branch creation is documented here. The automated part is done in promote-release.

• In the master bootstrap update PR, currently documented here, the commit that ran the sed tool during the creation of the beta branch shall be cherry picked and included.

• Whenever a PR that contains CURRENT_RUSTC_VERSION for whatever reason is backported to beta (say a backported stabilization, usually doesn't happen any more), the sed tool shall be run too. Currently documented here. The person doing the backport has to run that tool locally and add the commit to their backport PR, otherwise tidy will fail (due to the checks added by this PR), so people will be notified if this is forgotten.

I think with this I know what to do now for the tool. I'll be implementing it now.

[rust-timer]

Finished benchmarking commit (eaadb89): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean1	range	count2
Regressions ❌ (primary)	3.2%	[3.2%, 3.2%]	1
Regressions ❌ (secondary)	7.6%	[6.1%, 9.1%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.2%	[3.2%, 3.2%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Footnotes

1. the arithmetic mean of the percent change ↩

2. number of relevant changes ↩