feat(godbolt): add Compiler Explorer integration for rust-cuda kernels

[g-ampo]

Summary

Add Compiler Explorer integration so users can compile rust-cuda kernels to PTX in the browser.

Closes #177, partially addresses #353.

Building on the discussion between @LegNeato and @Forsworns .This takes the "wrapper script that replicates cuda_builder's rustc invocation" route that @LegNeato suggested (to avoiding the need for cargo on the CE side)

Changes

• contrib/godbolt/rust-cuda-wrapper.sh - wrapper that creates a temp Cargo project with the same rustflags as cuda_builder::invoke_rustc(), builds to PTX, extracts output from cargo JSON
• contrib/godbolt/install.sh - installs pinned nightly, builds rustc_codegen_nvvm, lays out a self-contained prefix
• contrib/godbolt/rust-cuda.defaults.properties - CE language/compiler config
• contrib/godbolt/test-kernel.rs - sample kernels for smoke-testing
• contrib/godbolt/README.md - local testing and upstream submission steps

Testing

• cargo check passes
• cargo clippy --workspace passes
• Tested on: Ubuntu 24.04, RTX 3060 Ti, CUDA 13.0

[LegNeato]

Thanks for working on this! I am not super familiar with compiler explorer, so apologies if my review questions are dumb.

[LegNeato]

Thinking about this some more, instead of shell perhaps it would be better to write this tool in rust (a normal binary that can compile with any version of rust). Then we can add tests and such to our CI to make sure we don't inadvertently break the integration. As it is I am worried that we land something and don't know it breaks until we go to update the version in compiler explorer. Thoughts?

[g-ampo]

Yes would make sense. The main thing the Rust binary would still do is shell out to cargo build under the hood, so the breakage surface is similar to shell (for the glue parts)... but if it imports cuda_std or hooks into the build logic directly, that gives compile-time detection when APIs change, which shell can't do :)

Would be (very) happy to rewrite it in Rust.
Should I do it in this PR or land what's here and follow up?

[LegNeato]

Up to you!

[g-ampo]

@LegNeato Done in 46e82ec: wrapper is now a stand-alone Rust binary (plus an integration test that compiles test-kernel.rs and asserts the output looks like PTX ).

[LegNeato]

Can the wrapper just use cuda_builder directly so these can't get out of sync? It looks like you can set DEP_RUSTC_CODEGEN_NVVM_OUT_DIR or put it in the proper place expected by

rust-cuda/crates/cuda_builder/src/lib.rs

Line 494 in 103a8d5

fn search_backend_artifact(filename: &str) -> Option<PathBuf> {

and it should possibly work?

[g-ampo]

There is some drift risk but unfortunatelly a direct cuda_builder dependency doesn't work here:

• cuda_builder -> nvvm -> cust_raw, and cust_raw (links = "cuda") requires a CUDA SDK at build time. The wrapper would no longer build without a full toolchain which is the thing the Rust rewrite was meant to avoid...
• CudaBuilder::build() writes cargo: lines to stdout (it's a build.rs API); the wrapper needs stdout to be PTX only for CE. The flag logic in invoke_rustc is private anyway. DEP_RUSTC_CODEGEN_NVVM_OUT_DIR only changes where the backend .so is found, not either blocker.

here the real fix would be to extract the flag-building from invoke_rustc into a small dep-free crate that both cuda_builder and the wrapper call so there would be one source of truth. If thats fine with you I would just do this here in this PR.