entry points with an enum of exactly two variants fails

[Firestar99]

Rust-gpu rejects entry points with an enum of exactly two variants and no values. rustc seems to convert those to bools, and we have explicit checks to fail emitting bools. Maybe we should even reconsider whether we actually want to block bools this way, and handle them as two variant enums?

// build-pass
use spirv_std::spirv;
use spirv_std::glam::Vec4;

pub enum MyEnum {
    Variant1,
    Variant2,
}

#[spirv(fragment)]
pub fn main(
    #[spirv(storage_buffer, descriptor_set = 0, binding = 0)] value: &MyEnum,
    out: &mut Vec4,
) {
    *out = match value {
        MyEnum::Variant1 => Vec4::new(1., 0., 0., 1.),
        MyEnum::Variant2 => Vec4::new(0., 1., 1., 1.),
    }
}

fails with:

error: entry-point parameter cannot contain `bool`s
  --> $DIR/entry_point_enum_two_variants.rs:12:70
   |
12 |     #[spirv(storage_buffer, descriptor_set = 0, binding = 0)] value: &MyEnum,
   |                                                                      ^^^^^^^

error: aborting due to 1 previous error

[charles-r-earp]

This is a niche optimization for repr Rust enums with values 0 and 1. The solution is either providing different values for the variants, or using repr C, u32, etc.

pub enum MyEnum {
    Variant1 = 1,
    Variant2,
}

#[repr(u32)]
pub enum MyEnum {
    Variant1,
    Variant2,
}

SPIR-V does have bools, but they cannot be in the interface (ie used in a storage buffer), because they are abstract and have no defined size.

[LegNeato]

Right, we catch the case where they are bools directly, this is just unexpected as it is an internal repr. This is becomign more and more of a problem and probably something we need to think about systemically (internal repr came up in the context of capabilities like Int64 and polyfilling)