bitshifter / glam-rs / 36053431749

99%

push

github

fix: rust-gpu breakage after PR 786 / v0.33.6 (#861)

# Objective

From rust-gpu issue https://github.com/Rust-GPU/rust-gpu/issues/645:
> PR https://github.com/bitshifter/glam-rs/pull/786 changed the
definition of `Vec3A` to make it `bytemuck::Pod`:
```diff
  #[repr(align(16))]
  #[repr(C)]
  #[cfg_attr(target_arch = "spirv", rust_gpu::vector::v1)]
  pub struct Vec3A {
      pub x: f32,
      pub y: f32,
      pub z: f32,
+     _w: f32,
  }
```

> From rust-gpu's perspective, this is now a vector with 4 floats
instead of 3 floats, breaking a lot of safety assumptions in our
codebase.

This PR is a **short-term fix** that undoes the changes in that PR **for
the spirv target only** to fix rust-gpu setups using glam v0.33.6+. It
is hopefully included in the next minor release of v0.33.9.

## long-term fix

I hate amount of special casing in this PR. spirv and cpu targets are
once again diverging even more.

Other options I've considered:
* Undoing that PR isn't feasible, as it would be a breaking change for
normal (non rust-gpu) users, since you'd be removing functionality.
* Fixing it within the rust-gpu compiler will be a giant hack to special
case Vec3A, and even more annoying if we want to remove it for future
glam versions.
* Changing the `#[spirv::vector::v1]` attribute to tell rust-gpu to
treat it as a 3xf32 will be a breaking change on both sides, eg. once
you update beyond this rust-gpu version you must also update glam and
vice versa.

So my thought is to add this "short-term" hack to glam to make it work
with current rust-gpu. And by the time the next major release v0.34.0
comes around, have a long-term solution ready. Like a
`#[spirv::vector::v2(3, f32)]` where you can explicitly specify that
this type is a 3xf32 and rust-gpu should just drop the last member. (And
revert this PR)

I think very-long-term we may be better off not special casing glam
vectors at all, which would likely gain us support for non-glam vector
libraries too. But that w... (continued)

1 of 1 new or added line in 1 file covered. (100.0%)

93211 of 94143 relevant lines covered (99.01%)

123578.07 hits per line