* Tidy up some headers related to shared memory
* Don't declare an anonymous `struct wasmtime_sharedmemory`, instead
`#include` the actual definition.
* Fix an issue where a header in `sharedmemory.h` referred to a type in
`extern.h` which wasn't `#include`'d. This function,
`wasmtime_sharedmemory_into_extern`, additionally isn't necessary as
it's no different than manually constructing it. Fix this by removing
this function.
* Run clang-format
Restores support for `externref` in `wasmtime_val_t`, methods for manipulating
them and getting their wrapped host data, and examples/tests for these things.
Additionally adds support for `anyref` in `wasmtime_val_t`, clone/delete methods
similar to those for `externref`, and a few `i31ref`-specific methods. Also adds
C and Rust example / test for working with `anyref`.
* Fix running wasi-common tests on CI
Turns out we haven't been running wasi-common tests for some time in CI
and they've started failing. Force enable the test at all times and then
fix the test failures. The test failures here were introduced in #8277
and weren't caught due to the test not running and the fix was to relax
the implementation of `fd_pread` to avoid taking multiple mutable
borrows.
* Fix CI
Currently we've got a good number of WASI tests and they're all
relatively large. We also can run a single test in up to three
configurations:
* As-is with a module
* As a component in "sync" mode
* As a component in "async" mode
In debug mode compilation of all these modules can take a significant
chunk of time (20-30s in total for test suites) This commit updates
these test suites to use an in-memory per-process incremental cache
backed by a simple `Mutex<HashMap>`. This gives some good speedups in
debug mode, locally the wasi-common, wasmtime-wasi, and
wasmtime-wasi-http test suites were reduced from 32 to 17 seconds. I'd
expect larger speedups on less-parallel machines such as our CI.
* wasmtime-c-api: switch from using wasi-common to wasmtime-wasi
* Fix WasiP1Ctx references, and stop eagerly opening dirs for preopens
* Add OutputFile to skip async writes in stdout/stderr
---------
Co-authored-by: Trevor Elliott <telliott@fastly.com>
Previously, `wasmtime_types::EngineOrModuleTypeIndex` had a raw `u32` for its
engine-level-canonicalized variant. This change allows it to store a
`VMSharedTypeIndex` directly, giving us some additional static assurance that we
aren't messing up our different index types and lets us remove a ton of
conversions back and forth between raw `u32`s and `VMSharedTypeIndex`.
* c-api: Better differentiate between `wasm.h` and `wasmtime.h` APIs
This renames some types and adds some type aliases to help us better distinguish
between `wasm.h` APIs and `wasmtime.h` APIs, primarily for `Store`-related
types. In general, `WasmFoo` is related to `wasm.h` and `WasmtimeFoo` is related
to `wasmtime.h`.
* `StoreRef` -> `WasmStoreRef`
* Introduce the `WasmStore[Data]` and `WasmStoreContext[Mut]` aliases
* `StoreData` -> `WasmtimeStoreData`
* `CStoreContext[Mut]` -> `WasmtimeStoreContext[Mut]`
* Introduce the `Wasmtime{Store,Caller}` aliases
* c-api: Improve non-support of GC references in `wasm.h` APIs
A couple small tweaks: error message improvements, exhaustive matching, etc...
* Document HttpResult and HttpError
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move error functions into error module
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Document the body module (and rearrange slightly)
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Make FinishMessage as it does not need to be public
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Rename as_body_error to as_body_size_error
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Make http_impl module non-public since it doesn't need to be
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Document the io module
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Document the proxy module
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Make types_impl module non-public since it doesn't need to be
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* WasiHttpCtx and WasiHttpView documented inline
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Add top level crate documentation
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Document proxy add_to_linker with example
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Deny missing docs
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Make HostOutgoingBody::body_output_stream non public
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
---------
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
This renames some types and adds some type aliases to help us better distinguish
between `wasm.h` APIs and `wasmtime.h` APIs, primarily for `Store`-related
types. In general, `WasmFoo` is related to `wasm.h` and `WasmtimeFoo` is related
to `wasmtime.h`.
* `StoreRef` -> `WasmStoreRef`
* Introduce the `WasmStore[Data]` and `WasmStoreContext[Mut]` aliases
* `StoreData` -> `WasmtimeStoreData`
* `CStoreContext[Mut]` -> `WasmtimeStoreContext[Mut]`
* Introduce the `Wasmtime{Store,Caller}` aliases
* Explicitly document why `blocking_mode` is being ignored.
* Don't write-in-a-loop to doing a partial write and then returning an
error.
* Spawn a background read/write when the embedding cannot block the
current thread.
* Don't panic on overflows for addition.
* Fix panic on reads with shared memory
Follow-ups to #8303
* Force users to construct WasiHttpCtx through a constructor
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Rename OutgoingRequest to OutgoingRequestConfig and breakout actual request
This rename makes the role of the type easier to understand and draws a
bigger difference between it and HostOutgoingRequest.
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Remove the authority field from the OutgoingRequestConfig
The authority is already encoded in the request itself.
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Add doc comments to the major request/response resource types
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Add more doc comments to resource types
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Rename `IncomingResponseInternal` to `IncomingResponse`
Calling a public type "internal" seems strange. This also adds docs to
the type.
* Small additional changes
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Refactor HttpView::send_request
Don't require implementors to do resource management.
* Make worker task optional
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Fix CI
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
---------
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
The worker is a handle to a tokio task where the connection is being
read from. It should be kept alive in order to continue to be able to
read the response body. However, the worker _is_ kept alive on
`HostIncomingBody`. Arguably this the exact place where the task should be kept
as once that type is dropped there's no longer a need to keep the worker
around.
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
By default previously all return types were wrapped in
`wasmtime::Result<T>` to enable any import to return a trap to the wasm
guest. This is a fair bit of boilerplate, however, and it's easy to
accidentally turn a normal error into a trap. This is additionally
somewhat of a power-user method as many imports probably don't end up
wanting to trap.
This commit adds a new configuration option to `bindgen!`:
`trappable_imports`, and switches the default to `false`. The previous
behavior can be recovered with `trappable_imports: true`.
* Cranelift: Do not dedupe/GVN bitcasts from reference values
Deduping bitcasts to integers from references can make the references no long
longer live across safepoints, and instead only the bitcasted integer results
would be. Because the reference is no longer live after the safepoint, the
safepoint's stack map would not have an entry for the reference, which could
result in the collector reclaiming an object too early, which is basically a
use-after-free bug. Luckily, we sandbox the GC heap now, so such UAF bugs aren't
memory unsafe, but they could potentially result in denial of service
attacks. Either way, we don't want those bugs!
On the other hand, it is technically fine to dedupe bitcasts *to* reference
types. Doing so extends, rather than shortens, the live range of the GC
reference. This potentially adds it to more stack maps than it otherwise would
have been in, which means it might unnecessarily survive a GC it otherwise
wouldn't have. But that is fine. Shrinking live ranges of GC references, and
removing them from stack maps they otherwise should have been in, is the
problematic transformation.
* Add additional logging and debug asserts for GC stuff
* winch: Add support for address maps
Closes https://github.com/bytecodealliance/wasmtime/issues/8095
This commit adds support for generating address maps for Winch.
Give that source code locations and machine code offsets are machine independent, one objective of this change is introduce minimal methods to the MacroAssesmbler and Asssembler implementations and tries to accomodate the bulk of the work in the ISA independent `CodeGen` module.
* Update method documentation to match implementation
This commit fixes an issue with errors in the `wasmtime-wasi-http` crate
by using the `trappable_error_type` bindgen configuration option in the
same manner as other WASI interfaces in the `wasmtime-wasi` crate.
Unfortunately due to coherence the `TrappableError<T>` type itself could
not be used but it was small enough it wasn't much effort to duplicate.
Closes#8269
\### The `GcRuntime` and `GcCompiler` Traits
This commit factors out the details of the garbage collector away from the rest
of the runtime and the compiler. It does this by introducing two new traits,
very similar to a subset of [those proposed in the Wasm GC RFC], although not
all equivalent functionality has been added yet because Wasmtime doesn't
support, for example, GC structs yet:
[those proposed in the Wasm GC RFC]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md#defining-the-pluggable-gc-interface
1. The `GcRuntime` trait: This trait defines how to create new GC heaps, run
collections within them, and execute the various GC barriers the collector
requires.
Rather than monomorphize all of Wasmtime on this trait, we use it
as a dynamic trait object. This does imply some virtual call overhead and
missing some inlining (and resulting post-inlining) optimization
opportunities. However, it is *much* less disruptive to the existing embedder
API, results in a cleaner embedder API anyways, and we don't believe that VM
runtime/embedder code is on the hot path for working with the GC at this time
anyways (that would be the actual Wasm code, which has inlined GC barriers
and direct calls and all of that). In the future, once we have optimized
enough of the GC that such code is ever hot, we have options we can
investigate at that time to avoid these dynamic virtual calls, like only
enabling one single collector at build time and then creating a static type
alias like `type TheOneGcImpl = ...;` based on the compile time
configuration, and using this type alias in the runtime rather than a dynamic
trait object.
The `GcRuntime` trait additionally defines a method to reset a GC heap, for
use by the pooling allocator. This allows reuse of GC heaps across different
stores. This integration is very rudimentary at the moment, and is missing
all kinds of configuration knobs that we should have before deploying Wasm GC
in production. This commit is large enough as it is already! Ideally, in the
future, I'd like to make it so that GC heaps receive their memory region,
rather than allocate/reserve it themselves, and let each slot in the pooling
allocator's memory pool be *either* a linear memory or a GC heap. This would
unask various capacity planning questions such as "what percent of memory
capacity should we dedicate to linear memories vs GC heaps?". It also seems
like basically all the same configuration knobs we have for linear memories
apply equally to GC heaps (see also the "Indexed Heaps" section below).
2. The `GcCompiler` trait: This trait defines how to emit CLIF that implements
GC barriers for various operations on GC-managed references. The Rust code
calls into this trait dynamically via a trait object, but since it is
customizing the CLIF that is generated for Wasm code, the Wasm code itself is
not making dynamic, indirect calls for GC barriers. The `GcCompiler`
implementation can inline the parts of GC barrier that it believes should be
inline, and leave out-of-line calls to rare slow paths.
All that said, there is still only a single implementation of each of these
traits: the existing deferred reference-counting (DRC) collector. So there is a
bunch of code motion in this commit as the DRC collector was further isolated
from the rest of the runtime and moved to its own submodule. That said, this was
not *purely* code motion (see "Indexed Heaps" below) so it is worth not simply
skipping over the DRC collector's code in review.
\### Indexed Heaps
This commit does bake in a couple assumptions that must be shared across all
collector implementations, such as a shared `VMGcHeader` that all objects
allocated within a GC heap must begin with, but the most notable and
far-reaching of these assumptions is that all collectors will use "indexed
heaps".
What we are calling indexed heaps are basically the three following invariants:
1. All GC heaps will be a single contiguous region of memory, and all GC objects
will be allocated within this region of memory. The collector may ask the
system allocator for additional memory, e.g. to maintain its free lists, but
GC objects themselves will never be allocated via `malloc`.
2. A pointer to a GC-managed object (i.e. a `VMGcRef`) is a 32-bit offset into
the GC heap's contiguous region of memory. We never hold raw pointers to GC
objects (although, of course, we have to compute them and use them
temporarily when actually accessing objects). This means that deref'ing GC
pointers is equivalent to deref'ing linear memory pointers: we need to add a
base and we also check that the GC pointer/index is within the bounds of the
GC heap. Furthermore, compressing 64-bit pointers into 32 bits is a fairly
common technique among high-performance GC
implementations[^compressed-oops][^v8-ptr-compression] so we are in good
company.
3. Anything stored inside the GC heap is untrusted. Even each GC reference that
is an element of an `(array (ref any))` is untrusted, and bounds checked on
access. This means that, for example, we do not store the raw pointer to an
`externref`'s host object inside the GC heap. Instead an `externref` now
stores an ID that can be used to index into a side table in the store that
holds the actual `Box<dyn Any>` host object, and accessing that side table is
always checked.
[^compressed-oops]: See ["Compressed OOPs" in
OpenJDK.](https://wiki.openjdk.org/display/HotSpot/CompressedOops)
[^v8-ptr-compression]: See [V8's pointer
compression](https://v8.dev/blog/pointer-compression).
The good news with regards to all the bounds checking that this scheme implies
is that we can use all the same virtual memory tricks that linear memories use
to omit explicit bounds checks. Additionally, (2) means that the sizes of GC
objects is that much smaller (and therefore that much more cache friendly)
because they are only holding onto 32-bit, rather than 64-bit, references to
other GC objects. (We can, in the future, support GC heaps up to 16GiB in size
without losing 32-bit GC pointers by taking advantage of `VMGcHeader` alignment
and storing aligned indices rather than byte indices, while still leaving the
bottom bit available for tagging as an `i31ref` discriminant. Should we ever
need to support even larger GC heap capacities, we could go to full 64-bit
references, but we would need explicit bounds checks.)
The biggest benefit of indexed heaps is that, because we are (explicitly or
implicitly) bounds checking GC heap accesses, and because we are not otherwise
trusting any data from inside the GC heap, we greatly reduce how badly things
can go wrong in the face of collector bugs and GC heap corruption. We are
essentially sandboxing the GC heap region, the same way that linear memory is a
sandbox. GC bugs could lead to the guest program accessing the wrong GC object,
or getting garbage data from within the GC heap. But only garbage data from
within the GC heap, never outside it. The worse that could happen would be if we
decided not to zero out GC heaps between reuse across stores (which is a valid
trade off to make, since zeroing a GC heap is a defense-in-depth technique
similar to zeroing a Wasm stack and not semantically visible in the absence of
GC bugs) and then a GC bug would allow the current Wasm guest to read old GC
data from the old Wasm guest that previously used this GC heap. But again, it
could never access host data.
Taken altogether, this allows for collector implementations that are nearly free
from `unsafe` code, and unsafety can otherwise be targeted and limited in scope,
such as interactions with JIT code. Most importantly, we do not have to maintain
critical invariants across the whole system -- invariants which can't be nicely
encapsulated or abstracted -- to preserve memory safety. Such holistic
invariants that refuse encapsulation are otherwise generally a huge safety
problem with GC implementations.
\### `VMGcRef` is *NOT* `Clone` or `Copy` Anymore
`VMGcRef` used to be `Clone` and `Copy`. It is not anymore. The motivation here
was to be sure that I was actually calling GC barriers at all the correct
places. I couldn't be sure before. Now, you can still explicitly copy a raw GC
reference without running GC barriers if you need to and understand why that's
okay (aka you are implementing the collector), but that is something you have to
opt into explicitly by calling `unchecked_copy`. The default now is that you
can't just copy the reference, and instead call an explicit `clone` method (not
*the* `Clone` trait, because we need to pass in the GC heap context to run the
GC barriers) and it is hard to forget to do that accidentally. This resulted in
a pretty big amount of churn, but I am wayyyyyy more confident that the correct
GC barriers are called at the correct times now than I was before.
\### `i31ref`
I started this commit by trying to add `i31ref` support. And it grew into the
whole traits interface because I found that I needed to abstract GC barriers
into helpers anyways to avoid running them for `i31ref`s, so I figured that I
might as well add the whole traits interface. In comparison, `i31ref` support is
much easier and smaller than that other part! But it was also difficult to pull
apart from this commit, sorry about that!
---------------------
Overall, I know this is a very large commit. I am super happy to have some
synchronous meetings to walk through this all, give an overview of the
architecture, answer questions directly, etc... to make review easier!
prtest:full
* Move bind into Tcp type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move start_connect into Tcp type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move finish_connect into Tcp type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move *_listen into Tcp type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move accept into Tcp type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move address methods into Tcp type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move various option methods into Tcp type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move shutdown methods into Tcp type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move finish bind methods into Tcp type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Change connect's return type
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move shutdown over to io::Result
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Rearrange some code
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* Move bind to io Error
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
---------
Signed-off-by: Ryan Levick <ryan.levick@fermyon.com>
* More flags like `--dir` and `--env` are moved into `RunCommon` to be
shared between `wasmtime serve` and `wasmtime run`, meaning that the
`serve` command can now configure environment variables.
* A small test has been added as well as infrastructure for running
tests with `wasmtime serve` itself. Previously there were no tests
that executed `wasmtime serve`.
* The `test_programs` crate had a small refactoring to avoid
double-generation of http bindings.
This commit fixes an accidental issue introduced in #8018 where using an
element segment which had been dropped with an `externref` table would
cause a panic. The panic happened due to an assertion that tables are
being used with the right type of item and that was being mismatched.
The underlying issue was that dropped element segments are modeled as an
empty element segment but the empty element segment was using the
"functions" encoding as opposed to the "expressions" encoding. This
meant that code later assumed that due to the use of functions the table
must be a table-of-functions, but this was not correct for
externref-based tables.
The fix in this commit is to instead model the encoding as an
"expressions" list which means that the table type is dispatched on to
call the appropriate initializer.
There is no memory safety issue with this mistake as the assertion was
specifically targetted at preventing memory safety. This does, however,
enable any WebAssembly module to panic a host.
Closes#8281
This commit is a refactoring and modernization of wiggle's
`BorrowChecker` implementation. This type is quite old and predates
everything related to the component model for example. This type
additionally predates the implementation of WASI threads for Wasmtime as
well. In general, this type is old and has not been updated in a long
time.
Originally a `BorrowChecker` was intended to be a somewhat cheap method
of enabling the host to have active safe shared and mutable borrows to
guest memory. Over time though this hasn't really panned out. The WASI
threads proposal, for example, doesn't allow safe shared or mutable
borrows at all. Instead everything must be modeled as a copy in or copy
out of data. This means that all of `wasmtime-wasi` and `wasi-common`
have largely already been rewritten in such a way to minimize borrows
into linear memory.
Nowadays the only types that represent safe borrows are the `GuestSlice`
type and its equivalents (e.g. `GuestSliceMut`, `GuestStr`, etc). These
are minimally used throughout `wasi-common` and `wasmtime-wasi` and when
they are used they're typically isolated to a small region of memory.
This is all coupled with the facst that `BorrowChecker` never ended up
being optimized. It's a `Mutex<HashMap<..>>` effectively and a pretty
expensive one at that. The `Mutex` is required because `&BorrowChecker`
must both allow mutations and be `Sync`. The `HashMap` is used to
implement precise byte-level region checking to fulfill the original
design requirements of what `wiggle` was envisioned to be.
Given all that, this commit guts `BorrowChecker`'s implementation and
functionality. The type is now effectively a glorified `RefCell` for the
entire span of linear memory. Regions are no longer considered when
borrows are made and instead a shared borrow is considered as borrowing
the entirety of shared memory. This means that it's not possible to
simultaneously have a safe shared and mutable borrow, even if they're
disjoint, at the same time.
The goal of this commit is to address performance issues seen in #7973
which I've seen locally as well. The heavyweight implementation of
`BorrowChecker` isn't really buying us much nowadays, especially with
much development having since moved on to the component model. The hope
is that this much coarser way of implementing borrow checking, which
should be much more easily optimizable, is sufficient for the needs of
WASI and not a whole lot else.
This commit refactors the `wasmtime-runtime` crate to avoid the
`std::panic` module entirely if it's compiled with `panic=abort`. From
an optimization perspective this is not really required since it'll
optimize the same either way with `-Cpanic=abort`, but avoiding
`std::panic` can help make the code a bit more portable. This
refactoring bundles in the `catch_unwind` with the longjmp of the panic
to keep the `#[cfg]` in one location. Callers are then updated as
appropriate.
* bump tokio-rustls
Note that rustls is not on the latest minor since tokio-rustls
has not updated yet.
* Add vet exemptions
* Update ureq to trim the crate graph
* Add vet for ureq
* Fix compile on riscv
---------
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
I'm not sure why the test fails this way locally, but I spuriously was
receiving a "connection refused" error instead of a "connection
timeout" error. I've updated the test case to accept either error here
to fix the spurious errors I'm seeing locally.
* Lift all serde deps to the workspace level
Deduplicate some versions mentioned throughout crates in the workspace.
* Lift `bincode` deps to the workspace configuration level
Deduplicate some mentioned versions throughout.
* Lift libc deps up to the workspace root
As with prior commits, deduplicate some versions mentioned.
* Bad relocation type generated
When disabling sse on x86_64 architecture machines and generating float
libcall, incorrect relocation type R_X86_64_8 may be obtained, with the
correct type being R_X86_64_64.
* Gate support for the wasm `threads` proposal behind a Cargo feature
This commit moves support for the `threads` proposal behind a new
on-by-default Cargo feature: `threads`. This is intended to support
building Wasmtime with fewer runtime dependencies such as those required
for the atomic operations on memories.
This additionally adds the `gc` feature in a few missing places too.
* Fix compile of C API without threads
* Fix rustdoc warnings on Nightly
I noticed during a failed doc build of another PR we've got a number of
warnings being emitted, so resolve all those here.
* Fix more warnings
* Fix rebase conflicts
* Add a `compile` feature to `wasmtime-environ`
This commit adds a compile-time feature to remove some dependencies of
the `wasmtime-environ` crate. This compiles out support for compiling
modules/components and makes the crate slimmer in terms of amount of
code compiled along with its dependencies. Much of this should already
have been statically removed by native linkers so this likely won't have
any compile-size impact, but it's a nice-to-have in terms of
organization.
This has a fair bit of shuffling around of code, but apart from
renamings and movement there are no major changes here.
* Fix compile issue
* Gate `ModuleTranslation` and its methods on `compile`
* Fix doc link
* Fix doc link
* Plumb coredump feature to `wasmtime-runtime`
The `wasmtime` crate already has a `coredump` feature but whether or not
it's enabled the `wasmtime-runtime` crate still captures a core dump.
Use this flag in the `wasmtime` crate to plumb support to
`wasmtime-runtime` to skip capture if it's not enabled.
* Fix a typo
This commit fixes a mistake in #8181 which meant that the caching for
components was no longer working. The mistake is fixed in this commit as
well as a new test being added too.
* Add documentation and examples for `wasmtime-wasi`
This commit adds lots of missing documentation and examples to top-level
types in `wasmtime-wasi`, mostly related to WASIp2. I've additionally
made a number of small refactorings here to try to make the APIs a bit
more straightforward and symmetric and simplify where I can.
* Remove `bindings::wasi` (reexports are still present under `bindings`)
* Rename `bindings::sync_io` to `bindings::sync`
* Generate fewer bindings in `bindings::sync` that can be pulled in from
the `bindings` module.
* Change `WasiCtxBuilder::preopened_dir` to take a path instead of a
`Dir` argument to avoid the need for another import.
* Synchronize `wasmtime_wasi_http::{add_to_linker, sync::add_to_linker}`
in terms of interfaces added.
* Remove `wasmtime_wasi::command` and move the generated types to the
`bindings` module.
* Move top-level add-to-linker functions to
`wasmtime_wasi::add_to_linker_sync` and
`wasmtime_wasi::add_to_linker_async`.
Closes#8187Closes#8188
* Add documentation for `wasmtime_wasi::preview1` and refactor
This commit adds documentation for the `wasmtime_wasi::preview1` module
and additionally refactors it as well. Previously this was based on a
similar design as WASIp2 with a "view trait" and various bits and
pieces, but the design constraints of WASIp1 lends itself to a simpler
solution of "just" passing around `WasiP1Ctx` instead. This goes back to
what `wasi-common` did of sorts where the `add_to_linker_*` functions
only need a projection from `&mut T` to `&mut WasiP1Ctx`, a concrete
type, which simplifies the module and usage.
* Small refactorings to `preopened_dir`
* Add `WasiCtx::builder`.
* Fix typo
* Review comments
* Switch Winch tests to ATT syntax
* Update all test expectations
* Move all winch tests to `disas` folder
* Add `test = "winch"` to `disas`
* Add `test = "winch"` to all winch test files
* Stub out bits to get AArch64 Winch tests working
* Update expectations for all aarch64 winch tests
* Update flags in Winch tests
Use CLI syntax as that's what `flags` was repurposes as in the new test
suite.
* Update all test expectations for x64 winch
* Omit more offsets by default
* Delete now-dead code
* Update an error message
* Update non-winch test expectations
This commit slightly improves the error message of feeding a component
into a module-taking API. This at least tries to convey that a component
was recognized but a module was expected.
This commit fixes a bug that was introduced in #8190 and brought up on
[Zulip]. In #8190 there was a subtle change in how Tokio and the CLI are
managed, namely that a Tokio runtime is installed at the start of the
CLI to avoid entering/exiting the runtime on each blocking call. This
had a small performance improvement relative to entering/exiting on each
blocking call. This meant, though, that calls previously blocked with
`Runtime::block_on` and now block with `Handle::block_on`. The
[documentation of `Handle::block_on`][doc] has a clause that says that
for single-threaded runtimes I/O and timers won't work.
To fix this issue I've switch the fallback runtime to a multi-threaded
runtime to ensure that I/O and timers continue to work.
[Zulip]: https://bytecodealliance.zulipchat.com/#narrow/stream/219900-wasi/topic/Wasi-http.20requests.20hang/near/429187256
[doc]: https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.html#method.block_on
There have been more fuzzbugs than expected and the onslaught of issues
something I definitely don't have time to deal with right now; let's try
again later in the year (unless someone else wants to drive this!).
This puts the fuzzing logic under an off-by-default feature so it can
still be tested and developed in-tree as desired.
Alex Crichton
Nick Fitzgerald
Pat Hickey
Ryan Levick
liutao
Brian
wasmtime-publish
redismongo
Saúl Cabrera
Alexander Lyon
Wang-Zhongqi
Roman Volosatovs
Jamey Sharp
Chris Fallin