It is undefined behaviour to construct a safe object by calling
`MaybeUninit::assume_init()` when the object in question hasn't been
initialized by anything (in this case the underlying Vulkan call) at
all, even if the object is never "used". Postpone the `assume_init()`
call until after checking if `vk::Result::SUCCESS` has been returned by
the native implementation, by introducing a new
`assume_init_on_success()` helper that takes a `MaybeUninit<T>`.
Prepare the generator for more struct fields that have nested "dynamic
arrays" with a hardcoded size of `1` (effectively arrays with pointers
to single objects) in `vk.xml`s `len` attribute. These structs are
introduced by `VK_EXT_opacity_micromap` in 1.3.230.
* ash-window: Upgrade to raw-window-handle 0.5.0
* Bump `raw-window-metal` to recently-released `0.3`
https://github.com/norse-rs/raw-window-metal/pull/5
* examples: Bump `winit` to `0.27.1` to resolve our MSRV tests
While the examples technically aren't part of our MSRV requirement (it's
nice, but core crate compatibility is much more important), it's
annoying to exempt these especially now that `winit` removed some
unneeded MSRV 1.60/1.61 requirements.
* Take `Raw{Display,Window}Handle` directly instead of through trait
* Update Vulkan-Headers to 1.3.220
* Update Vulkan-Headers to 1.3.221
* Update Vulkan-Headers to 1.3.222
* Update Vulkan-Headers to 1.3.223
* Update Vulkan-Headers to 1.3.224
* Update Vulkan-Headers to 1.3.225
* Update Vulkan-Headers to 1.3.226
* Update Vulkan-Headers to 1.3.227
* Update Vulkan-Headers to 1.3.228
* ash: Add `const STRUCTURE_TYPE` to all Vulkan structures for matching with `match_struct!` macro
In Vulkan layers extracing a structure based on its `s_type` is a common
operation, but comparing against an enum value and subsequently casting
to the right type is verbose and error-prone.
By generating a `const STRUCTURE_TYPE` with the given value for every
Vulkan structure it becomes possible to implement a macro that abstracts
this logic away in a safer way.
* generator: Reuse `HasStructureType::STRUCTURE_TYPE` in `s_type` initializer
The match arms are not guarded by `cfg` anymore, allowing us to
compile-test these simple arms on every system whenever our Ash
extension helpers and types are not guarded by `cfg` attributes either.
This applies to every platform except Mac/IOS where the symbols and
external raw-window-metal crate are themselves guarded by cfg's.
A slice is designed to be a cheap view into a continuous segment of
memory and easily recreated with a different offset and size. This can
be used to our advantage to let the user set exactly how many items they
want to request, while ensuring all returned slots are filled on success
or otherwise return `NOT_READY` if not enough query results could be
copied to user memory (or block if the `WAIT` flag is set).
This also opens the door to accepting `MaybeUninit` in the future and
returning the initialized slice in the `VkResult::Ok(here)` case.
We already ship both license files in the published crate, have both
licenses listed in the `README`, and even `ash-window` already lists
both in `Cargo.toml`.
I found this while experimenting with shields.io badges, as there's a
special link that scrapes the license straight off of crates.io:
https://img.shields.io/crates/l/ash (and many more). This might've been
nice to use except that it's outdated until we publish the next release,
and doesn't allow a nice link to either `LICENSE-XXX` file that we have
now.
* Update Vulkan-Headers to 1.3.212
* Update Vulkan-Headers to 1.3.213
* Update Vulkan-Headers to 1.3.214
* Update Vulkan-Headers to 1.3.215
* Update Vulkan-Headers to 1.3.216
* Update Vulkan-Headers to 1.3.217
* Update Vulkan-Headers to 1.3.218
* Update Vulkan-Headers to 1.3.219
* Changelog: reorder entries chronologically based on PR ID
* extensions/khr: Reorder `Swapchain` functions to match `KhrSwapchainFn`
* extensions/khr: Implement additional `Swapchain` functions since Vulkan 1.1
These are also made available by `VK_KHR_device_group` when
`VK_KHR_swapchain` (and for certain functions only the underlying
`VK_KHR_surface` extension) is enabled.
* Error: vkCreateDevice: VK_KHR_portability_subset must be enabled [...]
* Error: Attempting to create a VkDevice from a VkPhysicalDevice which is from a portability driver without the VK_INSTANCE_CREATE_ENUMERATE_PORTABILITY_BIT_KHR bit in the VkInstanceCreateInfo flags being set and the VK_KHR_portability_enumeration extension enabled.
`_` as prefix is intended for unused variables and bindings; it should
be used in suffix position when intending to prevent a clash with a
keyword instead.
On certain platforms including Android and `aarch64` `c_char` is
unsigned, resulting in the same `u8` type as the byte-string here making
the cast redundant.
Just like any other code calling `get_instance_proc_addr`, use
`CStr::from_bytes_with_nul_unchecked` which abstracts away any
pointer-cast.
8dd682b ("Update Vulkan-Headers to 1.3.210 (#605)") wasn't based off of
the most recent master containing generator updates, leading to obvious
changes missing in generated output.
[#590] introduced an unsuspecting MSRV bump. While we're pro-ba-bly
fine having these at the benefit of better code (in this case more
appropriate `const` annotations), they should at least be clear to us
when merging through a CI failure (or up-front bump of this version in
the CI script). At the same time setting [`rust-version` in
`Cargo.toml`] provides a more helpful "requires newer rustc" error
message (since Rust 1.56.0) instead of showing potentially tons of
irrelevant compile errors in this crate to the user.
[#590]: https://github.com/MaikKlein/ash/pull/590
[`rust-version` in `Cargo.toml`]: https://doc.rust-lang.org/cargo/reference/manifest.html?highlight=pack#the-rust-version-field
* Omit wrapper functions on Fp structs
These wrappers contributed thousands of lines of code but offered
insignificant ergonomic benefit as the same functions are also wrapped
at a higher level and, if necessary, wrapper functions can be called
directly.
* Standardize on direct fp table access in wrapper functions
