Add -Zdirect-minimal-versions compatibility and testing.

[kpreid]

Connections
Prevents problems like the one described in #7526.

Description
This PR adds a CI job which confirms building with cargo update -Zdirect-minimal-versions on some platforms. This unstable feature updates all dependencies from the workspace packages to non-workspace packages to the minimum version allowed by the workspace’s dependency specifications, thus ensuring that the project will not build if it actually depends on items newer than its dependency specifications.

It also updates dependency versions to be compatible with -Zdirect-minimal-versions. Specifically, cargo update -Zdirect-minimal-versions will fail if any transitive dependency has a higher dependency requirement than the workspace. This should largely make no difference since those versions would have been required anyway; however, it may increase the minimum dependency requirement seen by users of a single package from crates.io (e.g. users of naga without wgpu). That could be a reason to reject this change.

Also, this change will increase the Cargo.toml maintenance burden, because increasing some dependency versions may require also increasing others even when that change is a noop for any normal build.

Testing
I confirmed that tests pass with the dependencies actually updated, except for naga back::msl::writer::test_stack_size. However, the added CI job does not run tests, only cargo check, to minimize the additional CI cost. Thus, CI will catch use of newer items, but not bugs in old dependencies.

Squash or Rebase?
Rebase

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• If this contains user-facing changes, add a CHANGELOG.md entry.

[kpreid]

…whoops, I only just noticed that there is already a similar test for naga only. It takes a different approach and I'm not familiar with what cargo hack does there and I don't know if it is redundant.

[cwfitzgerald]

Oooo -Ztarget-minimal-version is super cool!

…whoops, I only just noticed that there is already a similar test for naga only. It takes a different approach and I'm not familiar with what cargo hack does there and I don't know if it is redundant.

This fully subsumes the naga test and it should be removed. cargo hack here is making the --remove-dev-deps option possible as there are issues with the dev deps with the normal minimal version flag.

[cwfitzgerald]

This is super cool, one note, plus the naga check needs to be removed.

[cwfitzgerald]

Could we use RUSTC_BOOTSTRAP=1 to avoid needing to use a nightly rustc - if we can't, we need to pin the nightly version.

[kpreid]

Actually, how about I use a pinned nightly for the update (the only part that needs the unstable flag), then build on stable?

[cwfitzgerald]

I guess we could, but this feels more annoying than using RUSTC_BOOTSTRAP, which is what we're doing elsewhere

[kpreid]

As I see it, using a pinned nightly does have an advantage: it won't break when a future stable version removes the flag or changes its behavior. (Admittedly, that's a smaller, more predictable problem.)

But really, speaking only for my emotions and not any particular logical argument, it feels like a tiny smidge of a violation of professional ethics to touch RUSTC_BOOTSTRAP. It is not a supported feature, it is not supposed to be used for anything outside of rustc bootstraping, the Rust project specifically does not want anyone to use it, and therefore I really do not want to be responsible in any way for increasing use of it.

[cwfitzgerald]

I have some complicated feelings about this, as I largely agree, but I also feel like I am a bit backed against a wall.

Previously we did use a pinned nightly version, but it becomes really hard to impossible to find a nightly version that exactly matches stable version. The update that spurred me to use RUSTC_BOOTSTRAP was that the nightly version that should match exactly with when stable was cut from nightly, had both more and less warnings than the stable version did. We don't want to use any nightly code features (and most CI runs against stable), all we want is still "unstable" but usable command line options that do useful work for us. There's no fundamental reason why we can't use those command lines options besides "the build configuration says so" which is rather frustrating. I understand I'm asking for unstable things and I accept that if they break when I update my toolchain that is entirety my problem, just let me do the thing.

To that end, I don't really think there's any moral difference between using pinned nightly vs pinned stable + RUSTC_BOOTSTRAP; any bugs still need to be tested against latest nightly before bugs are filed, and breaking changes are fair game (hence a pinned toolchain). If a -Zuse-unstable-command-line-features existed, I'd 100% use that over RUSTC_BOOTSTRAP, but such a thing doesn't exist. I understand the problems with allowing instability when using an unpinned "stable" version, but we pin everything.

At a previous job I ran with pinned nightly and it caused a variety of problems that stable + BOOTSTRAP wouldn't have had - it's very easy when choosing a nightly version to get a version with crashes or bugs that you only discover once the rest of the company tries to use the new version.

Sorry for the essay, I've apparently had a lot of feelings on this

[cwfitzgerald]

All that being said, if you're uncomfortable landing such a change under your name, we can land as is, just could you move the pinned nightly version to the env block at the top, so they can all be kept synchronized.

[cwfitzgerald]

The mac version needs to be aarch64 - these are M1 runners.