Allow passing a specific date to bump-stage0
#106396
Conversation
This allows regenerating `src/stage0.json` on changes to the tool, without needing to hard-code the date in the source.
rustbot
added
T-bootstrap
| @@ -164,7 +169,7 @@ fn http_get(url: &str) -> Result<Vec<u8>, Error> { | |||
| data.extend_from_slice(new_data); | |||
| Ok(new_data.len()) | |||
| })?; | |||
| transfer.perform()?; | |||
| transfer.perform().context(format!("failed to fetch {url}"))?; | |||
There was a problem hiding this comment.
the new error message looks like
Building stage0 tool bump-stage0 (aarch64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.16s
Error: failed to fetch https://static.rust-lang.org/dist/2022-10-01/channel-rust-beta.toml
Caused by:
[22] HTTP response code said error (The requested URL returned error: 404)
| let url = if let Some(date) = date { | ||
| format!("{}/dist/{}/channel-rust-{}.toml", config.dist_server, date, channel) | ||
| } else { | ||
| format!("{}/dist/channel-rust-{}.toml", config.dist_server, channel) |
There was a problem hiding this comment.
|
Why is regenerating with the latest a problem? I would expect that to be what we want (even when adding a new tool); certainly we don't want to go back to an older copy by accident. (And if we are out of date we should typically sync up, just a matter of time for someone to do it - I would like to see it automated eventually). I'm not strictly opposed but slightly worried this makes it easier to check in an older copy, since I believe that's not (and shouldn't be) validated in CI. It's not a huge worry since changes are infrequent though. |
|
Regenerating with the latest version invalidates the build cache of all contributors, including the cache for bootstrap tools like bootstrap itself and tidy.
I think it will hopefully be pretty easy to notice changes like that, since they change 50+ lines of stage0.json, and I don't think anyone runs bump-stage0 locally except for T-release and people testing changes to bump-stage0. |
|
To be clear, noticing the change is easy. Noticing we went back (for example, if the clippy PR is open for more than a cycle) seems harder. Though I guess in practice you'll get cfg(bootstrap) errors, so maybe not a real problem. |
ahh I understand the concern now. that will cause a merge conflict :) so I'll be forced to regenerate the file, we can't merge an old change by accident. And the new lines are directly next to the old lines, so it will be easy to notice if the dates don't match between the two. |
|
Yeah, I'm not worried about that due to merge conflicts, as Joshua said. r=me if Mark is not opposed anymore. |
|
@bors r=pietroalbini To be clear, I think the merge conflict helps but resolving it with "let me rerun how I generated it last time" (i.e. passing a date) still means you're getting it wrong. But it's not very critical. |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#106200 (Suggest `impl Fn*` and `impl Future` in `-> _` return suggestions) - rust-lang#106274 (Add JSON output to -Zdump-mono-stats) - rust-lang#106292 (Add codegen test for `Box::new(uninit)` of big arrays) - rust-lang#106327 (Add tidy check for dbg) - rust-lang#106361 (Note maximum integer literal for `IntLiteralTooLarge`) - rust-lang#106396 (Allow passing a specific date to `bump-stage0`) - rust-lang#106436 (Enable doctests for rustc_query_impl) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This allows regenerating
src/stage0.jsonon changes to the tool, without needing to hard-code the date in the source. It was useful for #106394, which added clippy to the list of required components.r? @pietroalbini