Fix cargo-gpu in build script failing when called by Miri or Clippy

[tuguzT]

Requires Rust-GPU/rust-gpu#335

See that PR for details as well

Resolves #93
Resolves #77

[Firestar99]

Miri works, but ran into some trouble with clippy: The install action when using a local path to rust-gpu seems to use the wrong toolchain for some reason. Will have a go at it myself.

[2025-07-17T08:52:22Z DEBUG cargo_gpu::install] building artifacts with `cd "/home/firestar99/workspace/frameworks/rust-gpu" && env -u CARGO_CFG_FEATURE [...] "cargo" "+nightly-2025-06-23" "build" "--release" "-p" "rustc_codegen_spirv" "--lib"`
[...]
error[E0514]: found crate `strum` compiled by an incompatible version of rustc
 --> crates/rustc_codegen_spirv-target-specs/src/lib.rs:5:5
  |
5 | use strum::{Display, EnumIter, EnumString, IntoStaticStr};
  |     ^^^^^
  |
  = note: the following crate versions were found:
          crate `strum` compiled by rustc 1.89.0-nightly (be19eda0d 2025-06-22): /home/firestar99/workspace/frameworks/rust-gpu/target/release/deps/libstrum-23be4bc9b25a9a01.rmeta
  = help: please recompile that crate using this compiler (rustc 1.88.0 (6b00bc388 2025-06-23)) (consider running `cargo clean` first)

[tuguzT]

The install action when using a local path to rust-gpu seems to use the wrong toolchain for some reason.

Having the same problem with Clippy.

Additionally, when testing locally just now (with rust-gpu pulled from Rust-GPU/rust-gpu#335) I've noticed that Clippy continues to fail for some reason with the same message on build phase (but Miri works!):

  error: failed to run `rustc` to learn about target-specific information

  Caused by:
    process didn't exit successfully: `C:\Users\tuguzT\.rustup\toolchains\stable-x86_64-pc-windows-msvc\bin\clippy-driver.exe C:\Users\tuguzT\.rustup\toolchains\nightly-2025-06-23-x86_64-pc-windows-msvc\bin\rustc.exe - --crate-name ___ --print=file-names -Zcodegen-backend=C:\Users\tuguzT\AppData\Local\rust-gpu\codegen\https___github_com_tuguzT_rust-gpu+b11f13bd\rustc_codegen_spirv.dll -Zbinary-dep-depinfo -Csymbol-mangling-version=v0 -Zcrate-attr=feature(register_tool) -Zcrate-attr=register_tool(rust_gpu) -Coverflow-checks=off -Cdebug-assertions=off -Zinline-mir=off -Zmir-enable-passes=-GVN -Zshare-generics=off -Cllvm-args=--spirv-metadata=full --target \\?\C:\Users\tuguzT\AppData\Local\rust-gpu\codegen\https___github_com_tuguzT_rust-gpu+b11f13bd\target-specs\spirv-unknown-vulkan1.2.json --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=split-debuginfo --print=crate-name --print=cfg -Wwarnings` (exit code: 1)
    --- stderr
    error: the option `Z` is only accepted on the nightly compiler

    help: consider switching to a nightly toolchain: `rustup default nightly`

    note: selecting a toolchain with `+toolchain` arguments require a rustup proxy; see <https://rust-lang.github.io/rustup/concepts/index.html>

    note: for more information about Rust's stability policy, see <https://doc.rust-lang.org/book/appendix-07-nightly-rust.html#unstable-features>

    error: 1 nightly option were parsed

  Error: BuildFailed

So, removing RUSTC_WRAPPER might be not enough for Clippy 🥲.

[Firestar99]

Cargo clippy now works as well. I also unified env var cleaning in spirv-builder and added env var debug printing, so any issues like this should be easier to debug in the future.

@tuguzT feel free to give this branch another try :D

[tuguzT]

@Firestar99, thanks, I'll try this out until tomorrow

[tuguzT]

I tested this PR (and rust-gpu one, too) on the sample project mentioned in the issue and on my own project in which I originally noticed this issue...
And it is working flawlessly!

Additionally, I haven't known it is possible to use PR's git commit hash when linking to the original repository, could have simplified testing for me if I had known it earlier.
Thanks for fixing these PRs!

[Firestar99]

You can also use local paths like spirv-std = { path = "../rust-gpu/crates/spirv-std" } and it'll even rebuild the codegen backend within the same target dir to make it as easy as possible to dev and immediately test in another project :D