`.cast()` allows changing the pointer type without hiding (accidental)
mutability changes (noting that `*mut` still coerces to `*.const`).
For mutability changes Rust 1.65 included `cast_mut()` and
`cast_const()`, but those would bump our MSRV too eagerly for now.
`bytemuck` recently bumped its MSRV to 1.60 which is incompatible with
what we're currently advertising. Fortunately this doesn't affect MSRV
of the publicly published crates, but only `dev-dependencies` inside
`ash-window` via `winit`: make sure the CI doesn't reject this.
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
