update OpenXR-SDK to 1.0.25

[kcking]

fixes macOS build with KhronosGroup/OpenXR-SDK-Source#323

[Ralith]

Thanks! Want to run the generator for the update too?

[kcking]

Ah yes that was too easy... 😅 forgot about the generator.

@Ralith I added two commits to fix the build errors, except that VkImageCreateFlags and VkImageUsageFlags are undefined. It appears OpenXR-SDK assumes these are imported from vulkan.h. ash is currently a dependency of openxr but not sys. Should I add ash as a dep of sys and either 1) typedef or 2) substitute those types for the associated ash::vk:: types?

[Ralith]

No, ash should not be a dependency of either crate. The new Vulkan types should be handled consistently with the existing ones, by transcribing the bare minimum representation into sys/src/platform.rs. This ensures we don't break every time ash updates.

Generating atom definitions automatically is nice, but should probably be pursued in a separate PR. Note that we currently have handwritten definitions for most of them in sys/src/lib.rs.

[kcking]

Great, thanks for the comments! Latest version now pushed.
I have it down to some new FB spatial anchor/Space struct issues.

1. they use a UuidEXT struct that holds a 32-byte array. should we create a wrapper for this, or just export it as-is? If users wanted to manipulate the UUIDs instead of just using them as opaque handles, passing them to the uuid crate seems easy enough. UuidEXT currently fails the && x.static_array_len.is_none() check of is_simple_struct.
2. some generated struct wrappers like SpaceQueryCompleteFB turn XrResult into Result which is then conflicting with std::Result. do we have an existing solution for this? should we be mapping XrResult to Result<()>?

Thanks for your help!

[kcking]

Applied work-arounds for both of the above issues, let me what you think :)

[Ralith]

Thanks!

[Ralith]

Published in v0.17.1.