Some users are confused by seeing wildly different output after running
the generator, which is simply solved by running `rustfmt`. As this is
both confusing and "somewhat" slow, invoke `rustfmt` directly within the
generator by piping string contents through it before redirecting to
disk. This not only makes the output consistent, it is the fastest way
to reformat generator changes by omitting the round-trip to disk
entirely, nor having `rustfmt` recursively go through the workspace and
all files (including those that are not generated).
On a many-core machine these times are a bit skewed, but I want to
include them to prove the "speed" point nevertheless, even if simplicity
and consistency is the main reason to make this change:
Before:
time ./target/debug/generator && time cargo fmt --all
./target/debug/generator 3.51s user 1.25s system 99% cpu 4.769 total
cargo fmt --all 0.79s user 0.06s system 99% cpu 0.853 total
After:
time ./target/debug/generator
./target/debug/generator 4.51s user 0.41s system 99% cpu 4.931 total
There's no reason to use these steps anymore: besides being old,
unmaintained, and spitting out NodeJS deprecation warnings, GitHub's
`runner-images` come preloaded with all Rust tools and components we
need, and the syntax to run commands is more efficient, much shorter and
more apprehensible by simply matching what we'd use on our own
command-line, too.
Turns out we were doing the wrong thing for the right reason: the
`aliases` here aren't `vk.xml` aliases: they are renames. When
generating function pointers for extensions, a list of command
_definitions_ is collected, which can only ever be "root" `command`s.
Extensions typically reference stabilized `command`s under an alias with
the vendor tag suffixed, which the `Fn` struct field name is renamed to
using this `aliases` - now replaced with `rename_commands` - list, while
generating the rest of the "function pointer" command bits using the
"root" `command` (as this mostly pertains the parameters and return
type). With that explanation it becomes clear why
`generate_extension_commands()` was creating an "alias" mapping from
stabilized name to vendor-suffixed extension name, and calls
`generate_function_pointers()` with that mapping - and a list of
stabilized/root `command`s - rather than passing `cmd_aliases` directly.
(This `cmd_aliases` list exists because the rename always happens in the
root `<commands>` element: extensions then `<require>` the aliased
rather than the stabilized name, so the base for this alias is found
first to look up the base command, and then stored in `rename_commands`
to rename it back to the aliased name).
With improved clarity we can now also borrow the name strings rather
than cloning them in many places.
Somehow this stuck along when we removed all the other deprecated
aliases, because the comment annotation didn't match up with what was
normally used (but we did write a special `#[deprecated = ..]`
annotation based on `"Alias"`). Now that this all has been normalized
in `vk.xml` behind a standardized `deprecated="reason"` attribute we
have to go out of our way to keep this constant alias alive.
* Update Vulkan-Headers to 1.3.239
* Update Vulkan-Headers to 1.3.240
* Upgrade to `bindgen 0.63` and `vk-parse 0.9`
Updates cause no semantic changes in usage nor generated output.
* generator: Support new `deprecated` attribute
* Update Vulkan-Headers to 1.3.241
* generator: Emit `#[deprecated]` annotation for type members (struct fields)
* Update Vulkan-Headers to 1.3.242
* Update Vulkan-Headers to 1.3.243
* Update Vulkan-Headers to 1.3.244
For the upcoming `api` attribute in `vk.xml` commands also need to be
processed through `vk-parse` which has support for all the new
attributes, while `vkxml` is deprecated and completely untouched for
years. This conversion unfortunately requires whipping up yet another
quick-and-dirty `nom` parser of a specific subset of C used in `vk.xml`
to describe parameter signatures. This PR shows that conversion is
complete and provides no accidental semantic differences.
Also update `vk-parse` to `0.9` which contains a new `code` field on
`CommandParam` (`<param>` element) to be able to inspect the code
signature of individual parameters rather than parsing them out of (and
matching them back to `vk-parse`'s `params` array!) the `<command>`
/ `CommandDefinition` as a whole:
https://github.com/krolli/vk-parse/issues/25#issuecomment-1246330001615ffb69eb
`raw-window-handle 0.5.1` bumped from 1.60 to 1.64 in a
semver-compatible release, failing our CI infrastructure overnight.
Keep the `ash` version at `1.60` for now.
For upcoming `vk.xml` features (the new `api` attribute) some of our
codegen has to be converted to work on `vk-parse` types to make this
ergonomic (and there's a longstanding plan of factoring out `vkxml`
regardless). Start with converting the `#define` code and showcasing
that it does not affect the output (beyond removing the unneeded
edgecase for `VK_HEADER_VERSION` resulting in a doc link).
An upcoming extension will ship with an untyped `pCode` member (`void
*`) including a valid `len` field pointing to a `codeSize` field rather
than obscure Latex math and a `/4` expression in `altlen`. Limit the
scope of our workaround for that SPIR-V-specific `pCode` field to
`VkShaderModuleCreateInfo`.
Strangely some no-op cast remained in the codebase, and are only now
caught since Rust 1.66. In both cases the input value is already of the
correct type (independent of the platform).
Rustdoc since 1.66 points out that `<<ref>>` is malformed HTML, and the
resulting `<<devsandqueues-lost-device>>` isn't very helpful to users.
Convert it to the relevant link in both documentation and `Result`
`Display` to solve both issues at once.
The entire reason for calling `unsafe` `set_len()` after the Vulkan
driver function call is to ensure the `Vec` never gives safe access to
uninitialized values (as allocted via `Vec::with_capacity()`). This
contract is broken within the implementation of these functions by
temporarily setting a nonzero length when the Vulkan driver may not have
initialized the underlying data at all, and communicated this by
returning an error code.
Simply check the error code first, before jumping to a now-infallible
codepath that calls `.set_len()` and always returns `Ok()`.
* Update Vulkan-Headers to 1.3.229
* Update Vulkan-Headers to 1.3.230
* Update Vulkan-Headers to 1.3.231
* Update Vulkan-Headers to 1.3.232
* Update Vulkan-Headers to 1.3.233
* Update Vulkan-Headers to 1.3.235
* README: Document experimental Vulkan Video bindings being semver-exempt
`.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.
