incorrect bool/Option(bool) support

[louwenus]

Expected Behaviour

no crash when using bool / Option(bool) (note: in particular, the bug was observed when using iterators over bool)

Example & Steps To Reproduce

This code fail to compile:

#![cfg_attr(target_arch = "spirv", no_std)]

use spirv_std::glam::UVec3;
use spirv_std::spirv;

#[spirv(compute(threads(64)))]
pub fn main_cs(
    #[spirv(global_invocation_id)] id: UVec3,
    #[spirv(storage_buffer, descriptor_set = 0, binding = 0)] buffer: &mut [u32],
) {
    let mut t =test();
    buffer[1] += t.next().unwrap() as u32;
}
struct T{}
#[inline(never)]
pub fn test()->impl Iterator<Item = bool>{
    T{}
}

impl  Iterator for T {
    type Item=bool;
    fn next(&mut self) -> Option<Self::Item> {
        return Some(true);
    }
}

The relevant part of the error

 error: error:0:0 - Expected Result Type to be a pointer or int or float vector or scalar type: Bitcast
           %40 = OpBitcast %bool %33

NB: the error also happen the other way arround (cast from bool to char).
It also seem that these cast force to use the Capability::Int8 when no Int8 is used in similar cases

System Info

• Rust: rustc 1.90.0-nightly
• OS: artix linux with kernel 6.17.8-artix1-1
• GPU: NVIDIA Corporation GA102 [GeForce RTX 3080 Ti]
• SPIR-V: SPIRV-Tools v2025.4 v2025.4-0-g7f2d9ee92

[Firestar99]

You're running against some of the limits of current-day rust-gpu. SPIR-V only supports ordinary structs that don't have any overlapping fields. Meaning no unions nor tagged unions like Option, just regular C-like enums that are #[repr(u32)] work.

Now some Options still "work" only because they have a niche, like bool, NonZero, &T. Meaning instead of appending an extra "discriminant" member, they use some of the empty niches / unused bits in the type to represent whether it's None or not. So Option<NonZeroU32> will be a u32 where 0 means None, and is passed to our codegen an ordinary u32 which may just work in certain cases. These niche types include the ones mentioned in Option#Representation, but is not limited to them. For example, the std assumes Option<bool> can just be transmuted to bool and back, and all codegen backends need to support that transformation.

The capability Int8 is often from code just using u8 somewhere in the std. Or from an enum that is explicitly #[repr(u8)], Like Ordering from PartialCmp, which is why we're discussing integer polyfills.

The primary limitation you'll probably run into soon is that any offset to a pointer doesn't work, so no slicing a slice, no &vec.x (except Copy may "just work"), no iterators beyond Range-likes. Also have a look at #140, those haven't really changed all that much.

(Also yay ComputerCraft!)

[louwenus]

The problem here is exactly that the transmute operation between bool and option bool (which is represented as an u8) use OpBitcast (which work only on int/float/scalar but NOT bool)

bool to int should probably use a OpSelect with a constant 0/1 while int to bool should be a OpINotEqual with 0.

Also, in this case i had an inline(never) to force the issue (i do not know if it is even needed) but i did not have one in my real case error, maybe forcing some more inlining when detecting these, (especially for iterators when most of the time the Option can be discarded)) could be a solution ?

Regarding slice, I basically implemented my own Slice type (correspond more to a &mut [] realy) with a reference to the original slice, an index to the start and the lenght, and implemented Deref/DerefMut on it, and it work like a charm. Maybe all slice could be implemented as such / a more complete spirv_std::Slice convenience type could be implemented ?
(It is kinda out of scope for this particular issue, but I could work on a separate issue/PR if that solution would be appreciated)

[Firestar99]

We'd rather work on the underlying issue, emulating unions and making Option work, than work on the specifics of bool to option bool transmute. That's a huge task and will take a while.

Regarding slice: I get how useful such a type is, but let me have another think about adding it to the standard library, as we're currently working towards supporting pointers properly. Feel free to publish as an independent library on crates in the mean time.