This commit updates the allocation scheme for resources in the component
model to start at 1 instead of 0 when communicating with components.
This is an implementation of WebAssembly/component-model#284.
While this broke a number of tests we have this shouldn't actually break
any components in practice. The broken tests were all overly-precise in
their assertions and error messages and this shouldn't idiomatically
come up in any guest language, so this should not be a practically
breaking change.
This change additionally places an upper limit on the maximum
allocatable index at `1 << 30` which is also specified in the above PR.
* better top matter
* eliminate wasi-common deprecations from wasmtime-wasi
* wasmtime-wasi: preview2 feature always enabled, so just eliminate it
* rename preview1-on-preview2 feature to just preview1
* wasi-http fix
* dep fixes. change some log::debug! to tracing::debug!
* mv preview2 up to root
and `sed -i 's/crate::preview2/crate/g' **/*.rs`
* fix tests too
* fixes throughout wasmtime-wasi-http
* cli: s/wasmtime_wasi::preview2/wasmtime_wasi
* rustfmt
* fix wasi-async example
* fix docs build (needs wasi-common built to compile examples)
* c-api: use wasi-common directly
i guess we didnt build the c-api in CI with deprecation warnings denied
prtest:full
* fix example required-features
* fix examples CMakeLists build
By moving the registration count into the `Arc`, that is pulling the `Arc`
outwards from containing just the `WasmFuncType` to the registration count as
well, and turning it into an atomic, we can manipulate the registration count
without a write lock. Once that is done, we have the following:
* `RegisteredType::root` only needs a read lock, not a write lock.
* `RegisteredType::clone`, which used to need a write lock, doesn't need any
locking anymore.
* `RegisteredType::drop` doesn't need any locking most of the time. The
exception is when this is this drop that moves the refcount to zero, in which
case grabbing a write lock is still necessary to remove the type from the
registry.
This avoids locking the type registry to look up function types by
`VMSharedTypeIndex` in calls to `realloc`.
This gives a ~13% speedup to `wasmtime serve`'s requests per second for me
locally.
* Support patchable regions in MachBuffer
* Patch stack size into stack checks once functions have been visited
* Move the stack overflow check into the function prologue
* Start addressing review feedback
* Use an explicit encoding of add for fixing up add-with-immediate
* Track a single stack max addition
* Better comments about `sp_max`
* Fix comments
* Update winch filetest outputs
* Reuse the cranelift implementation of RexFlags
* Update winch/codegen/src/isa/x64/masm.rs
Co-authored-by: Saúl Cabrera <saulecabrera@gmail.com>
---------
Co-authored-by: Saúl Cabrera <saulecabrera@gmail.com>
First of all, thread a "chaos mode" control-plane into Context::optimize
and from there into EgraphPass, OptimizeCtx, and Elaborator.
In this commit we use the control-plane to change the following
behaviors in ways which shouldn't cause incorrect results:
- Dominator-tree block traversal order for both the rule application and
elaboration passes
- Order of evaluating optimization alternatives from `simplify`
- Choose worst values instead of best in each eclass
Co-authored-by: L. Pereira <lpereira@fastly.com>
* Wasmtime: Finish support for the typed function references proposal
While we supported the function references proposal inside Wasm, we didn't
support it on the "outside" in the Wasmtime embedder APIs. So much of the work
here is exposing typed function references, and their type system updates, in
the embedder API. These changes include:
* `ValType::FuncRef` and `ValType::ExternRef` are gone, replaced with the
introduction of the `RefType` and `HeapType` types and a
`ValType::Ref(RefType)` variant.
* `ValType` and `FuncType` no longer implement `Eq` and `PartialEq`. Instead
there are `ValType::matches` and `FuncType::matches` methods which check
directional subtyping. I also added `ValType::eq` and `FuncType::eq` static
methods for the rare case where someone needs to check precise equality, but
that is almost never actually the case, 99.99% of the time you want to check
subtyping.
* There are also public `Val::matches_ty` predicates for checking if a value is
an instance of a type, as well as internal helpers like
`Val::ensure_matches_ty` that return a formatted error if the value does not
match the given type. These helpers are used throughout Wasmtime internals
now.
* There is now a dedicated `wasmtime::Ref` type that represents reference
values. Table operations have been updated to take and return `Ref`s rather
than `Val`s.
Furthermore, this commit also includes type registry changes to correctly manage
lifetimes of types that reference other types. This wasn't previously an issue
because the only thing that could reference types that reference other types was
a Wasm module that added all the types that could reference each other at the
same time and removed them all at the same time. But now that the previously
discussed work to expose these things in the embedder API is done, type lifetime
management in the registry becomes a little trickier because the embedder might
grab a reference to a type that references another type, and then unload the
Wasm module that originally defined that type, but then the user should still be
able use that type and the other types it transtively references. Before, we
were refcounting individual registry entries. Now, we still are refcounting
individual entries, but now we are also accounting for type-to-type references
and adding a new type to the registry will increment the refcounts of each of
the types that it references, and removing a type from the registry will
decrement the refcounts of each of the types it references, and then recursively
(logically, not literally) remove any types whose refcount has now reached zero.
Additionally, this PR adds support for subtyping to `Func::typed`- and
`Func::wrap`-style APIs. For result types, you can always use a supertype of the
WebAssembly function's actual declared return type in `Func::typed`. And for
param types, you can always use a subtype of the Wasm function's actual declared
param type. Doing these things essentially erases information but is always
correct. But additionally, for functions which take a reference to a concrete
type as a parameter, you can also use the concrete type's supertype. Consider a
WebAssembly function that takes a reference to a function with a concrete type:
`(ref null <func type index>)`. In this scenario, there is no static
`wasmtime::Foo` Rust type that corresponds to that particular Wasm-defined
concrete reference type because Wasm modules are loaded dynamically at
runtime. You *could* do `f.typed::<Option<NoFunc>, ()>()`, and while that is
correctly typed and valid, it is often overly restrictive. The only value you
could call the resulting typed function with is the null function reference, but
we'd like to call it with non-null function references that happen to be of the
correct type. Therefore, `f.typed<Option<Func>, ()>()` is also allowed in this
case, even though `Option<Func>` represents `(ref null func)` which is the
supertype, not subtype, of `(ref null <func type index>)`. This does imply some
minimal dynamic type checks in this case, but it is supported for better
ergonomics, to enable passing non-null references into the function.
We can investigate whether it is possible to use generic type parameters and
combinators to define Rust types that precisely match concrete reference types
in future, follow-up pull requests. But for now, we've made things usable, at
least.
Finally, this also takes the first baby step towards adding support for the Wasm
GC proposal. Right now the only thing that is supported is `nofunc` references,
and this was mainly to make testing function reference subtyping easier. But
that does mean that supporting `nofunc` references entailed also adding a
`wasmtime::NoFunc` type as well as the `Config::wasm_gc(enabled)` knob. So we
officially have an in-progress implementation of Wasm GC in Wasmtime after this
PR lands!
Fixes https://github.com/bytecodealliance/wasmtime/issues/6455
* Fix WAT in test to be valid
* Check that dependent features are enabled for function-references and GC
* Remove unnecessary engine parameters from a few methods
Ever since `FuncType`'s internal `RegisteredType` holds onto its own `Engine`,
we don't need these anymore.
Still useful to keep the `Engine` parameter around for the `ensure_matches`
methods because that can be used to check correct store/engine usage for
embedders.
* Add missing dependent feature enabling for some tests
* Remove copy-paste bit from test
* match self to show it is uninhabited
* Add a missing `is_v128` method
* Short circuit a few func type comparisons
* Turn comment into part of doc comment
* Add test for `Global::new` and subtyping
* Add tests for embedder API, tables, and subtyping
* Add an embedder API test for setting globals and subtyping
* Construct realloc's type from its index, rather than from scratch
* Help LLVM better optimize our dynamic type checks in `TypedFunc::call_raw`
* Fix call benchmark compilation
* Change `WasmParams::into_abi` to take the whole func type instead of iter of params
* Fix doc links
prtest:full
* Fix size assertion on s390x
The construction before was readable in the GitHub Action itself, but IMO the descriptions in the [opened PR’s](https://github.com/bytecodealliance/wasmtime/pull/7958) are not as pretty to read. This will fix this by making every sentence on one line.
There are a *ton* of different options such a script could have, and things we
could tweak. This is just meant to be a shared starting point so it is easy to
get up and running with something.
Example output:
```
./benches/wasmtime-serve-rps.sh -O pooling-allocator hello_wasi_http.wasm
Finished `release` profile [optimized] target(s) in 0.17s
Running `target/release/wasmtime serve -O pooling-allocator hello_wasi_http.wasm`
Serving HTTP on http://0.0.0.0:8080/
Running `wasmtime serve` in background as pid 2476839
Benchmarking for 10 seconds...
Summary:
Total: 10.0025 secs
Slowest: 0.0138 secs
Fastest: 0.0001 secs
Average: 0.0013 secs
Requests/sec: 39461.5419
Response time histogram:
0.000 [1] |
0.001 [277602] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.003 [111637] |■■■■■■■■■■■■■■■■
0.004 [4182] |■
0.006 [720] |
0.007 [301] |
0.008 [143] |
0.010 [76] |
0.011 [26] |
0.012 [19] |
0.014 [7] |
Latency distribution:
10% in 0.0006 secs
25% in 0.0009 secs
50% in 0.0012 secs
75% in 0.0016 secs
90% in 0.0019 secs
95% in 0.0022 secs
99% in 0.0031 secs
Details (average, fastest, slowest):
DNS+dialup: 0.0000 secs, 0.0001 secs, 0.0138 secs
DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0000 secs
req write: 0.0000 secs, 0.0000 secs, 0.0092 secs
resp wait: 0.0012 secs, 0.0001 secs, 0.0137 secs
resp read: 0.0000 secs, 0.0000 secs, 0.0113 secs
Status code distribution:
[200] 394714 responses
```
This commit makes the following changes:
* A handful of `#[inline]` annotations.
* A couple cases of splitting out uncommon/slow paths from `#[inline]`-annotated
functions into their own non-`#[inline]`-annotated functions.
* Remove a call to `mpk::is_supported()` in async context construction. It is
sufficient to just check `self.pkey.is_some()` since if mpk isn't supported we
won't have a pkey, if we do have a pkey mpk must have been supported for us to
get it, and even if mpk is supported, if we don't have a pkey we
don't need to do anything here.
Criterion benchmark results:
```
sync/no-hook/core - host-to-wasm - typed - nop-params-and-results
time: [25.214 ns 25.322 ns 25.443 ns]
change: [-21.901% -20.227% -18.749%] (p = 0.00 < 0.05)
Performance has improved.
```
* Don't keep extra copies of root block ID
We already know the entry block everywhere we use this.
* Replace DomTreeWithChildren with DominatorTreePreorder
These two types had nearly identical interfaces except that the latter
also supports constant-time dominance checks.
* Use dom-tree preorder for O(1) dominance checks
It turns out this was the only thing the egraph pass used the original
dominator tree for, so we can stop passing that around.
We could also require that the caller of EgraphPass::new construct the
DominatorTreePreorder and avoid passing the original tree into the
egraph pass at all, but I've chosen to stop refactoring here.
We should review all uses of DominatorTree::dominates to see if it makes
sense to pass a DominatorTreePreorder around more places.
* review comments: Rename/document away from "domtree with children"
* Allow `traps.rs` tests to pass even when `RUST_BACKTRACE=1` on nightly Rust
Instead of asserting exact error messages, which `anyhow` auto adds Rust
backtrace to on nightly, assert that the important bits are there.
* Use `contains` on the whole error message when possible
This commit fixes a fuzz bug where modules involving known libcalls
would fail to compile given that they were unconditionally treated as
colocated libcalls.
This bug is only reproducible in non sse41 environments, given that some
operations like `floor` default to libcalls in this case. The
`use_colocated_libcalls` setting is not configurable within Wasmtime and
as such, they should be loaded into a register prior to emitting the
call. This will also ensure that the right 8-byte absolute relocation is
used.
* mpk: restore PKRU state when a fiber resumes execution
Previously, when a fiber was suspended, other computation could change
the PKRU state on the current CPU. This means that the fiber could be
resumed with a different PKRU state. This could be bad, resulting in
situations in which the fiber can access more memory slots than it
should or cannot even access its own memory slots.
This change saves the PKRU state prior to a fiber being suspended. When
the fiber resumes execution, that PKRU state is restored.
* mpk: check correct PKRU switching on async suspension
This adds a test that alternately polls two Wasm instances in a loop.
Since the instances are async, we can set up epochs to suspend each
fiber as we iterate over a loop. Because we alternate between the two
instances, it checks that `AsyncCx::block_on` has correctly restored the
PKRU bits; otherwise we should see test failures. In the process of
writing this test I discovered #7942, which can be solved separately
(it has to do with the interaction between memory images, _not_ used
here, and MPK).
prtest:full
* fix: condition the PKRU context switches
Not all stores have protection keys and MPK is not always enabled. This
change checks for these conditions before context-switching the PKRU
bits.
* Add Component::image_range
This is the same as `Module::image_range` but for components. While I'm
here additionally return a pointer instead of a `usize` to further
emphasize that it's in the host's address space.
* Remove unused import
* Fix compilation of the C API
* Restructure the MacroAssembler interface to clobbers
* Update winch/codegen/src/trampoline.rs
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
* Revert "Update winch/codegen/src/trampoline.rs"
This reverts commit 53ca1dea4f.
* Review feedback
* Prevent calling multiple `emit` functions on a `Trampoline` value
---------
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
* Shrink the size of int-to-float conversions
This commit adds egraph optimization rules to shrink the size of
int-to-float conversions where possible. This helps backends like the
x64 backend where the 64-bit-unsigned-integer-to-float conversions does
not have a single instruction lowering unlike other types.
* Update cranelift/codegen/src/opts/arithmetic.isle
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
---------
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
This commit fully enables usage of Winch in the `differential` fuzzer
against all other engines with no special cases. I attempted enabling
winch for the other fuzzers as well but Winch doesn't currently
implement all methods for generating various trampolines required so
it's currently only limited to the `differential` fuzzer.
This adds Winch as an "engine" and additionally ensures that when
configured various wasm proposals are disabled that Winch doesn't
support (similar to how enabling `wasmi` disables proposals that `wasmi`
doesn't support).
This does reduce fuzzing of Winch slightly in that the reference-types
proposal is completely disabled for Winch rather than half-enabled where
Winch doesn't implement `externref` operations yet but does implement
`funcref` operations. This, however, enables integrating it more cleanly
into the rest of the fuzzing infrastructure with fewer special cases.
* winch: Optimize calls
This commit introduces several optimizations to speed up the compilation
of function calls:
* Keep track of previously resolved function signatures for local or
imported callees to avoid computing the `ABISig` on every
function call.
* Keep track of previously resolved type signatures for indirect calls
to avoid computing the `ABISig` on every function call.
* Refactor `CallKnown` and `CallUnknown` instructions to make the
`BoxCallInfo` field in the struct optional. Prior to this change,
from Winch's perspective each call lowering involved a heap
allocation, using the default values for `BoxCallInfo`, which in the
end are not used by Winch.
* Switch Winch's internal `Stack` to use a `SmallVec` rather than
a `Vec`. Many of the operations involving builtin function calls
require inserting elements at arbitrary offsets in the stack and
using a `SmallVec` makes this process more efficient.
With the changes mentioned above, I observed ~30% improvement in
compilation times for modules that are call-heavy.
* Expect `CallInfo` where applicable and add a comment about the type
definition
* Remove unneeded types and lifetimes
* Discard 0-sized writes to files
This commit comes from #7633 where Windows and Unix would behave
differently when writing at a particular file offset. Notably Unix
semantics [indicate]:
> Before any action described below is taken, and if nbyte is zero
> and the file is a regular file, the write() function may detect
> and return errors as described below. In the absence of errors,
> or if error detection is not performed, the write() function
> shall return zero and have no other results. If nbyte is zero and
> the file is not a regular file, the results are unspecified.
These semantics are a bit easier to emulate on Windows so the host
implementation now discards any attempt to perform I/O if a zero-sized
write is detected.
[indicate]: https://man7.org/linux/man-pages/man3/write.3p.htmlCloses#7633
* Discard empty writes in wasi-common as well
* Remove the use of the union-find structure during elaboration
Remove the UnionFind argument to `Elaborator::new`, and from the
`Elaborator` structure, relying instead on the `value_to_best_value`
table when computing canonical values.
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
Co-authored-by: L. Pereira <lpereira@fastly.com>
* Document the eclass union subtree invariant
---------
Co-authored-by: Jamey Sharp <jsharp@fastly.com>
Co-authored-by: L. Pereira <lpereira@fastly.com>
Use a new `wit_parser::Resolve::push_path` API instead of a combo of
`push_dir` and `UnresolvedPackage` which handles the wasm format
internally and otherwise is a superset of the prior functionality.
* WIP: try to make wasi-common self contained.
* rebase: cargo.lock
* remove all dependencies between wasi-common and wasmtime-wasi
* use wasi-common directly throughout tests, benches, examples, cli run
* wasi-threads: use wasi-common's maybe_exit_on_error in spawned thread
not a very modular design, but at this point wasi-common and
wasi-threads are forever wed
* fix wasmtime's docs
* re-introduce wasmtime-wasi's exports of wasi-common definitions behind deprecated
* factor out determining i32 process exit code
and remove libc dep because rustix provides the same constant
* commands/run: inline the logic about aborting on trap
since this is the sole place in the codebase its used
* Add high-level summary to wasi-common's top-level doc comment.
* c-api: fix use of wasi_cap_std_sync => wasi_common::sync, wasmtime_wasi => wasi_common
* fix tokio example
* think better of combining downcast and masking into one method
* fix references to wasmtime_wasi in docs
prtest:full
* benches: use wasi-common
* cfg-if around use of rustix::process because that doesnt exist on windows
* wasi-common: include tests, caught by verify-publish
* fix another bench
* exit requires wasmtime dep. caught by verify-publish.
This commit fixes an issue with the proxy adapter where if the proxy
program attempted to look at prestat items, which wasi-libc always does
on startup, it would invoke `fd_prestat_get` and receive `ERRNO_NOTSUP`
in response (the standard response when using the
`cfg_filesystem_available!` macro). This error code is unexpected by
wasi-libc and causes wasi-libc to abort. The PR here is to instead
return `ERRNO_BADF` which is indeed expected by wasi-libc and is
recognized as meaning "that prestat isn't available".
* fd_filestat_set test: assert that a file descriptor behaves the same...
whether opened readonly or readwrite.
This test now reproduces the behavior reported in https://github.com/bytecodealliance/wasmtime/issues/7829
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* preview1_path_link test: refactor; create and open file separately
we create and open the file with separate descriptors because the
creation descriptor will always imply writing, whereas the rest do not.
there were a number of auxillary functions in here that were obscuring
what was going on, and making errors harder to read, so i changed some
assertions to use macro-rules so the panic message had the relevant line
number, and i inlined the creation / opening functions.
* preview2 filesystem: track open mode instead of reporting permissions it n DescriptorFlags
FilePerms/DirPerms is a way of having wasmtime-wasi, instead of the operating
system, mediate permissions on a preview2 Descriptor. This was conflated
with the open mode, which should determine whether DescriptorFlags
contains READ or WRITE or MUTATE_DIRECTORY.
We no longer mask FilePerms with the DescriptorFlags (oflags) in open_at -
instead, track what open mode is requested, and see if the file and
directory permissions permit it.
Additionally, File and Dir now track their open_mode (represented using
OpenMode, which just like FilePerms is just a read and write bit),
and report that in DescriptorFlags. Previously, we reported the
FilePerms or DirPerms in the DescriptorFlags, which was totally wrong.
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* different error on windows i guess?
prtest:full
* apparently set-times of read-only is rejected on windows. just skip testing that
* path open read write: another alternate error code for windows
* wasi-common actually gives a badf, so accept either
* this case too
---------
Co-authored-by: Trevor Elliott <telliott@fastly.com>
* Update the wasm-tools family of crates
Pulling in some updates to improve how WIT is managed in this
repository. No changes just yet, however, just pulling in the updates
first.
* Fix tests
* Fix fuzzer build
* Perform stronger typechecks of host-owned resources
Right now the abstraction for host-owned resources in Wasmtime is quite
simple, it's "just an index". This can be error prone because the host
can suffer both from use-after-free and ABA-style problems. While
there's not much that can be done about use-after-free the previous
implementation would accidentally enable "AB" style problems where if a
host-owned resource index was deallocated and then reallocated with
another type the original handle would still work. While not a major bug
this can be confusing and additionally violate's our guarantees as a
component runtime to guests to ensure that resources always have valid
`rep`s going into components.
This commit adds a new layer of storage which keeps track of the
`ResourceType` for all host-owned resources. This means that resources
going into a host-owned table now record their type and coming out of a
host-owned table a typecheck is always performed. Note that guests can
continue to skip this logic as they already have per-type tables and so
won't suffer the same issue.
This change is inspired by my taking a look at #7883. The crux of the
issue was a typo where a resource was reused by accident which led to
confusing behavior due to the reuse. This change instead makes it return
an error more quickly and doesn't allow the component to see any invalid
state.
Closes#7883
* Fix test
* Use generation counters, not types
* Review comments
Rather than an `Arc<RwLock<TypeRegistryInner>>`.
This also removes the `Arc` inside `TypeRegistry` and we effectively reuse
`Engine`'s internal `Arc` instead.
Also, to avoid various `TypeRegistry` methods needing to take an `Engine` to
construct their `RegisteredType` results, but then needing to assert that the
given engine is this registry's engine, I turned the methods into `TypeRegistry`
constructors. These constructors take just an `&Engine` and then access the
underlying `TypeRegistry` as needed, effectively making that property hold
statically.
This is a minor clean up on its own, but is a big help for follow up work I am
doing for Wasm GC and typed function references, where being able to grab a
reference to the engine that a `FuncType` is registered within will prevent
needing to thread in additional engine parameters to various places and then
assert that the engine is the engine that the type is registered within, and
etc...
This commit adds a general purpose lowering for the `fcvt_from_uint`
instruction in addition to the previously specialized lowering for what
the wasm frontend produces. This is unlikely to get triggered much from
the wasm frontend except when intermediate optimizations change the
shape of code. The goal of this commit is to address issues such as
those identified in #7915 and historically by ensuring that there's a
lowering for the instruction for all input types instead of trying to
massage the input into the right form.
This instruction lowering was crafted by studying LLVM's output and I've
put commentary to the best of my ability as to what's going on.
This commit is born out of a fuzz bug on x64 that was discovered recently.
Today, on `main`, and in the 17.0.1 release Wasmtime will panic when compiling
this wasm module for x64:
(module
(func (result v128)
i32.const 0
i32x4.splat
f64x2.convert_low_i32x4_u))
panicking with:
thread '<unnamed>' panicked at /home/alex/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cranelift-codegen-0.104.1/src/machinst/lower.rs:766:21:
should be implemented in ISLE: inst = `v6 = fcvt_from_uint.f64x2 v13 ; v13 = const0`, type = `Some(types::F64X2)`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Bisections points to the "cause" of this regression as #7859 which
more-or-less means that this has always been an issue and that PR just
happened to expose the issue. What's happening here is that egraph
optimizations are turning the IR into a form that the x64 backend can't
codegen. Namely there's no general purpose lowering of i64x2 being
converted to f64x2. The Wasm frontend never produces this but the
optimizations internally end up producing this.
Notably here the result of this function is constant and what's
happening is that a convert-of-a-splat is happening. In lieu of adding
the full general lowering to x64 (which is perhaps overdue since this is
the second or third time this panic has been triggered) I've opted to
add constant propagation optimizations for int-to-float conversions.
These are all based on the Rust `as` operator which has the same
semantics as Cranelift. This is enough to fix the issue here for the
time being.
* unionfind: robustly avoid changing `Idx`s in the GVN map
Stop hoping that keeping the smallest Idx as canonical will yield good
results, and instead explicitly inform the UnionFind of what we expect
not to move.
Fixes#6126
* unionfind: track unions of pinned indices as stats
Emitting a warning in this situation is too much.
* Test with aarch64 macOS on CI
Rebase of #7129 with the `macos-14` string which GitHub indicates should
now work for public repos.
prtest:full
* Fix syntax
This fixes the build on the latest nightly Rust. I was able to vet
`ahash` itself but `zerocopy` is such a large and full-of-unsafe
dependency I've added an exemption for it. The documentation of it seems
to indicate it's a pretty well thought out crate with lots of care
behind it, so at least at a first glance it did not seem overly
worrisome.
* vet: prune lockfile
When running `cargo vet` in #7900, it warned me that we should consider
pruning some unused entries, etc. This is the result of running `cargo
vet prune`.
* vet: a couple more post-#7908
Alex Crichton
Pat Hickey
Nick Fitzgerald
Trevor Elliott
Jamey Sharp
Sebastiaan Speck
wasmtime-publish
Saúl Cabrera
Dave Bakker
Andrew Brown
bjorn3
Archisman Mridha
Maja Kądziołka
Milek7