Allow using `MaybeUninit`

[NiklasNummelin]

When using MaybeUninit to initialize variables one gets this issue:
error: Cannot cast between pointer types. From: [u8; 256]. To: *struct core::mem::ManuallyDrop<[Vec4; 16]> { value: [f32x4; 16] }.

Would be nice to allow, if possible, as it's often unnecessary to initialize variables in shaders and adds additional overhead.

[NiklasNummelin]

I can also add that using core::mem::uninitialized() leads to the same issue.

[LegNeato]

Hmmm, from the tests it looks like this might already be supported?

https://github.com/EmbarkStudios/rust-gpu/blob/main/tests/ui/lang/core/mem/create_unitialized_memory.rs

[eddyb]

@NiklasNummelin @LegNeato Sorry I forgot about this, but it looks like the issue here is specifically arrays?

What were you using MaybeUninit for? It looks like .as_mut_ptr() is fine for inline asm! use and we should replace all our indirect-asm!-result patterns with it.

EDIT: oh, I see, MaybeUninit<T> works already when T is an integer/float/pointer, because it bypasses the general case, will still need to implement the general case.

[eddyb]

This PR has a fix (in its first commit) for unions that should handle all possible MaybeUninit<T>s:

• inline asm!: ban OpReturn/OpReturnValue (they're always UB). #1006

However, I haven't added tests, or even tried it out beyond the spirv_std changes, so even after that lands, this issue would be tracking making sure @NiklasNummelin's original usecase is addressed.

[eddyb]

Haven't looked into reproducing this yet but it's very likely that MaybeUninit<&[T]> (and scalar pairs in general) has a different layout than &[T], which seems to be negatively impacting #1014.

It might be fine for fixed-length arrays, so your original usecase is probably fine, but TypedBuffer kind of needs to work with slices to be maximally useful.

[rust-gpu-bot]

This issue is now being tracked at: Rust-GPU/rust-gpu#98