Erase explicit layout decorations (Offset/ArrayStride) when disallowed by Vulkan.

[eddyb]

Blocked on getting a spirv-tools-rs release for:

• update vulkan-sdk-1.4.321 spirv-tools-rs#19

---

More recent Vulkan SDK versions have started complaining about types having explicit memory layout, when used with memory that doesn't inherently require explicit layouts (only push constants and buffers really do), e.g.:

error: line 1097: [VUID-StandaloneSpirv-None-10684] Invalid explicit layout decorations on type for operand '367[%_ptr_Function__struct_61]'
  %1207 = OpVariable %_ptr_Function__struct_61 Function

The solution used here is simpler and more specialized (a pass that erases the explicit layout decorations from types behind pointers in storage classes that don't support them, combined with updating affected loads/stores) than what I originally described in #266 (comment), so we can hopefully use this for now and not worry about spirt::{mem,qptr} for the next release.

• fixes spirv-tools v2025.2 makes compiletest fail #276
• fixes Workgroup doesn't work in MoltenVk #266
  (not actually tested with MoltenVK, we should make sure it actually works now)
• see also spirv-val over-validation on private variable decoration KhronosGroup/SPIRV-Tools#6193

[Firestar99]

I just want to note that you're upgrading CI's Vulkan SDK to 1.4.321.0, but use-compiled-tools is still on 1.4.309.0, so we could have a scenario where the old SDK fails where the new SDK passes. I know that upgrading spirv-tools isn't trivial this time, so I would let this pass as is, just something to be aware of.

[eddyb]

TODO: before landing this, we should update spirv-tools-rs as well (I only changed the Vulkan SDK version that is used for CI, via the use-installed-tools feature).

@Firestar99 I 100% agree, that's why I still have the above quoted bit in the PR description, and it's why this PR was in draft state even before rebasing it on top of #400 (I know it'd be slower but it'd be nice to test use-compiled-tools as well, not just use-installed-tools, in CI).

EDIT: fixed the spirv-tools-rs upgrade and landed it:

• update vulkan-sdk-1.4.321 spirv-tools-rs#19

[eddyb]

As the spirv-tools-rs update PR was merged:

• update vulkan-sdk-1.4.321 spirv-tools-rs#19

I was able to get 10 failures in cargo compiletest by using it and turning off the new pass:

diff --git a/Cargo.toml b/Cargo.toml
index 7cf09984100..9da910407c9 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -49,3 +49,3 @@ spirv-std-types = { path = "./crates/spirv-std/shared", version = "=0.9.0" }
 spirv-std-macros = { path = "./crates/spirv-std/macros", version = "=0.9.0" }
-spirv-tools = { version = "0.12.1", default-features = false }
+spirv-tools = { version = "0.12.1", git = "https://github.com/Rust-GPU/spirv-tools-rs", default-features = false }
 rustc_codegen_spirv = { path = "./crates/rustc_codegen_spirv", version = "=0.9.0", default-features = false }
diff --git a/crates/rustc_codegen_spirv/src/linker/mod.rs b/crates/rustc_codegen_spirv/src/linker/mod.rs
index d289c8e5fce..89c46e11f03 100644
--- a/crates/rustc_codegen_spirv/src/linker/mod.rs
+++ b/crates/rustc_codegen_spirv/src/linker/mod.rs
@@ -564,3 +564,3 @@ pub fn link(
 
-        {
+        if false {
             let timer = before_pass("spirt_passes::explicit_layout::erase_when_invalid");

Re-enabling the pass (removing if false), while keeping the newer spirv-tools-rs, passes cargo compiletest.

---

So we should be able to land this once we release another version of spirv-tools-rs, AIUI.