Nightly version is off by one

[RalfJung]

This says it all:

$ rustc +nightly-2016-06-10 --version
rustc 1.11.0-nightly (7d2f75a95 2016-06-09)

The version reported by rustc itself is consistently off by one compared to what I requested from rustup. That's particularly confusing when looking at e.g. Travis CI build logs of of my project with a particular nightly, and trying to reproduce the result by installing the same nightly.

[kennytm]

We tried to fix it before but it has broken nightlies and thus reverted.

rust-lang/rust-central-station#27 (comment)

[crlf0710]

Maybe add something extra like "built on 2016-06-10" to record the packaging date and it's done? The commit date doesn't have to change...

[SimonSapin]

A typical sequence of events is:

• At 2019-09-01 18:04:49 UTC, Homu finishes dealing with a previous PR and picks up Suggest call fn ctor passed as arg to fn with type param bounds #63870 from the top of its queue. It makes a merge commit dfd43f0 and pushes it to the auto branch.

• Azure Pipelines gets notified of this GitHub Push Event, and schedules a number of builds.

• At 2019-09-01 18:11:06 UTC, after the Linux dist-x86_64-linux build starts running src/ci/run.sh which starts compilation. This produces a rustc executable binary that contains all the information printed by rustc --version.

  rust/src/librustc_driver/lib.rs

  Lines 745 to 777 in fdaf594

  	/// Returns a version string such as "0.12.0-dev".
  	fn release_str() -> Option<&'static str> {
  	option_env!("CFG_RELEASE")
  	}
  	/// Returns the full SHA1 hash of HEAD of the Git repo from which rustc was built.
  	fn commit_hash_str() -> Option<&'static str> {
  	option_env!("CFG_VER_HASH")
  	}
  	/// Returns the "commit date" of HEAD of the Git repo from which rustc was built as a static string.
  	fn commit_date_str() -> Option<&'static str> {
  	option_env!("CFG_VER_DATE")
  	}
  	/// Prints version information
  	pub fn version(binary: &str, matches: &getopts::Matches) {
  	let verbose = matches.opt_present("verbose");
  	println!("{} {}", binary, option_env!("CFG_VERSION").unwrap_or("unknown version"));
  	if verbose {
  	fn unw(x: Option<&str>) -> &str {
  	x.unwrap_or("unknown")
  	}
  	println!("binary: {}", binary);
  	println!("commit-hash: {}", unw(commit_hash_str()));
  	println!("commit-date: {}", unw(commit_date_str()));
  	println!("host: {}", config::host_triple());
  	println!("release: {}", unw(release_str()));
  	get_codegen_sysroot("llvm")().print_version();
  	}
  	}

• At 2019-09-01 21:55:39 UTC, Homu is notified that all builds are successful and pushes the previously-made merge commit to master

• At 2019-09-02 00:00:00 UTC, a cron job starts the Nightly publication. It then fetches the git repository and finds that the master branch is at commit dfd43f0. It downloads the artifacts that were already built for CI, signs them, and uploads them to static.rust-lang.org with a manifest, based on the then-current date.

---

When you run rustup install nigthly-2019-09-02, it refers to the packaging date taken at the last step above.

When you run rustc -V and see rustc 1.39.0-nightly (dfd43f0fd 2019-09-01), it refers to the commit date from the first step above. Since we test exactly what we want to push to master, the merge commit is made by Homu before testing.

something extra like "built on 2016-06-10" to record the packaging date

The build date (step 3) is not the packaging date. And it’s not very useful since it’s ~always a few minutes after the (merge) commit date. And it could vary across builds (e.g. if a machine takes a bit more time to be available to make the macOS build).

For rustc -V to print the packaging date we would either to patch binaries during packaging (which seems risky), or make rustc -V read an external file that would need to be shipped together with the executable.

---

In rust-lang/rust-central-station#27 I tried to hack the packaging date to be "10 minutes ago" instead of "now". Since the cron job starts at midnight UTC and we almost never go 24 hours without merging a PR, this would usually match the commit date.

The problem is that the code for signing the artifacts separately looks up the current date and expects this to match the packaging date.

[jyn514]

I think it might be possible to do this by using the date of the most recent commit, rather than the date the actual release process happens. The git command used would be the same between the release process and x.py, so because it's deterministic they'd pick the same one.

I don't know where the release process currently lives - is it in tree? If not it would be hard to coordinate the two PRs, they'd have to land on the same day to avoid breakage.

[RalfJung]

The release process lives at https://github.com/rust-lang/promote-release, I think.

[jyn514]

and the relevant code is at https://github.com/rust-lang/promote-release/blob/da325f0dded6ec10fcce8099561142c501cef79b/src/sign.rs#L121 :) thanks!

[tomwhoiscontrary]

This continues to be a papercut for me. Some people on my team have been using Rust since before rustup; their process for installing a new nightly is to download the tarball by hand, and extract it into a directory named for the date and the commit hash (like /opt/rust/rust-nightly-2019-08-29-72b2abfd6). I would much prefer to use rustup to manage versions, using a rust-toolchain file, but that involves working out what date to put in rust-toolchain to get the right version. Usually that's one day later, but not always!

[SimonSapin]

To automate a work-around, you could parse https://static.rust-lang.org/dist/2022-11-23/channel-rust-nightly.toml (here for rustup’s nightly-2022-11-23, or similar with another date). The pkg.rustc.version key should have the output of rustc --version.

[joshlf]

Just ran into this while writing tooling that manages the toolchain version we have pinned in CI. Not sure yet what my resolution will be; just wanted to pop in to raise my hand as someone who's affected by this.

[hkalbasi]

I think it might be possible to do this by using the date of the most recent commit, rather than the date the actual release process happens. The git command used would be the same between the release process and x.py, so because it's deterministic they'd pick the same one.

I'm not seeing the problem of this idea. Was it ever tried? The only problem that I can guess is that we won't have nightly for one night so that the new system takes place (and for each night that there is no commit) but I don't think that's important.