The trait `SafeDeref` is not implemented for `UnsafeCommandBuffer` about vulkano

[marc0246]

It's the compiler trying to be too helpful. It would have been clearer if it just told you that UnsafeCommandBuffer doesn't implement PrimaryCommandBufferAbstract. In other words you can't submit it.

[Rua]

That's definitely something we need to address. Probably as part of the task graph, but maybe earlier if possible.

[marc0246]

Yes, when the taskgraph comes around this will be fixed. Everything regarding current sync is on life support at the moment anyway, I don't see a point fixing anything to do with it.

[Jason0214]

Thanks @Rua and @marc0246. I found

vulkano/vulkano/src/command_buffer/traits.rs

Line 143 in f449858

unsafe impl<T> PrimaryCommandBufferAbstract for T

is the PrimaryCommandBufferAbstract which feels like the impl for this trait, I guess the compiler would try to ''instantiate" base on it? And yes, UnsafeCommandBuffer at least does not have resources_usage(), so it will fail anyway. This sounds like an easy patch to work around, resources_usage() is not used by Vulkan.
On the other hand, I am still a bit unclear on SafeDeref, not exact sure how the original https://github.com/vulkano-rs/vulkano/pull/29/files change realizes its change description. And is UnsafeCommandBuffer SafeDerfe-able?

[Jason0214]

Close, because this is not an issue and also not directly related to "taskgraph" mentioned in the discussion.

[marc0246]

I didn't really understand the questions, so it would be nice if you could clarify. I'll answer what I made out.

The compiler understands that UnsafeCommandBuffer doesn't implement PrimaryCommandBufferAbstract, but it implements VulkanObject<Handle = CommandBuffer> + Send + Sync. It understands that due to the blanket impl, any T wich satisfies those bounds, plus SafeDeref<Target: PrimaryCommandBufferAbstract>, will implement PrimaryCommandBufferAbstract. It then tells you that for UnsafeCommandBuffer to implement PrimaryCommandBufferAbstract, it needs to implement SafeDeref. That's true but completely useless information. To be honest I've never seen the errors arising from blanket impls help anyone rather than confuse them. UnsafeCommandBuffer is not a reference, it doesn't even make sense to talk about dereferencing it.

Rust implements operator overloading using traits, Deref being one of them. It overloads the * derefercing operator, that's really it.

Pretty much all libraries that expose traits also have blanket impls for reference and other pointer types to types of those traits, otherwise you wouldn't be able to use those types if they are behind a pointer in places where an implementation of the trait is required. Most libraries implement their traits for e.g. &T, &mut T if applicable, Box<T>, Rc<T>, and Arc<T>. It's just that vulkano chose to make the pointer type generic using SafeDeref.

[Jason0214]

@marc0246 Thanks for following up. My original question is about what's the purpose of SafeDeref. I noticed that the commit adding SafeDeref mentions "guarantee that the device was always the same", so I was curious how SafeDeref achieves it.
Based on your last comment and the fact SafeDeref is a direct inherit of trait Deref. I guess SafeDeref isn't much different from Deref. All my questions have been cleared now 😄

[marc0246]

You are right, SafeDeref is just Deref with the additional guarantee that the pointer always dereferences to the same pointee. It achieves this by being an unsafe trait.