Even though we don't have many dependencies, our GitHub Actions are
getting severely out of date and are best updated to the latest version.
Let dependabot help us with this, together with the few `cargo` crate
dependencies that we have (mainly in examples).
This parameter is not only used for the length of `pImageInfo`,
`pBufferInfo` or `pTexelBufferView`, but also matching the value
of `dataSize` when `VkWriteDescriptorSetInlineUniformBlock` is
appended in `pNext`, or the value of `accelerationStructureCount`
when `VkWriteDescriptorSetAccelerationStructureKHR` is in `pNext`.
Having the count setter directly avaialble makes builder code more
natural, instead of having to use a `mut` variable and manually assign
`.descriptor_count = xx.len();` afterwards.
https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkWriteDescriptorSet.html
* generator: Add many missing lifetime parameters
* Globally find-replace common patterns that need a `<'_>` lifetime annotation
perl -pi -E "s/(&(mut )?\[?vk::(?\!\w+(V1_\d|Fn|<))\w+)/\$1<'_>/" **/*.{rs,md}
* generator: Include aliased types in `has_lifetime` lookup table
* Manually revert wrong find-replace lifetimes
* Resolve lint warnings for `deprecated_in_future`, `rust_2018_idioms` and `unused_qualifications`
These are 3 non-default lints that cause a lot of violations in this
project that are sensible to resolve, and reduce noise when
test-including a local `ash` checkout in other projects that have
stricter lint setups.
* CI: Cross-lint for Mac, iOS and Windows
We have some conditional code specific to Mac and iOS which is currently
untested in the CI, allowing non-compiling code in PRs like #795 to go
unnoticed.
* Fix new clippy lints
* Update Vulkan-Headers to 1.3.255
* Update Vulkan-Headers to 1.3.257
* Update Vulkan-Headers to 1.3.258
* Update Vulkan-Headers to 1.3.259
* Update Vulkan-Headers to 1.3.260
* Update Vulkan-Headers to 1.3.252
* Update Vulkan-Headers to 1.3.253
* Update Vulkan-Headers to 1.3.254
* vk/platform_types: Add `_screen_buffer` type for QNX
Ash doesn't implement `Drop` intentionally, to not be too opinionated
about holding (heap) references to their parent objects
(`Device`->`Instance`->`Entry`) and ensuring they are destroyed in the
right order. As such, reword the `create` documentation for `Instance`
and `Device` to mention their respective `destroy_*` function instead of
referring to them as being "droppable".
Note that `Entry` is droppable as it does not have a Vulkan `destroy`
function _and_ the dynamically loaded library (behind the "loaded"
feature) is kept alive only for the lifetime of `Entry`.
* Update Vulkan-Headers to 1.3.247
* Update Vulkan-Headers to 1.3.248
* Update Vulkan-Headers to 1.3.249
* Update Vulkan-Headers to 1.3.250
* Update Vulkan-Headers to 1.3.251
We don't mark any of the extern calls to Vulkan function-pointers safe
except for a few `Entry` functions. Their safety contract was easy to
validate, but now that we exposed a constructor function to let the user
provide function pointers in the form of `Entry::from_parts_1_1()` it is
no longer safe to assume that we are calling the function that adheres
to the contract specified in the Vulkan reference.
Because we don't rigorously do this validation and safe-marking anywhere
else either, mark these function calls as `unsafe`.
Related discussion chain: https://github.com/ash-rs/ash/pull/748#discussion_r1186794284
* ash/device: Allow building device from handle+fns
Adds a constructor to build a device from a handle + functions.
Helps with interoperability with other vulkan wrappers
* ash/instance: Allow building instance from handle+fns
Adds a constructor to build an instance from a handle + functions.
Helps with interoperability with other vulkan wrappers
* ash/entry: Allow building entry from handle+fns
Adds a constructor to build an entry from a handle + functions.
Helps with interoperability with other vulkan wrappers
* changelog: Document #748 addition of `from_parts` constructors
Generate templated builder setters for fields taking an `objecttype`
We already do this for hand-written extension functions but can now also
implement it for setters since `vk_parse` fields are available within
the builder generator code: when a field refers to another field for
setting its `objecttype`, that `VkObjectType` field setter is omitted
and instead assigned when the object is set, based on a type generic
that implements the `Handle` trait instead of an untyped `u64`.
These functions don't contribute anything and should be removed to clean
up the `features` and `extensions` files, while now also not showing in
the documentation anymore. The structs remain in place for associated
constants but are replaced with true unit-like structs (no curly
brackets anymore), and unneeded `unsafe impl Send/Sync` are removed as
well.
As these `load()` functions have been removed from the empty
feature-levels on `Entry` and `Device` as well, rather than
instantiating the unit structs and returning those the fields and
`fp_vX_X()` getters have been removed entirely.
Xlib defines `Display` as follows:
typedef struct _XDisplay Display;
And then always references this type as a pointer to it, e.g. `Display
*`. The same happens in `ash`, where `Display` is only ever referenced
as a raw pointer via `*mut Display`, so making `Display` itself a type
alias to `*mut c_void` is wrong and confusing. Switch it back to a
`c_void` to match the forward-declared (but otherwise undefined) `struct
_XDisplay`.
Looks like #630 typo'd the argument for `DeviceGroupCreation::new()` by
unnecessarily requiring a move (`Clone`) of `Entry` just to call
`get_instance_proc_addr()` on it. Replace this with a borrow to match
all other extensions.
* extensions/khr: Take the remaining `p_next`-containing structs as `&mut`
Version 2 of `get_physical_device_surface_capabilities` and the matching
`vk::SurfaceCapabilitiesKHR` struct exist solely to provide an `sType`
and `pNext` field to allow extending the original query with additional
data via extension structs. However, this API when introduced in #530
only returns the `default()`-initialized struct making it just as
constrained as `get_physical_device_surface_capabilities()`. Solve this
by taking `vk::SurfaceCapabilities2KHR` as `&mut` just like any similar
API.
And just like this, do the same for the remaining:
- `AccelerationStructure::get_acceleration_structure_build_sizes()`
- `ExternalMemoryFd::get_memory_fd_properties()`
- `ExternalMemoryWin32::get_memory_win32_handle_properties()`
In case these structs get extended somewhere down the line, which the
Vulkan API allows for.
* extensions/khr/acceleration_structure: Use `mem::zeroed()` in place of `vk::AccelerationStructureCompatibilityKHR::default()`
* 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
* README: Autoformat
* README: Remove deprecated `builder()` snippets and guidelines
#602 introduced builder functions directly on the raw Vulkan struct
types by using lifetime borrows which are FFI compatible (ABI is
identical) wuth raw pointers, simplifying the whole system and
protecting the user against losing lifetimes upon calling `.build()`.
However, this change wasn't propagated through to the `README` so the
code snippets were still showcasing removed `::builder()` and `.build()`
functions and documenting "the `.build()` footgun" which doesn't even
exist anymore 🎉
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.
