kv named the wrong server binary (kv-server, not valkey-server) and assumed a C
compiler the reusable installs only for Go callers; forum assumed a ruby the
reusable never provisions; rocm-rs left gpu-sort on, whose nested nightly
build-std step no stock runner can do; insights-rs asked for --all-features,
which selects the live-endpoint e2e feature.
Co-authored-by: Hanzo Dev <[email protected]>
github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.
Co-authored-by: Hanzo Dev <[email protected]>
Return/param sites used literal u32 where bindgen emits typed aliases
(rocblas_status, rocrand_rng_type, rocfft_status). No-op on Linux where the
alias is u32; correct on the native Windows/MSVC ABI where it is i32. Public
Error types stay byte-identical via explicit 'as u32'.
Edition 2024 promotes unsafe_op_in_unsafe_fn to deny-by-default; the rocblas
level1/2/3 forwarders call FFI without an explicit unsafe block (hard E0133 on
MSVC). Wrap the bodies; no behavior change on any platform.
The kernel is built at compile time by the external amdgpu_kernel_finalize!
proc-macro via a nested nightly+build-std cargo build, which drops off nightly
on Windows/MSVC (E0463 can't find crate for core). GPU sort is unused by
inference, so gating the kernel (empty fallback) lets the crate build on every
host while keeping it default-on. No call sites change.
C enums whose values are all non-negative are compiled as unsigned int
(u32) by GCC/Clang on Linux but as signed int (i32) by MSVC on Windows.
bindgen follows the platform ABI, so every generated status/enum alias
(rocblas_status, rocrand_status, rocrand_rng_type, rocrand_ordering,
rocfft_status_e, rocfft_transform_type, ...) is u32 on Linux and i32 on
Windows. The crate hardcoded a literal u32 at FFI return types,
Error::new sites, and enum-typed parameters, which produced ~50
error[E0308] 'expected u32, found i32' on a native MSVC build while
building fine on Linux.
Fix: reference the bindgen-generated type instead of a literal u32
(ffi::rocblas_status, bindings::rocrand_rng_type, ...). This is a no-op
on Linux (the alias is u32 there) and correct on MSVC. Error variants
that store the raw code keep an explicit 'as u32' so the public Error
type is identical across platforms.
Also wrap the thin rocBLAS level1/2/3 'pub unsafe fn' forwarders' calls
to their unsafe trait methods in 'unsafe { }' blocks. The crate is
edition 2024, where unsafe_op_in_unsafe_fn is deny-by-default; MSVC
enforced it as a hard error[E0133] (17 sites). The wrap is identical on
both platforms and is arguably a correctness fix Linux should enforce too.
Generated bindings.rs is intentionally not included (it is a per-toolchain
build artifact regenerated by bindgen against the locally-installed ROCm
headers).
Verified: 'cargo check' reaches Finished on Linux for both
--no-default-features --features macros and default features (proving the
type changes are no-ops there); the downstream consumer builds and runs on
native Windows/MSVC with ROCm 7.13 (gfx1151).
Publish the Windows/MSVC-portable fork as a first-class crate (hanzo-rocm) so
downstream depends on a proper crates.io crate instead of a git patch. Examples
alias the package (their code still uses rocm_rs::).
Windows/MSVC bindgen emits C enums with only non-negative values as
signed c_int (i32) where Linux GCC/Clang emit c_uint (u32). Two classes
of failure surfaced only on the MSVC build:
E0308 (enum signedness, 31 sites, all in rocrand):
- rocrand/mod.rs: rng_type, ordering, direction_vector_set constants
were hand-typed "u32"; retype to the exact bindgen aliases
rocrand_rng_type / rocrand_ordering / rocrand_direction_vector_set.
- rocrand/generator.rs: PseudoRng::new/new_host and QuasiRng::new take
rocrand_rng_type; Generator::set_ordering takes rocrand_ordering.
- rocarray/random.rs: RandomUtils::seeded_generator rng_type param
follows PseudoRng::new (rocrand_rng_type).
These are no-ops on Linux (c_uint == u32) and correct on MSVC (i32).
E0133 (edition 2024 unsafe_op_in_unsafe_fn, 17 sites): the rocblas
level1/2/3 thin forwarders are "pub unsafe fn" but called their unsafe
trait method with no "unsafe { }" block. MSVC denies this lint as a hard
error; wrap each forwarding call. Required identically on both platforms.
rocblas enum args (rocblas_operation/fill/side/diagonal) already convert
via From impls in types.rs and stay correct on both ABIs; rocfft enums
are already bindgen-typed. Generated bindings.rs left untouched.
Verified: cargo check Finishes on Linux for both --features macros and
default features; zero E0308, zero E0133.
The kernel is built at compile time by the external amdgpu_kernel_finalize!
proc-macro via a nested nightly+build-std cargo build; that nested build
inherits the parent rustc env and drops off nightly on Windows/MSVC
(E0463 can't find crate for core). GPU sort is unused by LLM inference, so
gating the kernel (empty fallback) lets the crate build on every host while
keeping it default-on for native Linux users.
C enums with only non-negative values are unsigned int (u32) under Linux
GCC/Clang but signed int (i32) under MSVC. bindgen follows the platform ABI,
so the generated status/enum types are u32 on Linux and i32 on Windows.
Hand-coding u32 at status/enum-handling sites mismatched the bindgen type on
Windows, producing E0308 'expected u32, found i32'.
Fix is uniform: stop hardcoding u32; use the module's bindgen type. No-op on
Linux (the alias is u32 there), correct on Windows.
rocrand/error.rs:
from_status(status: bindings::rocrand_status) // was u32
Unknown(other as u32) // keep error variant u32-stable
rocfft/error.rs:
impl From<bindings::rocfft_status_e> for Error // was From<u32>
check_error(status: bindings::rocfft_status_e) // was u32
check_compatible_types(transform_type: rocfft_transform_type,
in/out_array_type: rocfft_array_type) // was u32
Unknown(code as u32) // keep error variant u32-stable
rocfft/plan.rs + rocfft/description.rs:
From<TransformType> for rocfft_transform_type // was for u32
From<Precision> for rocfft_precision // (enum-typed FFI args:
From<PlacementType> for rocfft_result_placement // the .into() targets
From<ArrayType> for rocfft_array_type // rocfft_plan_create etc.
From<CommType> for rocfft_comm_type // expect the enum type)
rocsparse/rocarray/hip already used bindgen types (or genuine u32 flags/dims/
counts) and need no change. Verified: cargo check --no-default-features
--features macros reaches Finished on Linux (ROCm 7.13).
MSVC compiles the rocblas_status enum as signed int (i32); GCC/Clang on Linux
make the all-positive enum u32. Hardcoding -> u32 in the FFI fn-pointer type
broke native-Windows builds (136 E0308 mismatches vs Error::new(ffi::rocblas_status)).
Referencing the bindgen-generated type is a no-op on Linux and correct on Windows.
zeekayandHanzo Dev