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
`CStr::from_bytes_with_nul_unchecked` is `const`-stable since Rust 1.59
which is already required for `ash` so it is high time to finally turn
these inlined `name()` functions into associated constants (which is a
breaking change in itself that cannot be backported).
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`.
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.
It is unlikely that disabled, reserved extensions (without naming
whatsoever) are used through Ash bindings generated from Vulkan-Headers
releases, and are best ignored to reduce diff noise and spurious issues
[1] with unfinished extension definitions.
This approach matches what is defined in the registry spec for
`supported="disabled"` [2]:
use `supported="disabled"` to indicate this extension should never
be processed.
[1]: https://github.com/KhronosGroup/Vulkan-Docs/issues/1549
[2]: b4e8cd820b/registry.txt (L1302-L1306)
* 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.
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.
* 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
* 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
`_` 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.
* 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>
* Unnest iterators
This hopefully makes the iterator definitions better resemble paths into
the XML tree.
* Use for-loop instead of .for_each()
* Use elems.contains(x) instead of elems.iter().any(...)
* Shrink commands-related .fold()
Co-authored-by: Steve Wooster <s.f.m.wooster@gmail.com>
* Simplify .map().flatten().next() and .filter_map().next() to .find_map()
* Avoid unnecessary closures for cheap expressions
* Use character instead of string for replacement pattern
Co-authored-by: Steve Wooster <s.f.m.wooster@gmail.com>
While making the code only marginally harder to read such casts can also
introduce subtle bugs when used incorrectly, and are best omitted
whenever unnecessary: Rust already coerces borrows into raw pointers
when the types on both ends are clear, and even then there remain many
casts that are identical to the source type.
In addition these errors show up when using a local crate reference to
`ash` in a workspace that uses "the `.cargo/config.toml` setup" from
[EmbarkStudios/rust-ecosystem#68] to configure linter warnings
project-wide instead of for all crates in that workspace individually.
In our case aforementioned linter warnings are enabled on top of
Embark's configuration, leading to a lot of these warnings in our build
process.
[EmbarkStudios/rust-ecosystem#68]: https://github.com/EmbarkStudios/rust-ecosystem/pull/68
Much like `platform_types.rs` and `vk.rs` before, there is no need to
generate this file as its contents are completely static. This allows
direct editing of the file without realizing that a copy lives in the
generator - and will overwrite `macros.rs` when the generator is being
run.
This name is emitted by the generator and already known to not contain
any null-characters: replace the runtime iteration+comparison (hidden
behind `from_bytes_with_nul`) and `.expect()` panic with an `unsafe`
"cast" through `from_bytes_with_nul_unchecked`, just like the
function-pointer loaders.
Instead of generating an impl block - together with "Generated from XXX"
doc - for every single item that extends an enum type, group all these
extensions together in a single `impl` block per extension per type.
This cuts down a couple thousand lines of repeated `impl T` and `#[doc]`
annotations, and makes the code more readable at the same time: it is
now possible to immediately see exactly all the constants that a certain
extension extends a type with.
Back when we were still trying to come up with sensible names for
"deprecated" aliases (initially introduced as self-supporting constants)
that don't adhere to the naming standard but only remain to exist for
backwards compatibility, some of these aliases would get the same name
as the enum constant they were aliasing, resulting in (compile-time)
conflicts.
Now that all those aliases are simply not generated anymore (end-users
should just pick the properly named variant) it is not necessary to
check for and prevent these conflicts on the generator side anymore.
`constants` is iterated twice here: once with a filter, the other time
without, and the results are zipped together. Besides being able to
simplify the entire execution to just one `iter()` without intermediary
iterators, removing `.zip()` makes it impossible for the results in both
iterators to get mismatched when the `filter` inevitably skips elements.
Fortunately no such cases seem to exist, or at least not that effect the
resulting generated code.
Some clippy lint long ago apparently suggested to explicitly specify a
type for all random generators in 8550683 ("Address all the clippy lints
(#233)"), so the `impl BuildHasher` trait was apparently passed as a
placeholder for the `RandomState` default that's selected.
This does not serve any purpose and that (likely bogus) clippy warning
no longer shows up, making it safe to remove the trait.
vk.xml now contains the comment text "Backwards-compatible alias
containing a typo" which we can use to detect intentional renames,
without needing to specify explicit overrides/exceptions in the
generator anymore.
These deprecated constants exist for the sole reason of backwards
compatibility which Vulkan cannot permit itself to remove in the C
headers, but are unreasonable for crate authors to use anyway due to
their `#[deprecated]` annotation whose cargo-check warnings are easy to
fix by just using the non-deprecated variant instead. Furthermore, Ash
is still allowing itself to perform breaking changes in its releases
making this the perfect time to get rid of all these useless variants
and the generator support code that comes with it. No need to come up
with a "more proper" variant name if we don't generate those that
"intentionally" fail to adhere to the "enum variant name" specification
in the first place.
