Closed 0xcaff closed 4 months ago
I think, the way the trait is implemented now, it's not going to work. It expects the base type to implement FromVulkan
on the reference, but all the existing FromVulkan
implementations are on the base type directly. So it may be necessary to include the clone
call after all. Alternatively, the FromVulkan
trait could maybe rewritten to always take references?
I was thinking of having a blanket impl for references which implement Copy.
impl <U: FromVulkan<T>, T: Copy> FromVulkan<&T> for U {
fn from_vulkan(val: &T) -> Option<Self> {
U::from_vulkan(*val)
}
}
For types which implement Clone but not Copy, I think its a good idea to explicitly handle the cloning. In the latest vk.xml, the only instance of a member which is an array is ImageLayout
, an enum which implements Copy.
I was thinking of putting it in the next PR, given your question I've decided to add it to this one.
Since this will only be dealing with Vulkan/C types, all of them are expected to be Copy
anyway.
I see, nice!
Anything else you want changed in this PR before it's ready to merge?
Overview
In the vk.xml added in ash 0.38, the newly added
VkPhysicalDeviceHostImageCopyPropertiesEXT
struct has the following xml:Currently, the
pCopySrcLayouts
andpCopyDstLayouts
arrays get a type of*mut T
(where T is defined by thevulkano_type
function). This PR changes the autogen behavior to do the following.*mut T
as a&[T]
with a length specified by thelen
attribute.p_{field_name}
to{field_name}
Merge Order
This is safe to merge today as this code adds functionality to handle the new vk.xml. The behavior for the current vk.xml will remain unchanged.
Related PRs:
Reviewing
I've broken up the changes int logical commits which have straightforward diffs to make it a bit easier to review.