ash
ash copied to clipboard
ash-rs
generator: Skip setters on `returnedonly="true"` structs
Vulkan annotates structs that are purely returned by the driver and do not have to be constructed by users (besides initializing sType/ pNext). For these we can skip all builder functions (except push_next() and the CStr/slice getter helpers) and lighten our codebase somewhat.
Note that it is still possible to update the structure in a more low-level way by directly acessing the fields (or via FRU syntax). For Rust-based layer implementations this may be somewhat cumbersome, for which we could re-expose the setters behind a cfg(feature = "returnedonly-setters") of sorts?
Note also that vk.xml retroactively adds this attribute to existing structures from time to time, because it was initially forgotten. That would immediately break semver compatibility for us so we have to be careful with this if we want to bump Vulkan spec versions without breaking ash releases.
For completeness, note that upstream does not set returnedonly="true" for structs that require the user to allocate storage, like https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkSurfacePresentModeCompatibilityEXT.html / https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkLatencySurfaceCapabilitiesNV.html.
For Rust-based layer implementations this may be somewhat cumbersome, for which we could re-expose the setters behind a cfg(feature = "returnedonly-setters") of sorts?
Sounds like a good idea to me. Perhaps output-setters?
For completeness, note that upstream does not set returnedonly="true" for structs that require the user to allocate storage
Hmm, seems like this should probably be an attribute on individual fields rather than entire structs.
Hmm, seems like this should probably be an attribute on individual fields rather than entire structs.
Perhaps that's something @oddhack can help us out with, but I can also report it upstream. A lot of sType/pNext structs could have this attribute moved to all other fields.
Otherwise a caller-allocates like annotation/feature might be useful separately as well. Caller-allocated arrays aren't that common in structs (typically only reside in function parameters) but are a necessity for extendability for extending functions via pNext chains.