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
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.
* 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.
