Test against master, not nightly -- or pin nightly

[RalfJung]

It seems we could use https://github.com/kennytm/rustup-toolchain-install-master for CI to test against master make make CI independent of whether a nightly has been released.

This would make it easier for us to land PRs. It could make it harder for users to use miri because we might be "ahead" of nightly -- whereas currently, there always is a nightly that worked. Though it may not be clear which.

So I think we should either:

• Focus on users always being able to get something. Then we should add a "nightly lock file", let's say rust-version, which contains the date of the nightly that this commit was tested with. CI uses that instead of the latest nightly, to make sure it works. The CI cron job still uses the latest nightly.
• Or focus on landing PRs, and use master instead of nightly.

Since the situation with no new nightlies coming out might be resolved in the near future -- which should help with landing PRs as there is definitely a new nightly every night -- I am leaning slightly towards focusing on users. We don't have many of them, but we won't get more if we make installing miri harder. ;)

We could then also ask @shepmaster to use rust-version for miri on the playground.

[oli-obk]

the "nightly lock file" is called rust-toolchain and contains the toolchain that rustup should use for working in said folder. Essentially rustup override add, but sharable via git.

Not sure how to teach the cronjob to ignore that though.

[RalfJung]

Oh is that a standard file? I had no idea.

Not sure how to teach the cronjob to ignore that though.

We have an environment variable to test if we are in a cron job. We could rm rust-toolchain or so ;)

[shepmaster]

We could then also ask @shepmaster to use rust-version for miri on the playground.

I probably would not do this. Installing a new version of Rust and building the crates takes about 25 minutes. If miri didn't build against the nightly that we have already spent 25 minutes building, I'd be loathe to spend another 25 minutes for it.

[RalfJung]

@shepmaster Ah, I somehow thought from what you said that miri had its own container or so. Because you said you'd keep using the old version if the new one failed to build?
But that's fine, we should anyway try to keep miri green. :)

[shepmaster]

miri had its own container or so

It does

keep using the old version if the new one failed to build

It will, because it will fail to build in CI, then fail to upload, and the playground will never download a new version.

The problem is that it builds atop the most recent nightly, so if the current master branch of Miri doesn't build with the most recently available nightly version of Rust, Miri will not be updated.

I believe this is basically the same workflow that any end-user of Miri would experience, so if it fails extremely frequently in such a setup, it would seem to indicate that it would be very hard for people to use Miri themselves.

[RalfJung]

So @oli-obk what do you think about a concrete dated nightly into rust-toolchain? On the minus side this could lead to people that regularly git pull accidentally installing a whole bunch of nightlies for some specific dates. On the plus side it would make picking a working nightly automatic.

Alternatively we could just have another file with a version that we guarantee will work. (Well, we don't fully guarantee it because there is no Cargo.lock.)

@shepmaster

so if the current master branch of Miri doesn't build with the most recently available nightly version of Rust, Miri will not be updated.

But the old Miri will keep working, and since it has its own copy of rustc it also doesn't get broken by the fact that the rustc used my the rest of playground got updated -- right?

[shepmaster]

But the old Miri will keep working, and since it has its own copy of rustc it also doesn't get broken by the fact that the rustc used my the rest of playground got updated -- right?

That is correct!