* update capstone dependency to 0.12.0
this is only used for benchmarking, so the cargo vet is just an exemption which I updated to the latest version.
* winch filetests: fix capstone changes
* Add WinML backend for wasi-nn.
* Log execution time.
* WinML backend supports execution target selection.
ExecutionTarget::Gpu is mapped to LearningModelDeviceKind::DirectX.
* Limit WinML backend on Windows only.
* Move wasi-nn WinML example to new test infra.
* Scale tensor data in test app.
App knows input and target data range, so it's better to let app to
handle scaling.
* Remove old example for wasi-nn WinML backend.
* Update image2tensor link.
* Format code.
* Upgrade image2tensor to 0.3.1.
* Upgrade windows to 0.52.0
* Use tensor data as input for wasi-nn WinML backend test.
To avoid involving too many external dependencies, input image is
converted to tensor data offline.
* Restore trailing new line for Cargo.toml.
* Remove unnecessary features for windows crate.
* Check input tensor types.
Only FP32 is supported right now. Reject other tensor types.
* Rename default model name to model.onnx.
It aligns with openvino backend.
prtest:full
* Run nn_image_classification_winml only when winml is enabled.
* vet: add trusted `windows` crate to lockfile
* Fix wasi-nn tests when both openvino and winml are enabled.
* Add check for WinML availability.
* vet: reapply vet lock
---------
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
* Add a "custom" platform configuration for Wasmtime
This commit leverages adds a new "platform" to Wasmtime to be supported
in the `crates/runtime/src/sys` folder. This joins preexisting platforms
such as Unix and Windows. The goal of this platform is to be an opt-in
way to build Wasmtime for targets that don't have a predefined way to
run.
The new "custom" platform requires `--cfg wasmtime_custom_platform` to
be passed to the Rust compiler, for example by using `RUSTFLAGS`. This
new platform bottoms out in a C API that is intended to be small and
Linux-like. The C API is effectively the interface to virtual memory
that Wasmtime requires. This C API is also available as a header file at
`examples/min-platform/embedding/wasmtime-platform.h` (generated by
`cbindgen`).
The main purpose of this is to make it easier to experiment with porting
Wasmtime to new platforms. By decoupling a platform implementation from
Wasmtime itself it should be possible to run these experiments
out-of-tree. An example of this I've been working on is getting
Wasmtime running on bare-metal with a custom kernel. This support
enables defining the platform interface of the custom kernel's syscalls
outside of Wasmtime.
* Exclude wasmtime-platform.h from formatting
* Include build-wasmtime-target-wasm32 in final job
* Don't force any single toolchain
* Add notes to no_std docs
* Add rust-src to CI
* Review comments
* Change APIs to be fallible
* Only compile the min-platform example on Linux
* Fix compile of min-platform example
* Fix another compile error in the example
This commit is an implementation of #7860 for Wasmtime where
`wasmtime::component::Linker` is now "semver aware". This means that it
assumes that hosts are always managing WIT interfaces in a
semver-aare fashion meaning that semver-compatible upgrade exclusively
adds functionality. This neatly fits into the idea of subtyping at the
instance-level where if a binary built against 0.2.0 only requests a
subset of functionality from a runtime that provides 0.2.1, that should
work just fine.
Specifically what this change does is:
* For all names inserted into a `Linker` there might also be a "semver
compatible name" which is registered as well. For example `..@1.0.0`
is also registered as `..@1`.
* Semver-compatible names are only provided for versions without a
prerelease and with either a nonzero major or minor version number.
* When looking up an item in the linker if no exact match is found then
if a semver-compatible-name is available for the lookup key then
that's consulted as well.
This semantically means that if a components imports WASI 0.2.0 then a
runtime which only provides WASI 0.2.1 will be able to instantiate the
component. Furthermore if a component imports WASI 0.2.1 but only
imports the subset of WASI that was available in 0.2.0 then it will be
instantiable in a runtime that only supports 0.2.0.
This implementation is intended to be a crucial part of the evolution to
WASI to make it more seamless to upgrade WASI from both a host and guest
perspective. This no longer requires everyone to upgrade to the same
version all at the same time but instead decouples the upgrade
schedules.
Closes#7860
First of all, it is just a nice separation of concerns.
Second of all, as I design the GC rooting APIs for Wasmtime's upcoming Wasm GC
support, I want this same thing and I'd rather not open code it multiple times.
* Remove the `WASI` submodule
Historically the `WASI` submodule in this repository was used to pull
the sources of the `*.witx` files for preview1. This has never been used
by the `wasmtime-wasi` crate (which has its own copy in the
`crates/wasi/witx` folder) and was only ever used by `wasi-common`. This
submodule also served as a location for the `witx` crate itself.
Neither of these are really needed any more as the `*.witx` files are
unlikely to ever really change again. This commit removes the submodule
entirely, as well as the `path` dependency on `witx`, and copies the
`*.witx` files in the same manner as the `wasmtime-wasi` crate.
* Updated vet entries for witx
* Remove witx special cases in publish script
* Change how the wasi-common package is built
* 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
* 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.
* 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
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.
* Add wasmtime-c-api-impl to the list of crates to publish
* Enable rustdoc and publishing for c-api crate
* Provide paths to c-api headers as cargo links metadata
* Add a README section about using wasm-c-api in a rust crate
* In C API doc comment, mention use case for crates w/ C bindings
* Enable publishing for wasmtime-c-api-macros (prtest:full)
* Move c-api crates later in the publishing sequence (prtest:full)
Looks like it's been awhile since our last update. I've updated the
dependency here and additionally vetted the various dependency upgrades.
I notably did not vet `zstd-sys` since that would require vetting all of
zstd's C implementation itself which I am not, nor do I suspect many of
are, equipped to do. In lieu of that I've updated the exemption of
`zstd-sys` to the newer version.
Closes#7869
* update Wasmi fuzzing oracle to version 0.31.0
This allows us to enable the bulk-memory, reference-types and tail-call Wasm proposals for the Wasmi fuzzing oracle.
* apply rustfmt
* be more explicit about supported Wasm features
* align Wasmi config to input config
I am not sure if this is how it is intended to be used. Please review and provide feedback.
* remove duplicate threads_enabled
* remove min and max tables
We can do this since Wasmi supports reference-types Wasm proposal.
* add comment about config mutation
* use Wasmi v0.31.1
* be more explicit about supported Wasm features
* add comment about config mutation
* update wasmi_arena to v0.4.1
* Move `jit` crate to `environ`
Move the platform agnostic parts of the crate `wasmtime-jit` to
`wasmtime-environ`. This is the first part of the refactoring discussed
here: https://github.com/bytecodealliance/wasmtime/issues/7652 and a
follow up will move the remaining parts of `wasmtime-jit` so that the
crate can be deleted.
* Move `jit` crate to `wasmtime`
Move the remaining parts of `wasmtime-jit` to the `wasmtime` crate and
remove `wasmtime-jit`. This is part of the refactoring discussed in
https://github.com/bytecodealliance/wasmtime/issues/7652.
* undo toml formatting
* Trigger pipeline: prtest:full
* Remove `jit` directory
* move `ProfilingAgent` out of `profiling` feature
* add links to ELF_NAME_DATA
* Update the wasm-tools family of crates
Brings in support for validating gc instructions, but they're all left
disabled for now.
* Update fuzz test case generation
* More test fixes, remove stray files
* More test fixes
* Rebase
* Update several dependencies to windows-sys 0.52.
Update cap-std, rustix, io-extras, errno, fd-lock, fs-set-times, and
winx to versions which use windows-sys 0.52.
I started out hoping that everything could be updated to
windows-sys 0.52, however tokio and mio have not yet updated to
windows-sys 0.52 due to supporting an older MSRV.
* Link the C++ examples with CoreFoundation.
This is needed due to the iana-time-zone support.
prtest:full
* Fix compilation on non-Apple platfoms.
* Fix compilation on Apple platforms.
* windows-sys 0.52
Not locally tested due to C dependencies which I don't have the tooling for.
The intent is to use GH's CI.
* MEMORYMAPPEDVIEW_HANDLE -> MEMORY_MAPPED_VIEW_ADDRESS
* .Value instead of cast
* fmt
* Remove cast to MEMORY_MAPPED_VIEW_ADDRESS with struct creation
* Cast ptr from *mut u8 from *mut void
* Remove CI changes which were supposed to be on a distinct branch
* Update binutils when the target is x86_64-pc-windows-gnu
* Escape paths in CI
* Update .github/workflows/main.yml
Co-authored-by: Chris Denton <christophersdenton@gmail.com>
* Correct type from p2sh to pwsh
* Use | to correct YAML parsing error
* Fix msys2's installation of MinGW
* Finally fix msys2 handling
---------
Co-authored-by: Chris Denton <christophersdenton@gmail.com>
* wasi-nn: add test programs
This change adds new test programs for wasi-nn in a way fits in with the
existing WASI test infrastructure. The code is not new, though: this
reuses the wasi-nn `examples`, which are currently used by the
`run-wasi-nn-example.sh` CI script. Eventually the examples will be
removed in favor of these tests.
Because wasi-nn's component model support is still in flight, this
change also skips the generation of components for `nn_`-prefixed tests.
* wasi-nn: add `testing` module
This testing-only module has code (i.e., `check_test!`) to check whether
OpenVINO and some test artifacts are available. The test artifacts are
downloaded and cached if not present, expecting `curl` to be present on
the command line (as discussed in the previous version of this, #6895).
* wasi-nn: run `nn_*` test programs as integration tests
Following the pattern of other WASI crates, this change adds the
necessary infrastructure to run the `nn_*` files in
`crates/test-programs` (built by `test-program-artifacts`). These tests
are only run when two sets of conditions are true:
- statically: we only run these tests where we expect OpenVINO to be
easy to install and run (e.g., the `cfg_attr` parts)
- dynamically: we also only run these tests when the OpenVINO libraries
can be located and the model artifacts can be downloaded
* ci: install OpenVINO for running wasi-nn tests
prtest:full
* vet: certify the `wasi-nn` crate
* ci: remove wasi-nn test script
* Gate more functionality behind `debug-builtins`
This commit extends the gating behavior of the preexisting
`debug-builtins` Cargo feature to cover more GDB-related functionality
associated with debugging. This can additionally slim down the set of
exposed symbols from Wasmtime over the default with them included.
* Move timing in Cranelift behind a Cargo feature
This commit adds a `timing` feature to the `cranelift-codegen` crate
which is enabled by default. This feature gates the timing functionality
in Cranelift to enable turning it off if desired. The goal of this
commit is to remove a system dependency on `Instant` for possibly
esoteric environments.
* Consolidate platform-specific definitions in Wasmtime
Prior to this commit Wasmtime did not not have a style or system for
containing platform-specific logic in files. The goal of this commit is
to consolidate all platform-specific functionality into one location to
make it easier to port Wasmtime to new systems. This commit creates a
`sys` module within the `wasmtime-runtime` crate which conditionally
defines all of the platform support that Wasmtime requires, namely
things related to virtual memory management and trap handling. Many of
the previous `unix.rs` files interspersed throughout the tree are now
all located in a single `unix` directory. This additionally helps split
out `miri`-specific functionality by pretending `miri` is its own
platform.
This change additionally goes through `#[cfg]` directives throughout
`wasmtime-runtime`, `wasmtime-jit`, and `wasmtime` itself to place all
of this target-specific functionality within this `sys` directory. The
end state is that there are two new top-level modules in the
`wasmtime-runtime` crate:
* `arch` - this conditionally defines architecture-specific logic such
as the state used by backtraces, libcalls, etc.
* `sys` - this conditionally defines OS or platform-specific logic such
as virtual memory management.
One secondary goal of this commit is to enable the ability to easily
add new platforms to Wasmtime, even if it's in a fork of Wasmtime.
Previously patches might have to touch a good number of locations where
now they'd ideally only have to touch `sys/mod.rs` to declare a new
platform and `sys/$platform/*.rs` to define all the functionality.
* Fix build on Windows
prtest:full
* Fix some build warnings
* Fix miri build
* Include debug-builtins when testing
* Try to fix Windows tests
* Fix warnings on miri
* Fix miri build
* Fix debug-builtins feature
* More feature fixes
* Rename `fd` field
* Fix speeling
* Review comments
* mpk: allow checking for MPK without a config instance
It is inconvenient to have to construct a `PoolingAllocationConfig` in
order to check if memory protection keys are available. This removes
the unused `&self` restriction.
* mpk: improve logging of calculated slab layout
When double-checking the slab layout calculations it is quite convenient
to see the total slab size. This helps in correlating with mapped
regions.
* mpk: add an example testing the memory limits
This adds an example that can be run with `cargo run --example mpk`. Not
only does the example demonstrate how to build a pool-allocated engine
that uses MPK, it performs an exponential search to find the maximum
number of slots the system can support, with and without MPK.
* review: document Linux requirement
* review: `env_logger::init`
* review: replace `proc-maps` with manual parsing
* vet: audit `bytesize`
* fix: provide `main` for non-Linux systems
* fix: move `cfg` to avoid unused code
This commit updates to the latest wasm-tools and `wit-bindgen` to bring
the family of crates forward. This update notably includes Nick's work
on packed indices in the `wasmparser` crate for validation for the
upcoming implementation of GC types. This meant that translation from
`wasmparser` types to Wasmtime types now may work with a "type id"
instead of just a type index which required plumbing not only Wasmtime's
own type information but additionally `wasmparser`'s type information
throughout translation.
This required a fair bit of refactoring to get this working but no
change in functionality is intended, only a different way of doing
everything prior.
* Configure Rust lints at the workspace level
This commit adds necessary configuration knobs to have lints configured
at the workspace level in Wasmtime rather than the crate level. This
uses a feature of Cargo first released with 1.74.0 (last week) of the
`[workspace.lints]` table. This should help create a more consistent set
of lints applied across all crates in our workspace in addition to
possibly running select clippy lints on CI as well.
* Move `unused_extern_crates` to the workspace level
This commit configures a `deny` lint level for the
`unused_extern_crates` lint to the workspace level rather than the
previous configuration at the individual crate level.
* Move `trivial_numeric_casts` to workspace level
* Change workspace lint levels to `warn`
CI will ensure that these don't get checked into the codebase and
otherwise provide fewer speed bumps for in-process development.
* Move `unstable_features` lint to workspace level
* Move `unused_import_braces` lint to workspace level
* Start running Clippy on CI
This commit configures our CI to run `cargo clippy --workspace` for all
merged PRs. Historically this hasn't been all the feasible due to the
amount of configuration required to control the number of warnings on
CI, but with Cargo's new `[lint]` table it's possible to have a
one-liner to silence all lints from Clippy by default. This commit by
default sets the `all` lint in Clippy to `allow` to by-default disable
warnings from Clippy. The goal of this PR is to enable selective access
to Clippy lints for Wasmtime on CI.
* Selectively enable `clippy::cast_sign_loss`
This would have fixed#7558 so try to head off future issues with that
by warning against this situation in a few crates. This lint is still
quite noisy though for Cranelift for example so it's not worthwhile at
this time to enable it for the whole workspace.
* Fix CI error
prtest:full
* Update `errno` crate to drop unused dependency
Small change to our dependency graph.
* Update rayon-core to drop some dependency edges
Just a bit of pruning for our dependency graph.
* Update num_cpus dependency to drop a dependency
Minor pruning of our dependency graph.
Pull in bytecodealliance/wasm-tools#1277 to switch the defaults for some
WIT behaviors:
* Semicolons are now required by default in WIT files
* Wasm-encoded WIT packages now use the "new" format by default.
WIT files without semicolons can still be parsed with
`WIT_REQUIRE_SEMICOLONS=0`. The "old" format for wasm-encoded WIT
packages can be emitted via `WIT_COMPONENT_ENCODING_V2=0`. Note that for
wasm-encoded WIT packages both the old and the new format can be decoded
irregardless of env vars.
* Update wasm-tools crates
This commit updates the wasm-tools family of crate for a number of
notable updates:
* bytecodealliance/wasm-tools#1257 - wasmparser's ID-based
infrastructure has been refactored to have more precise types for each
ID rather than one all-purpose `TypeId`.
* bytecodealliance/wasm-tools#1262 - the implementation of
"implementation imports" for the component model which both updates
the binary format in addition to adding more syntactic forms of
imports.
* bytecodealliance/wasm-tools#1260 - a new encoding scheme for component
information for `wit-component` in objects (not used by Wasmtime but
used by bindings generators).
Translation for components needed to be updated to account for the first
change, but otherwise this was a straightforward update.
* Remove a TODO
* Add compatibility shims for Wasmtime 13 CLI
This commit introduces a compatibility shim for the Wasmtime 13 CLI and
prior. The goal of this commit is to address concerns raised in #7336
and other locations as well. While the new CLI cannot be un-shipped at
this point this PR attempts to ameliorate the situation somewhat through
a few avenues:
* A complete copy of the old CLI parser is now included in `wasmtime` by
default.
* The `WASMTIME_NEW_CLI=0` environment variable can force usage of the
old CLI parser for the `run` and `compile` commands.
* The `WASMTIME_NEW_CLI=1` environment variable can force usage of the
new CLI parser.
* Otherwise both the old and the new CLI parser are executed. Depending
on the result one is selected to be executed, possibly with a warning
printed.
* If both CLI parsers succeed but produce the same result, then no
warning is emitted and execution continues as usual.
* If both CLI parsers succeed but produce different results then a
warning is emitted indicating this. The warning points to #7384 which
has further examples of how to squash the warning. The warning also
mentions the above env var to turn the warning off. In this situation
the old semantics are used at this time instead of the new semantics.
It's intended that eventually this will change in the future.
* If the new CLI succeeds and the old CLI fails then the new semantics
are executed without warning.
* If the old CLI succeeds and the new CLI fails then a warning is issued
and the old semantics are used.
* If both the old and the new CLI fail to parse then the error message
for the new CLI is emitted.
Note that this doesn't add up to a perfect transition. The hope is that
most of the major cases of change at the very least have something
printed. My plan is to land this on `main` and then backport it to the
14.0.0 branch as a 14.0.3 release.
* Wordsmith messages
* Update messages
* More wording updates
* Fix grammar
* More updates