Repository navigation
entry points with an enum of exactly two variants fails #358
Description
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
Activity
[-](my bug report)[/-][+]entry points with an enum of exactly two varants fails[/+][-]entry points with an enum of exactly two varants fails[/-][+]entry points with an enum of exactly two variants fails[/+]charles-r-earp commentedon Aug 5, 2025
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.
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 commentedon Aug 6, 2025
Right, we catch the case where they are bools directly, this is just unexpected as it is an internal repr. This is becoming 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)