It's so much easier to use RUSTUP_TOOLCHAIN for this, I was just asking @Firestar99 why the + syntax when the env var also works.

All you need in the script, if you want to have dynamic dispatch, is:

''
  #!${pkgs.lib.getExe pkgs.bash}
  exec "${toolchains}/${"\$"}{RUSTUP_TOOLCHAIN:-stable}/bin/$(basename "$0")" "$@"
''

(I don't like that ${"\$"} but am not sure I can make it much nicer)

I suppose something different than what you are doing today is you would want to define toolchains as one of those sym trees with one directory per supported toolchain - maybe the oxalica overlay rust-bin has something along those lines? (it's been a while since I looked at it anyway)

Although, if cargo-gpu/spirv-builder switched to setting RUSTUP_TOOLCHAIN, the fact that this script only has to filter out the + syntax, makes me think the script can just go away? (since I guess there is no dynamic dispatch right now, just a pesky first argument)

We don't want devs mistaking the pinned rust-gpu rust nightly toolchain for a normal nightly toolchain. We want a way to ensure that it is only ever usable to compile rust-gpu code. A wrapper script is the best way to ensure that in my opinion.

But getting rid of the filter logic would be great. Thanks for the comment.

I just want to note that on master, we kill the RUSTUP_TOOLCHAIN env var. I'm unsure if my branch has these changes already or not, so we could see behaviour differences between now and me rebasing the branch.

https://github.com/Rust-GPU/rust-gpu/blob/e0dfdd1112d9b2cf27d10e25104dc997db9acdf0/crates/spirv-builder/src/cargo_cmd.rs#L52

Yes we do need a better solution for this, but since this has to work within the next week, it'll have to wait.