* Expose `FramebufferCreateInfo::attachment_count` builder for `IMAGELESS`
Don't omit the `attachment_count()` builder method, because it is valid
to set the number of attachments without providing attachments in the
`IMAGELESS` case.
Also change the generator array lookup to use the name of the count
field that is allowed to have a builder method, rather than the name of
the field that would use this as `len` field and hence cause it to be
skipped.
* Clean up clones
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
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.
* 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
`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.
