Toolchain locking is still buggy

[nazar-pc]

This certainly works better than before, but I think there might still be something not quite handled. I occasionally get this in CI:

  Error: ensuring toolchain and components exist

  Caused by:
      Command `rustup component list --toolchain nightly-2026-05-22-aarch64-apple-darwin -q --installed` failed with exit status: 1:
      -- stdout
      
      -- stderr
      error: Missing manifest in toolchain 'nightly-2026-05-22-aarch64-apple-darwin'

https://github.com/nazar-pc/abundance/actions/runs/29024559956/job/86141194982?pr=698

It doesn't happen every time, but enough to be annoying.

Originally posted by @nazar-pc in #622 (comment)

[Firestar99]

rustup itself sadly doesn't protect against other racing rustup cmds, so I made sure we acquire our filelock before calling rustup, so this shouldn't really be possible.

Some scenarios in which it may still fail:

• If spirv_std is a path dependency, we never lock. I assume you're not doing that in CI.
• The file lock is only acquired if we need to build to codegen backend (librustc_codegen_spirv.so exists), to not do any unnecessary locking when it's already build. Meaning:
  • We always query rustup for installed components, even if the .so exists, not sure how that could race
  • If you cargo gpu install, then rustup toolchain remove ..., it won't acquire the lock but still install the toolchain

[nazar-pc]

This issue happens on all platforms supported by GitHub Actions: Linux, Windows and macOS.

It is happening on one of the platforms in ~50% of PRs I open, so there is definitely something there. And yes, the backend should actually be cached in my case, so maybe it is related to that? rustup famously has zero locking implemented (not sure why they don't have at least global installation lock).