* 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.
The `all()` function only represents bitflags known in the core of
Vulkan; it omits all bits added by extensions making this function
unrepresentative and has hence been scheduled for removal for quite some
time to get rid of the confusion it causes.
Alternatively the generator could be taught to collect bitflags added by
extensions, but new extensions get added over time skewing available
values in ash versus the current driver/environment. This makes the
value from `all()` unreliable and fragile at best.
`-` and `-=` (`sub()` and `sub_assign()`) are also controversial by
nature since the underlying value represents an integer but the
implemented math uses bitwise operators. This is a confusing design
pattern and the caller better replaces their uses - if any at all - with
`foo &= !BAR`.
* Update Vulkan-Headers to 1.2.192
* Update Vulkan-Headers to 1.2.193
* Update Vulkan-Headers to 1.2.194
* Update Vulkan-Headers to 1.2.195
Includes the new VK_EXT_rgba10x6_formats, VK_KHR_format_feature_flags2
and VK_KHR_maintenance4 extensions.
* Update Vulkan-Headers to 1.2.196
Includes Vulkan-Headers fixup commit with the missing h265 encode
header.
* Update Vulkan-Headers to 1.2.197
* Update Vulkan-Headers to 1.2.198
* generator: Use `Self` instead of `$name` in macros
Saves a bit of unnecessary expansion inside the macro.
* Fix remaining violations of clippy::use_self in generated code
* generator: Remove unnecessary match on reference type
* ash: Exclude static `vk.rs` from the generator
Much like `platform_types.rs` `vk.rs` does not contain any generated
code that depends on `Vulkan-Headers`' `vk.xml`, making it easier to
just keep this file manually editable.
* Add Packed24_8 helper-type for constructing AS Instance bitfields
* Update Vulkan-Headers to 1.2.187; drop Video enum-variant edgecases
* Update Vulkan-Headers to 1.2.188
* generator: Improve support for pointers to static-sized arrays
Vulkan 1.2.188 removed the only occurence of `ename:`, which was our
heuristic to find a type that's a pointer to a static-sized array. It
is now replaced with a "normal" `latexmath:` expression, but should
still be dealt with appropriately.
Note that all `latexmath:` conditions have been removed, as these fields
should not be silently omitted. As of this Vulkan version only 3 exist,
and all have their own edge-case.
* Revert "Remove upstream-fixed vk_platform.h header path fallback"
This reverts commit 43dee26ec04dfd3871da8a11b624eaf9fbd16f3a.
Upstream is reverting back to inconsistent paths in [this commit] to
counter unintentional header `#include` changes on the C-side:
https://github.com/KhronosGroup/Vulkan-Docs/issues/1573
[this commit]: 8bde11cbd7
* generator: Remove unnecessary `-Iinclude/vulkan` directory
Every `#include` path (except `"vk_platform.h"`, see previous commit) is
relative to the `include/` directory or the current file, and does not
look for a path relative to `include/vulkan/`.
* Update Vulkan-Headers to 1.2.189
* Update Vulkan-Headers to 1.2.190
* Update Vulkan-Headers to 1.2.191
* Update Vulkan-Headers to 1.2.176
* Update Vulkan-Headers to 1.2.177
* Update Vulkan-Headers to 1.2.178
This requires `len="null-terminated"` to be added to
`VkCuFunctionCreateInfoNVX::pName` in `vk.xml`.
* Update Vulkan-Headers to 1.2.179
* Update Vulkan-Headers to 1.2.181
Skipping 1.2.180 due to missing VkPipelineLayoutCreateFlagBits, which is
defined now.
* push_next and Extends traits are generated for all root structs.
root structs are now all structs that are extended by other structs!
root structs used to be all structs that don't extend any other structs.
* the root_structs local variable that is passed around is now a set of Ident (and no String).
fixes https://github.com/MaikKlein/ash/issues/229
* generator: Add edegecases for broken Video extension enum variants
* Replace deprecated `make_version()` with `make_api_version()`
* generator: Use the same predicate for push_next and its traits
Some structs turn out to be root structs when their name is not in the
`root_structs` set, even when they themselves extend another struct.
This was already taken care of for `push_next` which is emitted in this
situation, but the trait referenced by `push_next`'s `T` bound is still
relying on the `extends` field to not exist in `vk.xml` at all, leading
to it not being generated despite `push_next` needing it.
Fixes: 215511f ("Implement ExtendXXX for multiple root create infos if
there are more than 1")
* Update Vulkan-Headers to 12.175
* generator: Generate low-level structs with bindgen (for vk_video)
* generator: Emit deprecation warnings and documentation link for defines
* generator: Parse and autogenerate version-related defines
With more and more version-related defines showing up this saves us a
bunch of time.
* generator: Untangle mismatched parameter/return fn signatures in types
With function typedefs for commands having some elements filtered out
(by name) if they were previously defined already, combined with
unfiltered arrays containing the parameter sets and return type for
_all_ commands expanded together in `quote!` macros the wrong array
elements get combined resulting in incorrect signatures. No-one seems
to use function pointer types (but we should!) which is why this has
gone unnoticed for some time.
* generator: Derive clone for function pointers instead of generating it
* generator: Regroup token generation per command instead of across arrays
This complements the previous commit by avoiding mismatches in array
content altogether, instead of expanding multiple arrays within a single
`#()*` quote expression and assuming they all contain the same data in
the same order, reducing cognitive overhead while reading this code.
Rusty wrappers are already marked `unsafe`, and by definition the raw
Vulkan function pointers used under the hood are `unsafe` too. Not
needing `unsafe` when going directly through `self.fp_v1_x()` is odd at
best.
* generator: Simplify contains+insert pairs to just insert()
Insert returns true when the value was inserted, false when it was
already present in the set.
* generator: Strictify "Vk"/"vk" prefix stripping with strip_prefix+unwrap
This way we are sure only the expected prefix ("Vk" or "vk") is
stripped, anything else panics the generator.
* generator: `format_ident` can format strings directly
As per [1] no explicit length field is available for `pSampleMask`, this
is based on `ceil(rasterizationSamples/32)` instead. It is valid to not
set an array for `pSampleMask` (under normal circumestances this is
signaled by setting the length to zero, and the array pointer is
ignored) but this has to happen by setting the pointer to `NULL`.
[1]: https://github.com/MaikKlein/ash/issues/256
Following [1] a stable release including the fixed commit has been made;
we can now depend on the released crate version again. This also
includes support for all new fields up to Vulkan 1.2.176.
[1]: https://github.com/krolli/vk-parse/issues/18#issuecomment-837815599
* 1.2.171 new types
* generator: Keep platform_types checked in to git only
This static content is better kept in the platform_types.rs file only,
where it can be edited directly.
(Perhaps we should be more clear about generated versus manual files
within the ash crate, by storing generated outputs in an auto/
module/subdirectory that is reexported, like glib and friends?)
* Update Vulkan-Headers to 12.171
* Update Vulkan-Headers to 12.172
* Update Vulkan-Headers to 12.173
* Update Vulkan-Headers to 12.174
* generator: Generalize C number parsing
Co-authored-by: caradhras11@gmail.com <caradhras11@gmail.com>
* Update Vulkan-Headers to 1.2.169
* generator: Add support for vkFlags64
Since Vulkan-Headers v1.2.170 with VK_KHR_synchronization2 there are now
bitmasks/enums using 64-bits instead of the default 32. vk-parse has
been updated to convey this info though the typedefs for these
enumerations could be parsed as well.
* generator: Insert underscores before trailing type number
Enum types like `VkAccessFlags2KHR` are turned into `VK_ACCESS2` after
demangling and `SHOUTY_SNAKE_CASE` conversion by Heck, but the enum
variants for the type start with `VK_ACCESS_2` (or similar) which fails
the `strip_suffix` and leads to long names to show up.
Inserting an underscore here makes sure the match succeeds.
* Update Vulkan-Headers to 12.170
* generator: Add Intel to the list of vendors for enum-postfix-stripping
* generator: Fortify enum-variant type prefix stripping
As brought up in [1] a new enum variant "pattern" not dealth with by our
type-prefix stripper went silently unnoticed. Explicitly listing the
few misnamed enum variants and panicking otherwise makes sure this won't
happen again.
[1]: https://github.com/MaikKlein/ash/pull/411#issuecomment-826013950
The docs clearly state:
#[rustc_deprecated(since = "1.42.0", reason = "use the Display impl or to_string()")]
fn description(&self) -> &str {
"description() is deprecated; use Display"
}
We already have a `Display` implementation containing an identical
`match` block and has further improvements on the way in [1].
[1]: https://github.com/MaikKlein/ash/pull/424
Previously, the `Display` impl for `vk::Result` did not include handling
for extension values. For example, `VK_ERROR_OUT_OF_DATE_KHR` would
display simply as `"-1000001004"`. Now, we fall back to the `Debug` impl
of the `Result` if the value is unknown (i.e. from an extension). This
preserves the current nice messages for non-extension values, and the
numeric output for truly unknown values, but displays the enum variant
name (e.g. `"ERROR_OUT_OF_DATE"`) for extension values.
* generator: Generate enums from vk_parse representation
This change prepares for future additions in vk_parse fields ([1]) by
converting over the enum generation path from vkxml. Most of the
conversion is easy by repurposing the existing `EnumSpec` parsing logic
from extension constants for all enumeration variants, with slight
modifications to not bail when `extends` is not set which is specific to
extension constants.
As an (unintended) added bonus this unification of the `EnumSpec`
codepath allows aliases (for backwards-compatible names) to be generated
as discussed earlier in [2].
[1]: https://github.com/krolli/vk-parse/pull/17
[2]: https://github.com/MaikKlein/ash/pull/384#discussion_r588693967
* generator: Turn "backwards"-mentioning docs into deprecation notices
All constant aliases for misspelled items (missing `_BIT` andsoforth)
contain the text "backwards compatibility" or "Backwards-compatible
alias".
* generator: Drop aliases whose name becomes identical after de-mangling
* generator: Remove aliases from const_debugs
These already have a match against the name they're aliasing, and some
of the aliases are "deprecated" (since they're just typo fixups for
backwards compatibility).
* generator: Only replace "VK_" at the start of enum variant names
Replacing the occurence of "VK" is dangerous as shown by this diff; MVK
shorthands for MoltenVK are accidentally mangled. Using
strip_prefix/suffix is not only more correct and performs more runtime
checks, it is also more performant by returning a slice into the string.
* generator: Correct duplicate suffix stripping
The original `.replace(vendor, "")` operation and `.trim_end_matches`
replace every (trailing) occurence of the vendor, causing
DEBUG_REPORT_CALLBACK_EXT_EXT to end up without `_EXT` at all. This name
is also provided by vk.xml as fallback alias because it is used but
technically incorrect; the current generator can however not generate it
(limitation in vkxml representation).
Constants (enumeration bitflags) containing the word `external` were not
stripped of their common typename, and quick debugging showed the word
`VKTERNAL_...` in `struct_name`. `_EXT` would be the first extension to
match in `VK_EXTERNAL_...` messing up `struct_name` with a global
`.replace`, in turn not removing it from the variant name.
CString::new needs to perform an allocation to own the `&'static str`
and append a NULL byte to it. We can instead perform this "allocation"
in the generator and emit a byte-string literal with trailing NULL byte
that can immediately be used by the function loader.
