fix(cuda_std): pin glam to "0.30" to match the rest of the workspace

[samlaf]

Context

Ran into this glam issue when running https://rust-gpu.github.io/rust-cuda/guide/getting_started.html

Compiling
 cuda_std v0.2.2 (https://github.com/rust-gpu/rust-cuda?rev=7fa76f3d717038a92c90bf4a482b0b8dd3259344#7fa76f3d)
error[E0432]
: unresolved imports glam::UVec2, glam::UVec3
--> 
/home/samlaf/.cargo/git/checkouts/rust-cuda-f2e68423bdc84998/7fa76f3/crates/cuda_std/src/thread.rs:69:12
| 69 |  use glam::{UVec2, UVec3}; |
^^^^^
^^^^^
no UVec3 in the root | | | no UVec2 in the root |
help : a similar name exists in the module | 69
- 
use glam::{ UVec2 , UVec3}; 69
+ 
use glam::{ Vec2 , UVec3}; |
help : a similar name exists in the module | 69
- 
use glam::{UVec2, UVec3 }; 69
+ 
use glam::{UVec2, Vec3 };
|
For more information about this error, try rustc --explain E0432.
error: could not compile cuda_std (lib) due to 1 previous error warning

Bug

cuda_std declared its glam dependency with an unbounded lower bound and no upper cap:

glam = { version = ">=0.22", default-features = false, features = [...] }

With default-features = false, this broke rust-cuda: glam's Type features PR gated the vector types behind cargo features. glam keeps all-types in its default, so ordinary consumers see no change -- but anyone who disables default features loses the integer/size/f64 types unless they re-enable them.

cuda_std relies on those gated types:

• glam::UVec2 / UVec3 (u32) in src/thread.rs
• glam::USizeVec2 / USizeVec3 (size) in src/rt/mod.rs
• pub use glam; re-exports the whole crate to kernel authors

So on glam >=0.33 with defaults off, cuda_std fails to compile (e.g. cannot find glam::UVec2). The unbounded ">=0.22" let a fresh resolve float straight across the 0.32 -> 0.33 break.

Why it wasn't already broken in-tree: the other glam consumers in this workspace (cust, cust_core, optix) all pin glam = "0.30", which unifies the dependency graph to 0.30.9 -- a version that predates the type gating, so all types are present regardless of default-features. The bug only bites a standalone consumer of cuda_std, where nothing else caps glam.

Fix

pin cuda_std to glam = "0.30", matching the other three crates. This caps the bound, keeps the whole workspace on one tested version (0.30.9; Cargo.lock unchanged), and needs no type-feature re-enabling because 0.30 does not gate types (and all-types does not exist there). Behavior is preserved.

Follow-up suggestion

Hoist glam into [workspace.dependencies] so its version is defined once and cannot drift across crates again -- this drift is exactly what allowed cuda_std to diverge from the others.