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.
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.
[#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
* Constify generated extension names
* Constify hand-written extension names
* Make ash-window list extensions as &[*const c_char]
This alters enumerate_required_extensions() to return the same type that
is expected by vk::InstanceCreateInfoBuilder::enabled_extension_names(),
allowing simple Vulkan apps to omit the boilerplate of mapping to an
intermediate Vec<*const c_char>.
Co-authored-by: Steve Wooster <s.f.m.wooster@gmail.com>
