We already cover module linking with the `instantiate-swarm` target and
otherwise enabling module linking is preventing otherwise-valid modules
from being compiled because of the breaking change in the module linking
proposal with respect to imports.
Previously wasmtime would handle any signal originating from wasm JIT
code. This would, however, handle bugs in JIT code as-if they were wasm
traps. Instead this commit switches signal handling to specifically
check for whether the precise program counter is expected to be a trap.
This way if a program counter traps and it's not expected to trap the
signal isn't handled and the process is aborted (presumably leading to
further debugging of whomever happens to work on the JIT at that time).
With `Module::{serialize,deserialize}` it should be possible to share
wasmtime modules across machines or CPUs. Serialization, however, embeds
a hash of all configuration values, including cranelift compilation
settings. By default wasmtime's selection of the native ISA would enable
ISA flags according to CPU features available on the host, but the same
CPU features may not be available across two machines.
This commit adds a `Config::cranelift_clear_cpu_flags` method which
allows clearing the target-specific ISA flags that are automatically
inferred by default for the native CPU. Options can then be
incrementally built back up as-desired with teh `cranelift_other_flag`
method.
change reopen_with_fdflags(&self, fdflags) -> Result<Box<dyn WasiFile>>
to set_fdflags(&mut self, fdflags) -> Result<()>.
this makes way more sense than my prior hare-brained schemes.
This commit introduces two new methods on `Memory` that enable
reading and writing memory contents without requiring `unsafe`.
The methods return a new `MemoryError` if the memory access
fails.
* need to close the handle to the subdirectory before its legal to
delete it
* windows doesnt give us a way to distinguish between an ERRNO_PERM and
an ERRNO_ACCES, so lets accept either one
* path_open of a directory without OFLAGS_DIRECTORY worked on linux,
but fortunately not on windows!
* the errno is BADF instead of NOTCAPABLE for fd_seek on a directory
* no way for a directory to have the FD_SEEK right.
cargo-deny tells us that we should upgrade raw-cpuid to v9.0.0. This
new version also seems to lack the `nightly` feature (perhaps it has
been incorporated into the base functionality) so I had to remove this
feature selector to build.
* Add support for the experimental wasi-crypto APIs
The sole purpose of the implementation is to allow bindings and
application developers to test the proposed APIs.
Rust and AssemblyScript bindings are also available as examples.
Like `wasi-nn`, it is currently disabled by default, and requires
the `wasi-crypto` feature flag to be compiled in.
* Rename the wasi-crypto/spec submodule
* Add a path dependency into the submodule for wasi-crypto
* Tell the publish script to vendor wasi-crypto