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.
`raw-window-handle 0.5.1` bumped from 1.60 to 1.64 in a
semver-compatible release, failing our CI infrastructure overnight.
Keep the `ash` version at `1.60` for now.
`bytemuck` recently bumped its MSRV to 1.60 which is incompatible with
what we're currently advertising. Fortunately this doesn't affect MSRV
of the publicly published crates, but only `dev-dependencies` inside
`ash-window` via `winit`: make sure the CI doesn't reject this.
[#590] introduced an unsuspecting MSRV bump. While we're pro-ba-bly
fine having these at the benefit of better code (in this case more
appropriate `const` annotations), they should at least be clear to us
when merging through a CI failure (or up-front bump of this version in
the CI script). At the same time setting [`rust-version` in
`Cargo.toml`] provides a more helpful "requires newer rustc" error
message (since Rust 1.56.0) instead of showing potentially tons of
irrelevant compile errors in this crate to the user.
[#590]: https://github.com/MaikKlein/ash/pull/590
[`rust-version` in `Cargo.toml`]: https://doc.rust-lang.org/cargo/reference/manifest.html?highlight=pack#the-rust-version-field
Broken links that snuck in (most recently in #530 and #537) while the
CI was not testing the documentation have also been corrected, to allow
it to succeed again (and to have proper docs in the first place).
With more and more features being added to `ash`, now seems to be the
right time to make sure the crate is clean of clippy warnings when
building without any features in addition to building with the deafult
set of features.
* Mark EntryCustom::new_custom as unsafe
Passing a badly-behaved `load` function can invoke undefined behavior.
* Document required feature for Entry
* Support linking Vulkan directly
This is the preferred pattern in most environments when an application
cannot function without Vulkan, as it saves the libloading dependency,
eliminates an error case, and makes the Vulkan dependency visible to
the OS.
* Rename libloading feature to "loaded"
* Link by default
* Guide users towards linking the loader directly
* Remove unnecessary error type
InstanceError::LoadError was never constructed.
* Unify entry types
Simplifies the interface and allows a bunch of code to become
monomorphic.
* ci: Test docs in addition to `cargo t --all-targets`
Unfortunately docs are not explicitly (build-)tested as part of
`--all-targets` allowing broken code to slip in as shown by #390.
Also remove the `rust` listing type which is the default, leaving only
`no_run` (until the CI has a loadable Vulkan library).
* ash: Fix errors and warnings in (now tested) documentation comments
