-
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
Require stabilizations to use a placeholder instead of writing out stabilization version #100591
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
edddcdd
to
a76b9d6
Compare
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:
Those times should be added to https://forge.rust-lang.org/release/process.html. |
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 My idea/understanding was that glorified sed tool would run in three scenarios:
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? |
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. |
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. |
Oh right I missed that. I think the "right before src/version is bumped" approach can be salvaged though: what about adjusting tidy to extend the |
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.
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. |
By that I meant that if a stabilization is merged after the
The issue is the different error conditions: if a |
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. |
Hmm yeah I like the cherry-pick idea (I was afraid that it's too complicated to first base the
I think with this I know what to do now for the tool. I'll be implementing it now. |
a76b9d6
to
ebf1d77
Compare
ebf1d77
to
6c5fa74
Compare
Finished benchmarking commit (eaadb89): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis 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.
CyclesThis benchmark run did not return any relevant results for this metric. Footnotes |
… r=Mark-Simulacrum Also replace the version placeholder in rustc_attr Replace the version placeholder with the current version in the rustc_attr crate too so that users won't see the placeholder but instead the explicit version. This especially fixes the bug for rustdoc not showing it but instead the placeholder. Originally reported [here](https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/libs.20stabilization.20placeholder/near/296057188). cc rust-lang#100591 ![Screenshot_20220830_233727](https://user-images.githubusercontent.com/8872119/187548079-6207776b-4481-4351-afff-607f5b3fe03a.png)
… r=Mark-Simulacrum Also replace the version placeholder in rustc_attr Replace the version placeholder with the current version in the rustc_attr crate too so that users won't see the placeholder but instead the explicit version. This especially fixes the bug for rustdoc not showing it but instead the placeholder. Originally reported [here](https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/libs.20stabilization.20placeholder/near/296057188). cc rust-lang#100591 ![Screenshot_20220830_233727](https://user-images.githubusercontent.com/8872119/187548079-6207776b-4481-4351-afff-607f5b3fe03a.png)
… r=Mark-Simulacrum Also replace the version placeholder in rustc_attr Replace the version placeholder with the current version in the rustc_attr crate too so that users won't see the placeholder but instead the explicit version. This especially fixes the bug for rustdoc not showing it but instead the placeholder. Originally reported [here](https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/libs.20stabilization.20placeholder/near/296057188). cc rust-lang#100591 ![Screenshot_20220830_233727](https://user-images.githubusercontent.com/8872119/187548079-6207776b-4481-4351-afff-607f5b3fe03a.png)
… r=Mark-Simulacrum Also replace the version placeholder in rustc_attr Replace the version placeholder with the current version in the rustc_attr crate too so that users won't see the placeholder but instead the explicit version. This especially fixes the bug for rustdoc not showing it but instead the placeholder. Originally reported [here](https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/libs.20stabilization.20placeholder/near/296057188). cc rust-lang#100591 ![Screenshot_20220830_233727](https://user-images.githubusercontent.com/8872119/187548079-6207776b-4481-4351-afff-607f5b3fe03a.png)
… r=Mark-Simulacrum Also replace the version placeholder in rustc_attr Replace the version placeholder with the current version in the rustc_attr crate too so that users won't see the placeholder but instead the explicit version. This especially fixes the bug for rustdoc not showing it but instead the placeholder. Originally reported [here](https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/libs.20stabilization.20placeholder/near/296057188). cc rust-lang#100591 ![Screenshot_20220830_233727](https://user-images.githubusercontent.com/8872119/187548079-6207776b-4481-4351-afff-607f5b3fe03a.png)
… r=Mark-Simulacrum Also replace the version placeholder in rustc_attr Replace the version placeholder with the current version in the rustc_attr crate too so that users won't see the placeholder but instead the explicit version. This especially fixes the bug for rustdoc not showing it but instead the placeholder. Originally reported [here](https://rust-lang.zulipchat.com/#narrow/stream/241545-t-release/topic/libs.20stabilization.20placeholder/near/296057188). cc rust-lang#100591 ![Screenshot_20220830_233727](https://user-images.githubusercontent.com/8872119/187548079-6207776b-4481-4351-afff-607f5b3fe03a.png)
…acrum Fix error printing mistake in tidy Fixes a small bug in the error printing code added by rust-lang#100591 .
…ics, r=jackh726 Also replace the placeholder for the stable_features lint Follow up of rust-lang#101215 and rust-lang#100591 . Fixes rust-lang#101766
…=Mark-Simulacrum Add all submodules to the list of directories tidy skips Tidy contains a blacklist of directories that it is not visiting. This list is also used by the `replace-version-placeholder` tool added by rust-lang#100591 , to determine the directories to do its replacement from. Generally, tidy does not check submodules, but this is not done consistently for all submodules. This PR adds the submodules that were previously missing, so that the `replace-version-placeholder` tool does not attempt to change content of the books. This was needed because `rustc-dev-guide` contains the placeholder, leading to rust-lang#102014. Fixes rust-lang#102014
…k-Simulacrum Don't crate-locally reexport walk functions in tidy I've moved the walk functions into their own module in rust-lang#100591 and didn't want to make changing the paths everywhere in tidy part of the PRs diff, so I just reexported the functions locally. This PR removes the crate-local reexport and instead does module level reexports. I'm not sure how much it's worth it and whether the new state is better, idk. Feel free to have any opinion on this.
9480: Convert compiler features to json and update compiler features r=mchernyavsky a=Undin After rust-lang/rust#100591, compiler uses `CURRENT_RUSTC_VERSION` placeholder as value of `since` field which means that feature is available in the current compiler. It's ok for the compiler, but the plugin should work with different compiler versions, so it needs some concrete version when the feature became available to annotate code properly. The main idea to solve this problem is to use already saved values: - if feature has a placeholder and we didn't meet it before, the current compiler version will be used to replace the placeholder. Here we assume that this code is launched with the same (or almost the same) rustc version as in rustc master - otherwise, just use version saved previously Previously, we saved info about compiler features directly as generated kotlin code and it made loading this info from `attributes-info` quite complicated. So, now compiler features are saved in language independent form - json file located in resources. This approach not only allows us to deserialize data in any language. It also opens up the possibility to upload generated json somewhere and load this file from plugin to update features info Closes #9258 changelog: Keep info about compiler features in json instead of generated Kotlin code Co-authored-by: Arseniy Pendryak <[email protected]>
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:Alternative to #100577 which added checking.