github
/
cranelift
mirror of https://github.com/bytecodealliance/wasmtime.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
10371 Commits
49 Branches
140 Tags
128 MiB
Tree: 24da5f7787
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '24da5f7787'
${ noResults }
cranelift/Cargo.lock

3983 lines
87 KiB
Raw Normal View History

Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
Update `rand` dependency to 0.8.3.
4 years ago
version = 3
Update `gimli` to 0.25; `addr2line` to 0.16
3 years ago
[[package]]
name = "addr2line"
Update addr2line and gimli deps (#3580) Just a routine update, figured it was good to stay close to their most recent versions
3 years ago
version = "0.17.0"
Update `gimli` to 0.25; `addr2line` to 0.16
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update addr2line and gimli deps (#3580) Just a routine update, figured it was good to stay close to their most recent versions
3 years ago
checksum = "b9ecd88a8c8378ca913a680cd98f0f13ac67383d35993f86c90a70e3f137816b"
Update `gimli` to 0.25; `addr2line` to 0.16
3 years ago
dependencies = [
Update `backtrace` to 0.3.61
3 years ago
"gimli",
externref: implement stack map-based garbage collection For host VM code, we use plain reference counting, where cloning increments the reference count, and dropping decrements it. We can avoid many of the on-stack increment/decrement operations that typically plague the performance of reference counting via Rust's ownership and borrowing system. Moving a `VMExternRef` avoids mutating its reference count, and borrowing it either avoids the reference count increment or delays it until if/when the `VMExternRef` is cloned. When passing a `VMExternRef` into compiled Wasm code, we don't want to do reference count mutations for every compiled `local.{get,set}`, nor for every function call. Therefore, we use a variation of **deferred reference counting**, where we only mutate reference counts when storing `VMExternRef`s somewhere that outlives the activation: into a global or table. Simultaneously, we over-approximate the set of `VMExternRef`s that are inside Wasm function activations. Periodically, we walk the stack at GC safe points, and use stack map information to precisely identify the set of `VMExternRef`s inside Wasm activations. Then we take the difference between this precise set and our over-approximation, and decrement the reference count for each of the `VMExternRef`s that are in our over-approximation but not in the precise set. Finally, the over-approximation is replaced with the precise set. The `VMExternRefActivationsTable` implements the over-approximized set of `VMExternRef`s referenced by Wasm activations. Calling a Wasm function and passing it a `VMExternRef` moves the `VMExternRef` into the table, and the compiled Wasm function logically "borrows" the `VMExternRef` from the table. Similarly, `global.get` and `table.get` operations clone the gotten `VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the reference out of the table. When a `VMExternRef` is returned to host code from a Wasm function, the host increments the reference count (because the reference is logically "borrowed" from the `VMExternRefActivationsTable` and the reference count from the table will be dropped at the next GC). For more general information on deferred reference counting, see *An Examination of Deferred Reference Counting and Cycle Detection* by Quinane: https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf cc #929 Fixes #1804
4 years ago
]
[[package]]
Wasmtime 0.19.0 and Cranelift 0.66.0 (#2027) This commit updates Wasmtime's version to 0.19.0, Cranelift's version to 0.66.0, and updates the release notes as well.
4 years ago
name = "adler"
Update version for fs-set-times to 3.1
4 years ago
version = "1.0.2"
externref: implement stack map-based garbage collection For host VM code, we use plain reference counting, where cloning increments the reference count, and dropping decrements it. We can avoid many of the on-stack increment/decrement operations that typically plague the performance of reference counting via Rust's ownership and borrowing system. Moving a `VMExternRef` avoids mutating its reference count, and borrowing it either avoids the reference count increment or delays it until if/when the `VMExternRef` is cloned. When passing a `VMExternRef` into compiled Wasm code, we don't want to do reference count mutations for every compiled `local.{get,set}`, nor for every function call. Therefore, we use a variation of **deferred reference counting**, where we only mutate reference counts when storing `VMExternRef`s somewhere that outlives the activation: into a global or table. Simultaneously, we over-approximate the set of `VMExternRef`s that are inside Wasm function activations. Periodically, we walk the stack at GC safe points, and use stack map information to precisely identify the set of `VMExternRef`s inside Wasm activations. Then we take the difference between this precise set and our over-approximation, and decrement the reference count for each of the `VMExternRef`s that are in our over-approximation but not in the precise set. Finally, the over-approximation is replaced with the precise set. The `VMExternRefActivationsTable` implements the over-approximized set of `VMExternRef`s referenced by Wasm activations. Calling a Wasm function and passing it a `VMExternRef` moves the `VMExternRef` into the table, and the compiled Wasm function logically "borrows" the `VMExternRef` from the table. Similarly, `global.get` and `table.get` operations clone the gotten `VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the reference out of the table. When a `VMExternRef` is returned to host code from a Wasm function, the host increments the reference count (because the reference is logically "borrowed" from the `VMExternRefActivationsTable` and the reference count from the table will be dropped at the next GC). For more general information on deferred reference counting, see *An Examination of Deferred Reference Counting and Cycle Detection* by Quinane: https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf cc #929 Fixes #1804
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update version for fs-set-times to 3.1
4 years ago
checksum = "f26201604c87b1e01bd3d98f8d5d9a8fcbb815e8cedb41ffccbeb4bf593a35fe"
externref: implement stack map-based garbage collection For host VM code, we use plain reference counting, where cloning increments the reference count, and dropping decrements it. We can avoid many of the on-stack increment/decrement operations that typically plague the performance of reference counting via Rust's ownership and borrowing system. Moving a `VMExternRef` avoids mutating its reference count, and borrowing it either avoids the reference count increment or delays it until if/when the `VMExternRef` is cloned. When passing a `VMExternRef` into compiled Wasm code, we don't want to do reference count mutations for every compiled `local.{get,set}`, nor for every function call. Therefore, we use a variation of **deferred reference counting**, where we only mutate reference counts when storing `VMExternRef`s somewhere that outlives the activation: into a global or table. Simultaneously, we over-approximate the set of `VMExternRef`s that are inside Wasm function activations. Periodically, we walk the stack at GC safe points, and use stack map information to precisely identify the set of `VMExternRef`s inside Wasm activations. Then we take the difference between this precise set and our over-approximation, and decrement the reference count for each of the `VMExternRef`s that are in our over-approximation but not in the precise set. Finally, the over-approximation is replaced with the precise set. The `VMExternRefActivationsTable` implements the over-approximized set of `VMExternRef`s referenced by Wasm activations. Calling a Wasm function and passing it a `VMExternRef` moves the `VMExternRef` into the table, and the compiled Wasm function logically "borrows" the `VMExternRef` from the table. Similarly, `global.get` and `table.get` operations clone the gotten `VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the reference out of the table. When a `VMExternRef` is returned to host code from a Wasm function, the host increments the reference count (because the reference is logically "borrowed" from the `VMExternRefActivationsTable` and the reference count from the table will be dropped at the next GC). For more general information on deferred reference counting, see *An Examination of Deferred Reference Counting and Cycle Detection* by Quinane: https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf cc #929 Fixes #1804
4 years ago
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "aead"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.4.3"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "0b613b8e1e3cf911a086f53f03bf286f52fd7a7258e4fa606f0ef220d39d8877"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"generic-array",
]
[[package]]
name = "aes"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.7.5"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "9e8b47f52ea9bae42228d07ec09eb676433d7c4ed1ebdf0f1d1c29ed446f1ab8"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"cipher",
ISLE: guard against stale generated source in default build config. Currently, the `build.rs` script that generates Rust source from the ISLE DSL will only do this generation if the `rebuild-isle` Cargo feature is specified. By default, it is not. This is based on the principle that we (the build script) do not modify the source tree as managed by git; git-managed files are strictly a human-managed and human-edited resource. By adding the opt-in Cargo feature, a developer is requesting the build script to perform an explicit action. (In my understanding at least, this principle comes from the general philosophy of hermetic builds: the output should be a pure function of the input, and part of this is that the input is read-only. If we modify the source tree, then all bets are off.) Unfortunately, requiring the opt-in feature also creates a footgun that is easy to hit: if a developer modifies the ISLE DSL source, but forgets to specify the Cargo feature, then the compiler will silently be built successfully with stale source, and will silently exclude any changes that were made. The generated source is checked into git for a good reason: we want DSL compiler to not affect build times for the overwhelmingly common case that Cranelift is used as a dependency but the backends are not being actively developed. (This overhead comes mainly from building `islec` itself.) So, what to do? This PR implements a middle ground first described in [this conversation](https://github.com/bytecodealliance/wasmtime/pull/3506#discussion_r743113351), in which we: - Generate a hash (SHA-512) of the ISLE DSL source and produce a "manifest" of ISLE inputs alongside the generated source; and - Always read the ISLE DSL source, and see if the manifest is still valid, on builds that do not have the opt-in "rebuild" feature. This allows us to know whether the ISLE compiler output would have been the same (modulo changes to the DSL compiler itself, which are out-of-scope here), without actually building the ISLE compiler and running it. If the compiler-backend developer modifies an ISLE source file and then tries to build `cranelift-codegen` without adding the `rebuild-isle` Cargo feature, they get the following output: ```text Error: the ISLE source files that resulted in the generated Rust source * src/isa/x64/lower/isle/generated_code.rs have changed but the generated source was not rebuilt! These ISLE source files are: * src/clif.isle * src/prelude.isle * src/isa/x64/inst.isle * src/isa/x64/lower.isle Please add `--features rebuild-isle` to your `cargo build` command if you wish to rebuild the generated source, then include these changes in any git commits you make that include the changes to the ISLE. For example: $ cargo build -p cranelift-codegen --features rebuild-isle (This build script cannot do this for you by default because we cannot modify checked-into-git source without your explicit opt-in.) ``` which will tell them exactly what they need to do to fix the problem! Note that I am leaving the "Rebuild ISLE" CI job alone for now, because otherwise, we are trusting whomever submits a PR to generate the correct generated source. In other words, the manifest is a communication from the checked-in tree to the developer, but we still need to verify that the checked-in generated Rust source and the manifest are correct with respect to the checked-in ISLE source.
3 years ago
"cpufeatures",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"opaque-debug",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
]
[[package]]
name = "aes-gcm"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.9.4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "df5f85a83a7d8b0442b6aa7b504b8212c1733da07b98aae43d4bc21b2cb3cdf6"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"aead",
"aes",
"cipher",
"ctr",
"ghash",
"subtle",
]
Hook up all crates via path dependencies
5 years ago
[[package]]
name = "ahash"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.7.6"
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "fcb51a0695d8f838b1ee009b3fbf66bda078cd64590202a864a8f3e8c4315c47"
dependencies = [
"getrandom 0.2.6",
"once_cell",
"version_check",
]
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "aho-corasick"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "0.7.18"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "1e37cfd5e7657ada45f742d6e99ca5788580b5c529dc78faf11ece6dc702656f"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"memchr",
]
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
[[package]]
name = "ambient-authority"
Update to cap-std 0.17.0. (#3198) This completes the posish->rsix rename, and contains a number of other minor cleanups, including avoiding the `cstr` dependency.
3 years ago
version = "0.0.1"
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.17.0. (#3198) This completes the posish->rsix rename, and contains a number of other minor cleanups, including avoiding the `cstr` dependency.
3 years ago
checksum = "ec8ad6edb4840b78c5c3d88de606b22252d552b55f3a4699fbb10fc070ec3049"
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "anyhow"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "1.0.57"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "08f9b8508dccb7687a1d6c4ce66b2b0ecef467c94667de27d8d7fe1f8d2a9cdc"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "arbitrary"
Fuzz cranelift cpu flag settings with Wasmtime (#3800) * Fuzz cranelift cpu flag settings with Wasmtime This commit updates the `Config` fuzz-generator to consume some of the input as configuration settings for codegen flags we pass to cranelift. This should allow for ideally some more coverage where settings are disabled or enabled, ideally finding possible bugs in feature-specific implementations or generic implementations that are rarely used if the feature-specific ones almost always take precedent. The technique used in this commit is to weight selection of codegen settings less frequently than using the native settings. Afterwards each listed feature is individually enabled or disabled depending on the input fuzz data, and if a feature is enabled but the host doesn't actually support it then the fuzz input is rejected with a log message. The goal here is to still have many fuzz inputs accepted but also ensure determinism across hosts. If there's a bug specifically related to enabling a flag then running it on a host without the flag should indicate that the flag isn't supported rather than silently leaving it disabled and reporting the fuzz case a success. * Use built-in `Unstructured::ratio` method * Tweak macro * Bump arbitrary dep version
3 years ago
version = "1.1.0"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Fuzz cranelift cpu flag settings with Wasmtime (#3800) * Fuzz cranelift cpu flag settings with Wasmtime This commit updates the `Config` fuzz-generator to consume some of the input as configuration settings for codegen flags we pass to cranelift. This should allow for ideally some more coverage where settings are disabled or enabled, ideally finding possible bugs in feature-specific implementations or generic implementations that are rarely used if the feature-specific ones almost always take precedent. The technique used in this commit is to weight selection of codegen settings less frequently than using the native settings. Afterwards each listed feature is individually enabled or disabled depending on the input fuzz data, and if a feature is enabled but the host doesn't actually support it then the fuzz input is rejected with a log message. The goal here is to still have many fuzz inputs accepted but also ensure determinism across hosts. If there's a bug specifically related to enabling a flag then running it on a host without the flag should indicate that the flag isn't supported rather than silently leaving it disabled and reporting the fuzz case a success. * Use built-in `Unstructured::ratio` method * Tweak macro * Bump arbitrary dep version
3 years ago
checksum = "c38b6b6b79f671c25e1a3e785b7b82d7562ffc9cd3efdc98627e5668a2472490"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
dependencies = [
"derive_arbitrary",
]
Cranelift: Use bump allocation in `remove_constant_phis` pass (#4710) * Cranelift: Use bump allocation in `remove_constant_phis` pass This makes compilation 2-6% faster for Sightglass's bz2 benchmark: ``` compilation :: cycles :: benchmarks/bz2/benchmark.wasm Δ = 7290648.36 ± 4245152.07 (confidence = 99%) bump.so is 1.02x to 1.06x faster than main.so! [166388177 183238542.98 214732518] bump.so [172836648 190529191.34 217514271] main.so compilation :: cycles :: benchmarks/pulldown-cmark/benchmark.wasm No difference in performance. [182220055 225793551.12 277857575] bump.so [193212613 227784078.61 277175335] main.so compilation :: cycles :: benchmarks/spidermonkey/benchmark.wasm No difference in performance. [3848442474 4295214144.37 4665127241] bump.so [3969505457 4262415290.10 4563869974] main.so ``` * Add audit for `bumpalo` * Add an audit of `arrayvec` version 0.7.2 * Remove unnecessary `collect` into `Vec` I wasn't able to measure any perf difference here, but its nice to do anyways. * Use a `SecondaryMap` for keeping track of summaries
2 years ago
[[package]]
name = "arrayvec"
version = "0.7.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8da52d66c7071e2e3fa2a1e5c6d088fec47b593032b254f5e980de8ea54454d6"
bump cargo.lock, add wiggle-generate and wiggle-macro to workspace wiggle-macro doc tests weren't being run, so docs had gotten out of sync.
4 years ago
[[package]]
name = "async-trait"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.1.53"
bump cargo.lock, add wiggle-generate and wiggle-macro to workspace wiggle-macro doc tests weren't being run, so docs had gotten out of sync.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "ed6aa3524a2dfcf9fe180c51eae2b58738348d819517ceadf95789c51fff7600"
bump cargo.lock, add wiggle-generate and wiggle-macro to workspace wiggle-macro doc tests weren't being run, so docs had gotten out of sync.
4 years ago
dependencies = [
"proc-macro2",
"quote",
"syn",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "atty"
Bump version to 0.9.0 (#790)
5 years ago
version = "0.2.14"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Bump version to 0.9.0 (#790)
5 years ago
checksum = "d9b39be18770d11421cdb1b9947a45dd3f37e93092cbf377614828a319d5fee8"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"hermit-abi 0.1.19",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"libc",
"winapi",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "autocfg"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.8"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "0dde43e75fd43e8a1bf86103336bc699aa8d17ad1be60c76c0bdfd4828e19b78"
dependencies = [
"autocfg 1.1.0",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
Hook up all crates via path dependencies
5 years ago
[[package]]
name = "autocfg"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.1.0"
Bump version to 0.9.0 (#790)
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "d468802bab17cbc0cc575e9b053f41e72aa36bfa6b7f55e3529ffa43161b97fa"
Bump version to 0.9.0 (#790)
5 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "backtrace"
Update some dependency versions used by Wasmtime (#4405) No major motivation here, mostly just dependency gardening.
2 years ago
version = "0.3.66"
externref: Address review feedback
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependency versions used by Wasmtime (#4405) No major motivation here, mostly just dependency gardening.
2 years ago
checksum = "cab84319d616cfb654d03394f38ab7e6f0919e181b1b57e1fd15e7fb4077d9a7"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update `backtrace` to 0.3.61
3 years ago
"addr2line",
Upgrade to the latest versions of gimli, addr2line, object (#2901) * Upgrade to the latest versions of gimli, addr2line, object And adapt to API changes. New gimli supports wasm dwarf, resulting in some simplifications in the debug crate. * upgrade gimli usage in linux-specific profiling too * Add "continue" statement after interpreting a wasm local dwarf opcode
4 years ago
"cc",
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"libc",
externref: implement stack map-based garbage collection For host VM code, we use plain reference counting, where cloning increments the reference count, and dropping decrements it. We can avoid many of the on-stack increment/decrement operations that typically plague the performance of reference counting via Rust's ownership and borrowing system. Moving a `VMExternRef` avoids mutating its reference count, and borrowing it either avoids the reference count increment or delays it until if/when the `VMExternRef` is cloned. When passing a `VMExternRef` into compiled Wasm code, we don't want to do reference count mutations for every compiled `local.{get,set}`, nor for every function call. Therefore, we use a variation of **deferred reference counting**, where we only mutate reference counts when storing `VMExternRef`s somewhere that outlives the activation: into a global or table. Simultaneously, we over-approximate the set of `VMExternRef`s that are inside Wasm function activations. Periodically, we walk the stack at GC safe points, and use stack map information to precisely identify the set of `VMExternRef`s inside Wasm activations. Then we take the difference between this precise set and our over-approximation, and decrement the reference count for each of the `VMExternRef`s that are in our over-approximation but not in the precise set. Finally, the over-approximation is replaced with the precise set. The `VMExternRefActivationsTable` implements the over-approximized set of `VMExternRef`s referenced by Wasm activations. Calling a Wasm function and passing it a `VMExternRef` moves the `VMExternRef` into the table, and the compiled Wasm function logically "borrows" the `VMExternRef` from the table. Similarly, `global.get` and `table.get` operations clone the gotten `VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the reference out of the table. When a `VMExternRef` is returned to host code from a Wasm function, the host increments the reference count (because the reference is logically "borrowed" from the `VMExternRefActivationsTable` and the reference count from the table will be dropped at the next GC). For more general information on deferred reference counting, see *An Examination of Deferred Reference Counting and Cycle Detection* by Quinane: https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf cc #929 Fixes #1804
4 years ago
"miniz_oxide",
Update `object` to 0.26.0
3 years ago
"object",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"rustc-demangle",
]
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
[[package]]
name = "base64"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
version = "0.13.0"
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
checksum = "904dfeac50f3cdaba28fc6f57fdcddb75f49ed61346676a78c4ffe55877802fd"
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
[[package]]
name = "base64ct"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.1.1"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "e6b4d9b1225d28d360ec6a231d65af1fd99a2a095154c8040689617290569c5c"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "bincode"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "1.3.3"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "b1f45e9417d87227c7a56d22e471c6206462cba514c7590c09aff4cf6d1ddcad"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"serde",
]
Fix wiggle's tests
5 years ago
[[package]]
name = "bit-set"
externref: Address review feedback
4 years ago
version = "0.5.2"
Fix wiggle's tests
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
externref: Address review feedback
4 years ago
checksum = "6e11e16035ea35e4e5997b393eacbf6f63983188f7a2ad25bfb13465f5ad59de"
Fix wiggle's tests
5 years ago
dependencies = [
"bit-vec",
]
[[package]]
name = "bit-vec"
cargo update
4 years ago
version = "0.6.3"
Fix wiggle's tests
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
cargo update
4 years ago
checksum = "349f9b6a179ed607305526ca489b34ad0a41aed5f7980fa90eb03160b69598fb"
Fix wiggle's tests
5 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "bitflags"
Update to cap-std 0.19.0 and rsix 0.22.4. (#3331) This pulls in the s390x fix needed by #3330. Also a small `rsix` API update; `PollFdVec` has been removed in favor of just using `Vec<PollFd>`.
3 years ago
version = "1.3.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.19.0 and rsix 0.22.4. (#3331) This pulls in the s390x fix needed by #3330. Also a small `rsix` API update; `PollFdVec` has been removed in favor of just using `Vec<PollFd>`.
3 years ago
checksum = "bef38d45163c2f1dde094a7dfd33ccf595c92905c8f8f4fdc18d06fb1037718a"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "block-buffer"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
version = "0.9.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
checksum = "4152116fd6e9dadb291ae18fc1ec3575ed6d84c29642d97890f4b4a3417297e4"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"generic-array",
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "bstr"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.2.17"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "ba3569f383e8f1598449f1a423e72e99569137b47740b1da11ef19af3d5c3223"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"lazy_static",
"memchr",
"regex-automata",
"serde",
]
cranelift: Port most of `simple_preopt.rs` over to the `peepmatic` DSL This ports all of the identity, no-op, simplification, and canonicalization related optimizations over from being hand-coded to the `peepmatic` DSL. This does not handle the branch-to-branch optimizations or most of the divide-by-constant optimizations.
5 years ago
[[package]]
name = "bumpalo"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "3.9.1"
cranelift: Port most of `simple_preopt.rs` over to the `peepmatic` DSL This ports all of the identity, no-op, simplification, and canonicalization related optimizations over from being hand-coded to the `peepmatic` DSL. This does not handle the branch-to-branch optimizations or most of the divide-by-constant optimizations.
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "a4a45a46ab1f2412e53d3a0ade76ffad2025804294569aae387231a0cd6e0899"
cranelift: Port most of `simple_preopt.rs` over to the `peepmatic` DSL This ports all of the identity, no-op, simplification, and canonicalization related optimizations over from being hand-coded to the `peepmatic` DSL. This does not handle the branch-to-branch optimizations or most of the divide-by-constant optimizations.
5 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "byteorder"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "1.4.3"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "14c189c53d098945499cdfa7ecc63567cf3886b3332b312a5b4585d8d3a6a610"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
use some better traits
4 years ago
[[package]]
name = "bytes"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.1.0"
use some better traits
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "c4872d67bab6358e59559027aa3b9157c53d9358c51423c17554809a8858e0f8"
use some better traits
4 years ago
cap-std 0.13
4 years ago
[[package]]
name = "cap-fs-ext"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
version = "0.26.0"
cap-std 0.13
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
checksum = "d6540a9d9002b6ec6fe5f1bbbfcded600a16018570c64fedbc5ccad0632b8edc"
cap-std 0.13
4 years ago
dependencies = [
system-interface 0.6
4 years ago
"cap-primitives",
"cap-std",
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"io-lifetimes",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
test-programs: learn how to preopen a dir again
4 years ago
]
cap-std 0.13
4 years ago
[[package]]
name = "cap-primitives"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
version = "0.26.0"
cap-std 0.13
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
checksum = "591dbd5ace8712534c781367a16b46b620564153f88dfed85e7f609638f52e01"
cap-std 0.13
4 years ago
dependencies = [
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"ambient-authority",
cap-std 0.13
4 years ago
"fs-set-times",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"io-extras",
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"io-lifetimes",
cap-std 0.13
4 years ago
"ipnet",
"maybe-owned",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
cap-std 0.13
4 years ago
"winapi-util",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
cap-std 0.13
4 years ago
"winx",
]
use cap_rand instead of getrandom
4 years ago
[[package]]
name = "cap-rand"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
version = "0.26.0"
impl WasiFile for cap_std::fs::File
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
checksum = "d2832496b1552ea04fb9267a70f831697c67d4bf9656ada6b9f93d4640e78485"
impl WasiFile for cap_std::fs::File
4 years ago
dependencies = [
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"ambient-authority",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"rand 0.8.5",
test-programs: learn how to preopen a dir again
4 years ago
]
cap-std 0.13
4 years ago
[[package]]
name = "cap-std"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
version = "0.26.0"
cap-std 0.13
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
checksum = "2a6652184ef93583621d582105885a82cc7c6f522662390a15658e6d098c833c"
cap-std 0.13
4 years ago
dependencies = [
system-interface 0.6
4 years ago
"cap-primitives",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"io-extras",
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"io-lifetimes",
"ipnet",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
impl WasiFile for cap_std::fs::File
4 years ago
]
wasi-tokio kinda sorta working
4 years ago
[[package]]
name = "cap-tempfile"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
version = "0.26.0"
wasi-tokio kinda sorta working
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
checksum = "cc76d2cf04cd69960421f484ac5a82802546fada52b26253e1e51a44fc318c34"
wasi-tokio kinda sorta working
4 years ago
dependencies = [
"cap-std",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"rand 0.8.5",
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
"rustix",
Upgrade listenfd to v1.0.0 (#4197) Previously, `listenfd` depended on an old version of the `uuid` crate which caused cargo deny failures. https://github.com/mitsuhiko/listenfd/pull/13 upgrades the `uuid` dependency and a new version of `listenfd` is published. This change moves to the latest version of `listenfd`.
2 years ago
"uuid",
wasi-tokio kinda sorta working
4 years ago
]
add clocks!
4 years ago
[[package]]
name = "cap-time-ext"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
version = "0.26.0"
add clocks!
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
checksum = "8cd90913f359a8baff03c1c8b8e5655d2a465da561344da85f052d5fa3091d8c"
add clocks!
4 years ago
dependencies = [
system-interface 0.6
4 years ago
"cap-primitives",
add clocks!
4 years ago
"once_cell",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
rename everything c2 related to the "real" names
4 years ago
"winx",
add clocks!
4 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "capstone"
Upgrade capstone to v0.9
3 years ago
version = "0.9.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Upgrade capstone to v0.9
3 years ago
checksum = "178b3c80b4ce3939792d1dd6600575e012da806a10e81abe812dc29cbfe629ec"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"capstone-sys",
Get lightbeam compiling on stable Rust (#2370) This will hopefully remove a small thorn in our side with periodic nightly breakage due to nightly features changing. This commit moves lightbeam to stable Rust, swapping out `staticvec` for `arrayvec` and otherwise updating some dependencies (namely `dynasm`) to compile with stable. This then also updates CI appropriately to not use a pinned nightly and instead us a floating `nightly` channel so we can head off any breakage coming up ASAP.
4 years ago
"libc",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "capstone-sys"
Upgrade capstone to v0.9
3 years ago
version = "0.13.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Upgrade capstone to v0.9
3 years ago
checksum = "cf2f3d97b88fa4a9a6464c7c08b8c4588aaea8c18d0651eca11f2ca15f50f1f6"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"cc",
Get lightbeam compiling on stable Rust (#2370) This will hopefully remove a small thorn in our side with periodic nightly breakage due to nightly features changing. This commit moves lightbeam to stable Rust, swapping out `staticvec` for `arrayvec` and otherwise updating some dependencies (namely `dynasm`) to compile with stable. This then also updates CI appropriately to not use a pinned nightly and instead us a floating `nightly` channel so we can head off any breakage coming up ASAP.
4 years ago
"libc",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "cast"
Drop a few crates from our dependency graph (#5009) A minor update of a few other crates drops `semver` and `rustc_version` from `Cargo.lock`. I've audited the deltas in versions for the other crates here as well and they all look good.
2 years ago
version = "0.3.0"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Drop a few crates from our dependency graph (#5009) A minor update of a few other crates drops `semver` and `rustc_version` from `Cargo.lock`. I've audited the deltas in versions for the other crates here as well and they all look good.
2 years ago
checksum = "37b2a672a2cb129a2e41c10b1224bb368f9f37a2b16b612598138befd7b37eb5"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "cc"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.0.73"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "2fff2a6927b3bb87f9595d67196a70493f627687a71d87a0d692242c33f58c11"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"jobserver",
]
Replace unmaintained directories crate Fixes RUSTSEC-2020-0054 warning from cargo-audit/cargo-deny, follows the recommendation to switch to the new maintained `directories-next` crate fork Only affects the cache directory determination for the environment and was a simple search'n'replace to this fork so don't think behavior has changed. https://rustsec.org/advisories/RUSTSEC-2020-0054
4 years ago
[[package]]
name = "cfg-if"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "chacha20"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.8.1"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "01b72a433d0cf2aef113ba70f62634c56fddb0f244e6377185c56a7cadbd8f91"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"cipher",
ISLE: guard against stale generated source in default build config. Currently, the `build.rs` script that generates Rust source from the ISLE DSL will only do this generation if the `rebuild-isle` Cargo feature is specified. By default, it is not. This is based on the principle that we (the build script) do not modify the source tree as managed by git; git-managed files are strictly a human-managed and human-edited resource. By adding the opt-in Cargo feature, a developer is requesting the build script to perform an explicit action. (In my understanding at least, this principle comes from the general philosophy of hermetic builds: the output should be a pure function of the input, and part of this is that the input is read-only. If we modify the source tree, then all bets are off.) Unfortunately, requiring the opt-in feature also creates a footgun that is easy to hit: if a developer modifies the ISLE DSL source, but forgets to specify the Cargo feature, then the compiler will silently be built successfully with stale source, and will silently exclude any changes that were made. The generated source is checked into git for a good reason: we want DSL compiler to not affect build times for the overwhelmingly common case that Cranelift is used as a dependency but the backends are not being actively developed. (This overhead comes mainly from building `islec` itself.) So, what to do? This PR implements a middle ground first described in [this conversation](https://github.com/bytecodealliance/wasmtime/pull/3506#discussion_r743113351), in which we: - Generate a hash (SHA-512) of the ISLE DSL source and produce a "manifest" of ISLE inputs alongside the generated source; and - Always read the ISLE DSL source, and see if the manifest is still valid, on builds that do not have the opt-in "rebuild" feature. This allows us to know whether the ISLE compiler output would have been the same (modulo changes to the DSL compiler itself, which are out-of-scope here), without actually building the ISLE compiler and running it. If the compiler-backend developer modifies an ISLE source file and then tries to build `cranelift-codegen` without adding the `rebuild-isle` Cargo feature, they get the following output: ```text Error: the ISLE source files that resulted in the generated Rust source * src/isa/x64/lower/isle/generated_code.rs have changed but the generated source was not rebuilt! These ISLE source files are: * src/clif.isle * src/prelude.isle * src/isa/x64/inst.isle * src/isa/x64/lower.isle Please add `--features rebuild-isle` to your `cargo build` command if you wish to rebuild the generated source, then include these changes in any git commits you make that include the changes to the ISLE. For example: $ cargo build -p cranelift-codegen --features rebuild-isle (This build script cannot do this for you by default because we cannot modify checked-into-git source without your explicit opt-in.) ``` which will tell them exactly what they need to do to fix the problem! Note that I am leaving the "Rebuild ISLE" CI job alone for now, because otherwise, we are trusting whomever submits a PR to generate the correct generated source. In other words, the manifest is a communication from the checked-in tree to the developer, but we still need to verify that the checked-in generated Rust source and the manifest are correct with respect to the checked-in ISLE source.
3 years ago
"cpufeatures",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"zeroize",
]
[[package]]
name = "chacha20poly1305"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.9.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "3b84ed6d1d5f7aa9bdde921a5090e0ca4d934d250ea3b402a5fab3a994e28a2a"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"aead",
"chacha20",
"cipher",
"poly1305",
"zeroize",
]
[[package]]
name = "cipher"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.3.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "7ee52072ec15386f770805afd189a01c8841be8696bed250fa2f13c4c0d6dfb7"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"generic-array",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "clap"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "2.34.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "a0610544180c38b88101fecf2dd634b174a62eef6946f84dfc6a7127512b381c"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"bitflags",
Make ISLE part of the root Cargo workspace.
3 years ago
"textwrap 0.11.0",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"unicode-width",
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
]
[[package]]
name = "clap"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
version = "3.2.8"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
checksum = "190814073e85d238f31ff738fcb0bf6910cedeb73376c87cd69291028966fd83"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
dependencies = [
"atty",
"bitflags",
"clap_derive",
"clap_lex",
"indexmap",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"once_cell",
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
"strsim",
"termcolor",
"textwrap 0.15.0",
]
[[package]]
name = "clap_derive"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
version = "3.2.7"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
checksum = "759bf187376e1afa7b85b959e6a664a3e7a95203415dba952ad19139e798f902"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
dependencies = [
"heck",
"proc-macro-error",
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "clap_lex"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
version = "0.2.4"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
checksum = "2850f2f5a82cbf437dd5af4d49848fbdfc27c157c3d010345776f952765261c5"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
dependencies = [
"os_str_bytes",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
[[package]]
name = "component-fuzz-util"
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
version = "0.0.0"
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
dependencies = [
"anyhow",
"arbitrary",
"proc-macro2",
"quote",
"wasmtime-component-util",
]
support enums with more than 256 variants in derive macro (#4370) * support enums with more than 256 variants in derive macro This addresses #4361. Technically, we now support up to 2^32 variants, which is the maximum for the canonical ABI. In practice, though, the derived code for enums with even just 2^16 variants takes a prohibitively long time to compile. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * simplify `LowerExpander::expand_variant` code Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
[[package]]
name = "component-macro-test"
version = "0.1.0"
dependencies = [
"proc-macro2",
"quote",
"syn",
]
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
[[package]]
name = "component-test-util"
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
version = "0.0.0"
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
dependencies = [
"anyhow",
"arbitrary",
"env_logger 0.9.0",
"wasmtime",
]
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "console"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.15.0"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "a28b32d32ca44b70c3e4acd7db1babf555fa026e385fb95f18028f88848b3c31"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
dependencies = [
"encode_unicode",
"libc",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"once_cell",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"regex",
Update deps and tests for `anyref` --> `externref` * Update to using `wasmparser` 0.55.0 * Update wasmprinter to 0.2.5 * Update `wat` to 1.0.18, and `wast` to 17.0.0
5 years ago
"terminal_size",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"unicode-width",
"winapi",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "const-oid"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.6.2"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "9d6f2aa4d0537bcc1c74df8755072bd31c1ef1a3a1b85a68e8404a8c353b7b8b"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
Provide filename/line number information in `Trap` (#2452) * Provide filename/line number information in `Trap` This commit extends the `Trap` type and `Store` to retain DWARF debug information found in a wasm file unconditionally, if it's present. This then enables us to print filenames and line numbers which point back to actual source code when a trap backtrace is printed. Additionally the `FrameInfo` type has been souped up to return filename/line number information as well. The implementation here is pretty simplistic currently. The meat of all the work happens in `gimli` and `addr2line`, and otherwise wasmtime is just schlepping around bytes of dwarf debuginfo here and there! The general goal here is to assist with debugging when using wasmtime because filenames and line numbers are generally orders of magnitude better even when you already have a stack trace. Another nicety here is that backtraces will display inlined frames (learned through debug information), improving the experience in release mode as well. An example of this is that with this file: ```rust fn main() { panic!("hello"); } ``` we get this stack trace: ``` $ rustc foo.rs --target wasm32-wasi -g $ cargo run foo.wasm Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `target/debug/wasmtime foo.wasm` thread 'main' panicked at 'hello', foo.rs:2:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Error: failed to run main module `foo.wasm` Caused by: 0: failed to invoke command default 1: wasm trap: unreachable wasm backtrace: 0: 0x6c1c - panic_abort::__rust_start_panic::abort::h2d60298621b1ccbf at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/panic_abort/src/lib.rs:77:17 - __rust_start_panic at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/panic_abort/src/lib.rs:32:5 1: 0x68c7 - rust_panic at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:626:9 2: 0x65a1 - std::panicking::rust_panic_with_hook::h2345fb0909b53e12 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:596:5 3: 0x1436 - std::panicking::begin_panic::{{closure}}::h106f151a6db8c8fb at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:506:9 4: 0xda8 - std::sys_common::backtrace::__rust_end_short_backtrace::he55aa13f22782798 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153:18 5: 0x1324 - std::panicking::begin_panic::h1727e7d1d719c76f at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:505:12 6: 0xfde - foo::main::h2db1313a64510850 at /Users/acrichton/code/wasmtime/foo.rs:2:5 7: 0x11d5 - core::ops::function::FnOnce::call_once::h20ee1cc04aeff1fc at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:227:5 8: 0xddf - std::sys_common::backtrace::__rust_begin_short_backtrace::h054493e41e27e69c at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:137:18 9: 0x1d5a - std::rt::lang_start::{{closure}}::hd83784448d3fcb42 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:66:18 10: 0x69d8 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h564d3dad35014917 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:259:13 - std::panicking::try::do_call::hdca4832ace5a8603 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:381:40 - std::panicking::try::ha8624a1a6854b456 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:345:19 - std::panic::catch_unwind::h71421f57cf2bc688 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panic.rs:382:14 - std::rt::lang_start_internal::h260050c92cd470af at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:51:25 11: 0x1d0c - std::rt::lang_start::h0b4bcf3c5e498224 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:65:5 12: 0xffc - <unknown>!__original_main 13: 0x393 - __muloti4 at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/macros.rs:269 ``` This is relatively noisy by default but there's filenames and line numbers! Additionally frame 10 can be seen to have lots of frames inlined into it. All information is always available to the embedder but we could try to handle the `__rust_begin_short_backtrace` and `__rust_end_short_backtrace` markers to trim the backtrace by default as well. The only gotcha here is that it looks like `__muloti4` is out of place. That's because the libc that Rust ships with doesn't have dwarf information, although I'm not sure why we land in that function for symbolizing it... * Add a configuration switch for debuginfo * Control debuginfo by default with `WASM_BACKTRACE_DETAILS` * Try cpp_demangle on demangling as well * Rename to WASMTIME_BACKTRACE_DETAILS
4 years ago
[[package]]
name = "cpp_demangle"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.3.5"
Provide filename/line number information in `Trap` (#2452) * Provide filename/line number information in `Trap` This commit extends the `Trap` type and `Store` to retain DWARF debug information found in a wasm file unconditionally, if it's present. This then enables us to print filenames and line numbers which point back to actual source code when a trap backtrace is printed. Additionally the `FrameInfo` type has been souped up to return filename/line number information as well. The implementation here is pretty simplistic currently. The meat of all the work happens in `gimli` and `addr2line`, and otherwise wasmtime is just schlepping around bytes of dwarf debuginfo here and there! The general goal here is to assist with debugging when using wasmtime because filenames and line numbers are generally orders of magnitude better even when you already have a stack trace. Another nicety here is that backtraces will display inlined frames (learned through debug information), improving the experience in release mode as well. An example of this is that with this file: ```rust fn main() { panic!("hello"); } ``` we get this stack trace: ``` $ rustc foo.rs --target wasm32-wasi -g $ cargo run foo.wasm Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `target/debug/wasmtime foo.wasm` thread 'main' panicked at 'hello', foo.rs:2:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Error: failed to run main module `foo.wasm` Caused by: 0: failed to invoke command default 1: wasm trap: unreachable wasm backtrace: 0: 0x6c1c - panic_abort::__rust_start_panic::abort::h2d60298621b1ccbf at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/panic_abort/src/lib.rs:77:17 - __rust_start_panic at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/panic_abort/src/lib.rs:32:5 1: 0x68c7 - rust_panic at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:626:9 2: 0x65a1 - std::panicking::rust_panic_with_hook::h2345fb0909b53e12 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:596:5 3: 0x1436 - std::panicking::begin_panic::{{closure}}::h106f151a6db8c8fb at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:506:9 4: 0xda8 - std::sys_common::backtrace::__rust_end_short_backtrace::he55aa13f22782798 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153:18 5: 0x1324 - std::panicking::begin_panic::h1727e7d1d719c76f at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:505:12 6: 0xfde - foo::main::h2db1313a64510850 at /Users/acrichton/code/wasmtime/foo.rs:2:5 7: 0x11d5 - core::ops::function::FnOnce::call_once::h20ee1cc04aeff1fc at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:227:5 8: 0xddf - std::sys_common::backtrace::__rust_begin_short_backtrace::h054493e41e27e69c at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:137:18 9: 0x1d5a - std::rt::lang_start::{{closure}}::hd83784448d3fcb42 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:66:18 10: 0x69d8 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h564d3dad35014917 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:259:13 - std::panicking::try::do_call::hdca4832ace5a8603 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:381:40 - std::panicking::try::ha8624a1a6854b456 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:345:19 - std::panic::catch_unwind::h71421f57cf2bc688 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panic.rs:382:14 - std::rt::lang_start_internal::h260050c92cd470af at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:51:25 11: 0x1d0c - std::rt::lang_start::h0b4bcf3c5e498224 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:65:5 12: 0xffc - <unknown>!__original_main 13: 0x393 - __muloti4 at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/macros.rs:269 ``` This is relatively noisy by default but there's filenames and line numbers! Additionally frame 10 can be seen to have lots of frames inlined into it. All information is always available to the embedder but we could try to handle the `__rust_begin_short_backtrace` and `__rust_end_short_backtrace` markers to trim the backtrace by default as well. The only gotcha here is that it looks like `__muloti4` is out of place. That's because the libc that Rust ships with doesn't have dwarf information, although I'm not sure why we land in that function for symbolizing it... * Add a configuration switch for debuginfo * Control debuginfo by default with `WASM_BACKTRACE_DETAILS` * Try cpp_demangle on demangling as well * Rename to WASMTIME_BACKTRACE_DETAILS
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "eeaa953eaad386a53111e47172c2fedba671e5684c8dd601a5f474f4f118710f"
Provide filename/line number information in `Trap` (#2452) * Provide filename/line number information in `Trap` This commit extends the `Trap` type and `Store` to retain DWARF debug information found in a wasm file unconditionally, if it's present. This then enables us to print filenames and line numbers which point back to actual source code when a trap backtrace is printed. Additionally the `FrameInfo` type has been souped up to return filename/line number information as well. The implementation here is pretty simplistic currently. The meat of all the work happens in `gimli` and `addr2line`, and otherwise wasmtime is just schlepping around bytes of dwarf debuginfo here and there! The general goal here is to assist with debugging when using wasmtime because filenames and line numbers are generally orders of magnitude better even when you already have a stack trace. Another nicety here is that backtraces will display inlined frames (learned through debug information), improving the experience in release mode as well. An example of this is that with this file: ```rust fn main() { panic!("hello"); } ``` we get this stack trace: ``` $ rustc foo.rs --target wasm32-wasi -g $ cargo run foo.wasm Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `target/debug/wasmtime foo.wasm` thread 'main' panicked at 'hello', foo.rs:2:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Error: failed to run main module `foo.wasm` Caused by: 0: failed to invoke command default 1: wasm trap: unreachable wasm backtrace: 0: 0x6c1c - panic_abort::__rust_start_panic::abort::h2d60298621b1ccbf at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/panic_abort/src/lib.rs:77:17 - __rust_start_panic at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/panic_abort/src/lib.rs:32:5 1: 0x68c7 - rust_panic at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:626:9 2: 0x65a1 - std::panicking::rust_panic_with_hook::h2345fb0909b53e12 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:596:5 3: 0x1436 - std::panicking::begin_panic::{{closure}}::h106f151a6db8c8fb at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:506:9 4: 0xda8 - std::sys_common::backtrace::__rust_end_short_backtrace::he55aa13f22782798 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153:18 5: 0x1324 - std::panicking::begin_panic::h1727e7d1d719c76f at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:505:12 6: 0xfde - foo::main::h2db1313a64510850 at /Users/acrichton/code/wasmtime/foo.rs:2:5 7: 0x11d5 - core::ops::function::FnOnce::call_once::h20ee1cc04aeff1fc at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:227:5 8: 0xddf - std::sys_common::backtrace::__rust_begin_short_backtrace::h054493e41e27e69c at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:137:18 9: 0x1d5a - std::rt::lang_start::{{closure}}::hd83784448d3fcb42 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:66:18 10: 0x69d8 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h564d3dad35014917 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:259:13 - std::panicking::try::do_call::hdca4832ace5a8603 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:381:40 - std::panicking::try::ha8624a1a6854b456 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:345:19 - std::panic::catch_unwind::h71421f57cf2bc688 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panic.rs:382:14 - std::rt::lang_start_internal::h260050c92cd470af at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:51:25 11: 0x1d0c - std::rt::lang_start::h0b4bcf3c5e498224 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:65:5 12: 0xffc - <unknown>!__original_main 13: 0x393 - __muloti4 at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/macros.rs:269 ``` This is relatively noisy by default but there's filenames and line numbers! Additionally frame 10 can be seen to have lots of frames inlined into it. All information is always available to the embedder but we could try to handle the `__rust_begin_short_backtrace` and `__rust_end_short_backtrace` markers to trim the backtrace by default as well. The only gotcha here is that it looks like `__muloti4` is out of place. That's because the libc that Rust ships with doesn't have dwarf information, although I'm not sure why we land in that function for symbolizing it... * Add a configuration switch for debuginfo * Control debuginfo by default with `WASM_BACKTRACE_DETAILS` * Try cpp_demangle on demangling as well * Rename to WASMTIME_BACKTRACE_DETAILS
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Provide filename/line number information in `Trap` (#2452) * Provide filename/line number information in `Trap` This commit extends the `Trap` type and `Store` to retain DWARF debug information found in a wasm file unconditionally, if it's present. This then enables us to print filenames and line numbers which point back to actual source code when a trap backtrace is printed. Additionally the `FrameInfo` type has been souped up to return filename/line number information as well. The implementation here is pretty simplistic currently. The meat of all the work happens in `gimli` and `addr2line`, and otherwise wasmtime is just schlepping around bytes of dwarf debuginfo here and there! The general goal here is to assist with debugging when using wasmtime because filenames and line numbers are generally orders of magnitude better even when you already have a stack trace. Another nicety here is that backtraces will display inlined frames (learned through debug information), improving the experience in release mode as well. An example of this is that with this file: ```rust fn main() { panic!("hello"); } ``` we get this stack trace: ``` $ rustc foo.rs --target wasm32-wasi -g $ cargo run foo.wasm Finished dev [unoptimized + debuginfo] target(s) in 0.16s Running `target/debug/wasmtime foo.wasm` thread 'main' panicked at 'hello', foo.rs:2:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Error: failed to run main module `foo.wasm` Caused by: 0: failed to invoke command default 1: wasm trap: unreachable wasm backtrace: 0: 0x6c1c - panic_abort::__rust_start_panic::abort::h2d60298621b1ccbf at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/panic_abort/src/lib.rs:77:17 - __rust_start_panic at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/panic_abort/src/lib.rs:32:5 1: 0x68c7 - rust_panic at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:626:9 2: 0x65a1 - std::panicking::rust_panic_with_hook::h2345fb0909b53e12 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:596:5 3: 0x1436 - std::panicking::begin_panic::{{closure}}::h106f151a6db8c8fb at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:506:9 4: 0xda8 - std::sys_common::backtrace::__rust_end_short_backtrace::he55aa13f22782798 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153:18 5: 0x1324 - std::panicking::begin_panic::h1727e7d1d719c76f at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:505:12 6: 0xfde - foo::main::h2db1313a64510850 at /Users/acrichton/code/wasmtime/foo.rs:2:5 7: 0x11d5 - core::ops::function::FnOnce::call_once::h20ee1cc04aeff1fc at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:227:5 8: 0xddf - std::sys_common::backtrace::__rust_begin_short_backtrace::h054493e41e27e69c at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:137:18 9: 0x1d5a - std::rt::lang_start::{{closure}}::hd83784448d3fcb42 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:66:18 10: 0x69d8 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h564d3dad35014917 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:259:13 - std::panicking::try::do_call::hdca4832ace5a8603 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:381:40 - std::panicking::try::ha8624a1a6854b456 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:345:19 - std::panic::catch_unwind::h71421f57cf2bc688 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panic.rs:382:14 - std::rt::lang_start_internal::h260050c92cd470af at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:51:25 11: 0x1d0c - std::rt::lang_start::h0b4bcf3c5e498224 at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:65:5 12: 0xffc - <unknown>!__original_main 13: 0x393 - __muloti4 at /cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.35/src/macros.rs:269 ``` This is relatively noisy by default but there's filenames and line numbers! Additionally frame 10 can be seen to have lots of frames inlined into it. All information is always available to the embedder but we could try to handle the `__rust_begin_short_backtrace` and `__rust_end_short_backtrace` markers to trim the backtrace by default as well. The only gotcha here is that it looks like `__muloti4` is out of place. That's because the libc that Rust ships with doesn't have dwarf information, although I'm not sure why we land in that function for symbolizing it... * Add a configuration switch for debuginfo * Control debuginfo by default with `WASM_BACKTRACE_DETAILS` * Try cpp_demangle on demangling as well * Rename to WASMTIME_BACKTRACE_DETAILS
4 years ago
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
name = "cpufeatures"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.2"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "59a6001667ab124aebae2a495118e11d30984c3a653e99d86d58971708cf5e4b"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
dependencies = [
"libc",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "cranelift"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
dependencies = [
"cranelift-codegen",
"cranelift-frontend",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "cranelift-bforest"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"cranelift-entity",
]
[[package]]
name = "cranelift-codegen"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Cranelift: Use bump allocation in `remove_constant_phis` pass (#4710) * Cranelift: Use bump allocation in `remove_constant_phis` pass This makes compilation 2-6% faster for Sightglass's bz2 benchmark: ``` compilation :: cycles :: benchmarks/bz2/benchmark.wasm Δ = 7290648.36 ± 4245152.07 (confidence = 99%) bump.so is 1.02x to 1.06x faster than main.so! [166388177 183238542.98 214732518] bump.so [172836648 190529191.34 217514271] main.so compilation :: cycles :: benchmarks/pulldown-cmark/benchmark.wasm No difference in performance. [182220055 225793551.12 277857575] bump.so [193212613 227784078.61 277175335] main.so compilation :: cycles :: benchmarks/spidermonkey/benchmark.wasm No difference in performance. [3848442474 4295214144.37 4665127241] bump.so [3969505457 4262415290.10 4563869974] main.so ``` * Add audit for `bumpalo` * Add an audit of `arrayvec` version 0.7.2 * Remove unnecessary `collect` into `Vec` I wasn't able to measure any perf difference here, but its nice to do anyways. * Use a `SecondaryMap` for keeping track of summaries
2 years ago
"arrayvec",
mach backend: allow snapshotting IR graphs with the SNAPSHOT_REGALLOC env variable; This also requires the serde feature, which isn't enabled by default, thus it must be passed as a command-line argument to cargo.
4 years ago
"bincode",
Cranelift: Use bump allocation in `remove_constant_phis` pass (#4710) * Cranelift: Use bump allocation in `remove_constant_phis` pass This makes compilation 2-6% faster for Sightglass's bz2 benchmark: ``` compilation :: cycles :: benchmarks/bz2/benchmark.wasm Δ = 7290648.36 ± 4245152.07 (confidence = 99%) bump.so is 1.02x to 1.06x faster than main.so! [166388177 183238542.98 214732518] bump.so [172836648 190529191.34 217514271] main.so compilation :: cycles :: benchmarks/pulldown-cmark/benchmark.wasm No difference in performance. [182220055 225793551.12 277857575] bump.so [193212613 227784078.61 277175335] main.so compilation :: cycles :: benchmarks/spidermonkey/benchmark.wasm No difference in performance. [3848442474 4295214144.37 4665127241] bump.so [3969505457 4262415290.10 4563869974] main.so ``` * Add audit for `bumpalo` * Add an audit of `arrayvec` version 0.7.2 * Remove unnecessary `collect` into `Vec` I wasn't able to measure any perf difference here, but its nice to do anyways. * Use a `SecondaryMap` for keeping track of summaries
2 years ago
"bumpalo",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"cranelift-bforest",
"cranelift-codegen-meta",
"cranelift-codegen-shared",
"cranelift-entity",
Rename the `isle` crate to `cranelift-isle` The `isle` crate name is already taken on crates.io :(
3 years ago
"cranelift-isle",
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
"criterion",
Update `backtrace` to 0.3.61
3 years ago
"gimli",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"hashbrown",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"log",
Initial ISLE integration with the x64 backend On the build side, this commit introduces two things: 1. The automatic generation of various ISLE definitions for working with CLIF. Specifically, it generates extern type definitions for clif opcodes and the clif instruction data `enum`, as well as extractors for matching each clif instructions. This happens inside the `cranelift-codegen-meta` crate. 2. The compilation of ISLE DSL sources to Rust code, that can be included in the main `cranelift-codegen` compilation. Next, this commit introduces the integration glue code required to get ISLE-generated Rust code hooked up in clif-to-x64 lowering. When lowering a clif instruction, we first try to use the ISLE code path. If it succeeds, then we are done lowering this instruction. If it fails, then we proceed along the existing hand-written code path for lowering. Finally, this commit ports many lowering rules over from hand-written, open-coded Rust to ISLE. In the process of supporting ISLE, this commit also makes the x64 `Inst` capable of expressing SSA by supporting 3-operand forms for all of the existing instructions that only have a 2-operand form encoding: dst = src1 op src2 Rather than only the typical x86-64 2-operand form: dst = dst op src This allows `MachInst` to be in SSA form, since `dst` and `src1` are disentangled. ("3-operand" and "2-operand" are a little bit of a misnomer since not all operations are binary operations, but we do the same thing for, e.g., unary operations by disentangling the sole operand from the result.) There are two motivations for this change: 1. To allow ISLE lowering code to have value-equivalence semantics. We want ISLE lowering to translate a CLIF expression that evaluates to some value into a `MachInst` expression that evaluates to the same value. We want both the lowering itself and the resulting `MachInst` to be pure and referentially transparent. This is both a nice paradigm for compiler writers that are authoring and maintaining lowering rules and is a prerequisite to any sort of formal verification of our lowering rules in the future. 2. Better align `MachInst` with `regalloc2`'s API, which requires that the input be in SSA form.
3 years ago
"miette",
Switch Cranelift over to regalloc2. (#3989) This PR switches Cranelift over to the new register allocator, regalloc2. See [this document](https://gist.github.com/cfallin/08553421a91f150254fe878f67301801) for a summary of the design changes. This switchover has implications for core VCode/MachInst types and the lowering pass. Overall, this change brings improvements to both compile time and speed of generated code (runtime), as reported in #3942: ``` Benchmark Compilation (wallclock) Execution (wallclock) blake3-scalar 25% faster 28% faster blake3-simd no diff no diff meshoptimizer 19% faster 17% faster pulldown-cmark 17% faster no diff bz2 15% faster no diff SpiderMonkey, 21% faster 2% faster fib(30) clang.wasm 42% faster N/A ```
3 years ago
"regalloc2",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"serde",
Implement an incremental compilation cache for Cranelift (#4551) This is the implementation of https://github.com/bytecodealliance/wasmtime/issues/4155, using the "inverted API" approach suggested by @cfallin (thanks!) in Cranelift, and trait object to provide a backend for an all-included experience in Wasmtime. After the suggestion of Chris, `Function` has been split into mostly two parts: - on the one hand, `FunctionStencil` contains all the fields required during compilation, and that act as a compilation cache key: if two function stencils are the same, then the result of their compilation (`CompiledCodeBase<Stencil>`) will be the same. This makes caching trivial, as the only thing to cache is the `FunctionStencil`. - on the other hand, `FunctionParameters` contain the... function parameters that are required to finalize the result of compilation into a `CompiledCode` (aka `CompiledCodeBase<Final>`) with proper final relocations etc., by applying fixups and so on. Most changes are here to accomodate those requirements, in particular that `FunctionStencil` should be `Hash`able to be used as a key in the cache: - most source locations are now relative to a base source location in the function, and as such they're encoded as `RelSourceLoc` in the `FunctionStencil`. This required changes so that there's no need to explicitly mark a `SourceLoc` as the base source location, it's automatically detected instead the first time a non-default `SourceLoc` is set. - user-defined external names in the `FunctionStencil` (aka before this patch `ExternalName::User { namespace, index }`) are now references into an external table of `UserExternalNameRef -> UserExternalName`, present in the `FunctionParameters`, and must be explicitly declared using `Function::declare_imported_user_function`. - some refactorings have been made for function names: - `ExternalName` was used as the type for a `Function`'s name; while it thus allowed `ExternalName::Libcall` in this place, this would have been quite confusing to use it there. Instead, a new enum `UserFuncName` is introduced for this name, that's either a user-defined function name (the above `UserExternalName`) or a test case name. - The future of `ExternalName` is likely to become a full reference into the `FunctionParameters`'s mapping, instead of being "either a handle for user-defined external names, or the thing itself for other variants". I'm running out of time to do this, and this is not trivial as it implies touching ISLE which I'm less familiar with. The cache computes a sha256 hash of the `FunctionStencil`, and uses this as the cache key. No equality check (using `PartialEq`) is performed in addition to the hash being the same, as we hope that this is sufficient data to avoid collisions. A basic fuzz target has been introduced that tries to do the bare minimum: - check that a function successfully compiled and cached will be also successfully reloaded from the cache, and returns the exact same function. - check that a trivial modification in the external mapping of `UserExternalNameRef -> UserExternalName` hits the cache, and that other modifications don't hit the cache. - This last check is less efficient and less likely to happen, so probably should be rethought a bit. Thanks to both @alexcrichton and @cfallin for your very useful feedback on Zulip. Some numbers show that for a large wasm module we're using internally, this is a 20% compile-time speedup, because so many `FunctionStencil`s are the same, even within a single module. For a group of modules that have a lot of code in common, we get hit rates up to 70% when they're used together. When a single function changes in a wasm module, every other function is reloaded; that's still slower than I expect (between 10% and 50% of the overall compile time), so there's likely room for improvement. Fixes #4155.
2 years ago
"sha2",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"smallvec",
Harvest left-hand side superoptimization candidates. Given a clif function, harvest all its integer subexpressions, so that they can be fed into [Souper](https://github.com/google/souper) as candidates for superoptimization. For some of these candidates, Souper will successfully synthesize a right-hand side that is equivalent but has lower cost than the left-hand side. Then, we can combine these left- and right-hand sides into a complete optimization, and add it to our peephole passes. To harvest the expression that produced a given value `x`, we do a post-order traversal of the dataflow graph starting from `x`. As we do this traversal, we maintain a map from clif values to their translated Souper values. We stop traversing when we reach anything that can't be translated into Souper IR: a memory load, a float-to-int conversion, a block parameter, etc. For values produced by these instructions, we create a Souper `var`, which is an input variable to the optimization. For instructions that have a direct mapping into Souper IR, we get the Souper version of each of its operands and then create the Souper version of the instruction itself. It should now be clear why we do a post-order traversal: we need an instruction's translated operands in order to translate the instruction itself. Once this instruction is translated, we update the clif-to-souper map with this new translation so that any other instruction that uses this result as an operand has access to the translated value. When the traversal is complete we return the translation of `x` as the root of left-hand side candidate.
4 years ago
"souper-ir",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"target-lexicon",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "cranelift-codegen-meta"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"cranelift-codegen-shared",
]
[[package]]
name = "cranelift-codegen-shared"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Add the aegraph (acyclic e-graph) implementation crate. (#4909) * Add the aegraph (acyclic egraph) implementation crate. * fix crate-dep version for cranelift-entity (rebase error) * Review feedback. * Fix link in Markdown doc comment. * Doc link fix again. * add cranelift-egraph to publish list.
2 years ago
[[package]]
name = "cranelift-egraph"
version = "0.89.0"
dependencies = [
"cranelift-entity",
"fxhash",
"hashbrown",
"indexmap",
"log",
"smallvec",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "cranelift-entity"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"serde",
]
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "cranelift-filetests"
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
version = "0.0.0"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
dependencies = [
clif-util: Use `anyhow::Error` for errors instead of `String` Also does the same for `cranelift-filetests`.
4 years ago
"anyhow",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"cranelift-codegen",
Add ability to call CLIF functions with arbitrary arguments in filetests This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like `() -> b*` and check that the result is true under the `test run` directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results: - `run` commands look like `; run: %add(2, 2) == 4` or `; run: %add(2, 2) != 5` and verify that the executed CLIF function returns the expected value - `print` commands look like `; print: %add(2, 2)` and print the result of the function to stdout To make this work, this PR compiles a single Cranelift `Function` into a `CompiledFunction` using a `SingleFunctionCompiler`. Because we will not know the signature of the function until runtime, we use a `Trampoline` to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing with `VMTrampoline` in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compiling `Trampoline`s for the same function signatures, `Trampoline`s are cached in the `SingleFunctionCompiler`.
5 years ago
"cranelift-frontend",
Add `test interpret` support to filetests
5 years ago
"cranelift-interpreter",
cranelift: Use `cranelift-jit` in runtests (#4453) * cranelift: Use JIT in runtests Using `cranelift-jit` in run tests allows us to preform relocations and libcalls. This is important since some instruction lowerings fallback to libcall's when an extension is missing, or when it's too complicated to implement manually. This is also a first step to being able to test `call`'s between functions in the runtest suite. It should also make it easier to eventually test TLS relocations, symbol resolution and ABI's. Another benefit of this is that we also get to test the JIT more, since it now runs the runtests, and gets some fuzzing via `fuzzgen` (which uses the `SingleFunctionCompiler`). This change causes regressions in terms of runtime for the filetests. I haven't done any serious benchmarking but what I've been seeing is that it now takes about ~3 seconds to run the testsuite while it previously took around 2 seconds. * Add FMA tests for X86
2 years ago
"cranelift-jit",
"cranelift-module",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"cranelift-native",
"cranelift-preopt",
"cranelift-reader",
"file-per-thread-logger",
"filecheck",
Update `backtrace` to 0.3.61
3 years ago
"gimli",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"log",
"num_cpus",
Use `similar` to diff expected and actual output in filetests (#4282)
2 years ago
"similar",
ARM64 backend, part 10 / 11: filetest support for VCode tests. This patch adds support for filetests with the `vcode` type. This allows test cases to feed CLIF into the new backend, produce VCode output with machine instructions, and then perform matching against the pretty-printed text representation of the VCode. Tests for the new ARM64 backend using this infrastructure will come in a followup patch.
5 years ago
"target-lexicon",
Add ability to call CLIF functions with arbitrary arguments in filetests This resolves the work started in https://github.com/bytecodealliance/cranelift/pull/1231 and https://github.com/bytecodealliance/wasmtime/pull/1436. Cranelift filetests currently have the ability to run CLIF functions with a signature like `() -> b*` and check that the result is true under the `test run` directive. This PR adds the ability to call functions with arbitrary arguments and non-boolean returns and either print the result or check against a list of expected results: - `run` commands look like `; run: %add(2, 2) == 4` or `; run: %add(2, 2) != 5` and verify that the executed CLIF function returns the expected value - `print` commands look like `; print: %add(2, 2)` and print the result of the function to stdout To make this work, this PR compiles a single Cranelift `Function` into a `CompiledFunction` using a `SingleFunctionCompiler`. Because we will not know the signature of the function until runtime, we use a `Trampoline` to place the values in the appropriate location for the calling convention; this should look a lot like what @alexcrichton is doing with `VMTrampoline` in wasmtime (see https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/api/src/func.rs#L510-L526, https://github.com/bytecodealliance/wasmtime/blob/3b7cb6ee64469470fcdd68e185abca8eb2a1b20a/crates/jit/src/compiler.rs#L260). To avoid re-compiling `Trampoline`s for the same function signatures, `Trampoline`s are cached in the `SingleFunctionCompiler`.
5 years ago
"thiserror",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "cranelift-frontend"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"cranelift-codegen",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"hashbrown",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"log",
"smallvec",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"target-lexicon",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Cranelift CLIF-level differential fuzzer (#3038) * cranelift: Initial fuzzer implementation * cranelift: Generate multiple test cases in fuzzer * cranelift: Separate function generator in fuzzer * cranelift: Insert random instructions in fuzzer * cranelift: Rename gen_testcase * cranelift: Implement div for unsigned values in interpreter * cranelift: Run all test cases in fuzzer * cranelift: Comment options in function_runner * cranelift: Improve fuzzgen README.md * cranelift: Fuzzgen remove unused variable * cranelift: Fuzzer code style fixes Thanks! @bjorn3 * cranelift: Fix nits in CLIF fuzzer Thanks @cfallin! * cranelift: Implement Arbitrary for TestCase * cranelift: Remove gen_testcase * cranelift: Move fuzzers to wasmtime fuzz directory * cranelift: CLIF-Fuzzer ignore tests that produce traps * cranelift: CLIF-Fuzzer create new fuzz target to validate generated testcases * cranelift: Store clif-fuzzer config in a separate struct * cranelift: Generate variables upfront per function * cranelift: Prevent publishing of fuzzgen crate
3 years ago
[[package]]
name = "cranelift-fuzzgen"
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
version = "0.0.0"
Cranelift CLIF-level differential fuzzer (#3038) * cranelift: Initial fuzzer implementation * cranelift: Generate multiple test cases in fuzzer * cranelift: Separate function generator in fuzzer * cranelift: Insert random instructions in fuzzer * cranelift: Rename gen_testcase * cranelift: Implement div for unsigned values in interpreter * cranelift: Run all test cases in fuzzer * cranelift: Comment options in function_runner * cranelift: Improve fuzzgen README.md * cranelift: Fuzzgen remove unused variable * cranelift: Fuzzer code style fixes Thanks! @bjorn3 * cranelift: Fix nits in CLIF fuzzer Thanks @cfallin! * cranelift: Implement Arbitrary for TestCase * cranelift: Remove gen_testcase * cranelift: Move fuzzers to wasmtime fuzz directory * cranelift: CLIF-Fuzzer ignore tests that produce traps * cranelift: CLIF-Fuzzer create new fuzz target to validate generated testcases * cranelift: Store clif-fuzzer config in a separate struct * cranelift: Generate variables upfront per function * cranelift: Prevent publishing of fuzzgen crate
3 years ago
dependencies = [
"anyhow",
"arbitrary",
"cranelift",
fuzzgen: Add scalar float support (#4467) * fuzzgen: Add float support Add support for generating floats and some float instructions. * fuzzgen: Enable NaN Canonicalization Both IEEE754 and the Wasm spec are somewhat loose about what is allowed to be returned from NaN producing operations. And in practice this changes from X86 to Aarch64 and others. Even in the same host machine, the interpreter may produce a code sequence different from cranelift that generates different NaN's but produces legal results according to the spec. These differences cause spurious failures in the fuzzer. To fix this we enable the NaN Canonicalization pass that replaces any NaN's produced with a single fixed canonical NaN value. * fuzzgen: Use `MultiAry` when inserting opcodes This deduplicates a few inserters!
2 years ago
"cranelift-native",
Cranelift CLIF-level differential fuzzer (#3038) * cranelift: Initial fuzzer implementation * cranelift: Generate multiple test cases in fuzzer * cranelift: Separate function generator in fuzzer * cranelift: Insert random instructions in fuzzer * cranelift: Rename gen_testcase * cranelift: Implement div for unsigned values in interpreter * cranelift: Run all test cases in fuzzer * cranelift: Comment options in function_runner * cranelift: Improve fuzzgen README.md * cranelift: Fuzzgen remove unused variable * cranelift: Fuzzer code style fixes Thanks! @bjorn3 * cranelift: Fix nits in CLIF fuzzer Thanks @cfallin! * cranelift: Implement Arbitrary for TestCase * cranelift: Remove gen_testcase * cranelift: Move fuzzers to wasmtime fuzz directory * cranelift: CLIF-Fuzzer ignore tests that produce traps * cranelift: CLIF-Fuzzer create new fuzz target to validate generated testcases * cranelift: Store clif-fuzzer config in a separate struct * cranelift: Generate variables upfront per function * cranelift: Prevent publishing of fuzzgen crate
3 years ago
]
Add `test interpret` support to filetests
5 years ago
[[package]]
name = "cranelift-interpreter"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Add `test interpret` support to filetests
5 years ago
dependencies = [
"cranelift-codegen",
"cranelift-entity",
"cranelift-frontend",
"cranelift-reader",
cranelift: Add MinGW `fma` regression tests (#4517) * cranelift: Add MinGW `fma` regression tests * cranelift: Fix FMA in interpreter * cranelift: Add separate `fma` test suite for the interpreter The interpreter can run `fma.clif` on most platforms, however on `x86_64-pc-windows-gnu` we use libm which has issues with some inputs. We should delete `fma-interpreter.clif` and enable the interpreter on the main `fma.clif` file once those are fixed.
2 years ago
"libm",
Add `test interpret` support to filetests
5 years ago
"log",
Rewrite interpreter generically (#2323) * Rewrite interpreter generically This change re-implements the Cranelift interpreter to use generic values; this makes it possible to do abstract interpretation of Cranelift instructions. In doing so, the interpretation state is extracted from the `Interpreter` structure and is accessed via a `State` trait; this makes it possible to not only more clearly observe the interpreter's state but also to interpret using a dummy state (e.g. `ImmutableRegisterState`). This addition made it possible to implement more of the Cranelift instructions (~70%, ignoring the x86-specific instructions). * Replace macros with closures
4 years ago
"smallvec",
Add `test interpret` support to filetests
5 years ago
"thiserror",
]
Rename the `isle` crate to `cranelift-isle` The `isle` crate name is already taken on crates.io :(
3 years ago
[[package]]
name = "cranelift-isle"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Rename the `isle` crate to `cranelift-isle` The `isle` crate name is already taken on crates.io :(
3 years ago
dependencies = [
"log",
"miette",
Add an overlap checker to ISLE (#4906) https://github.com/bytecodealliance/wasmtime/pull/4906 Co-authored-by: Jamey Sharp <jsharp@fastly.com>
2 years ago
"rayon",
Implicit type conversions in ISLE (#3807) Add support for implicit type conversions to ISLE. This feature allows the DSL user to register to the compiler that a particular term (used as a constructor or extractor) converts from one type to another. The compiler will then *automatically* insert this term whenever a type mismatch involving that specific pair of types occurs. This significantly cleans up many uses of the ISLE DSL. For example, when defining the compiler backends, we often have newtypes like `Gpr` around `Reg` (signifying a particular type of register); we can define a conversion from Gpr to Reg automatically. Conversions can also have side-effects, as long as these side-effects are idempotent. For example, `put_value_in_reg` in a compiler backend has the effect of marking the value as used, causing codegen to produce it, and assigns a register to the value; but multiple invocations of this will return the same register for the same value. Thus it is safe to use it as an implicit conversion that may be invoked multiple times. This is documented in the ISLE-Cranelift integration document. This PR also adds some testing infrastructure to the ISLE compiler, checking that "pass" tests pass through the DSL compiler, "fail" tests do not, and "link" tests are able to generate code and link that code with corresponding Rust code.
3 years ago
"tempfile",
Rename the `isle` crate to `cranelift-isle` The `isle` crate name is already taken on crates.io :(
3 years ago
]
Rename SimpleJIT to JIT as it isn't simple anymore
4 years ago
[[package]]
name = "cranelift-jit"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Rename SimpleJIT to JIT as it isn't simple anymore
4 years ago
dependencies = [
"anyhow",
"cranelift",
"cranelift-codegen",
"cranelift-entity",
"cranelift-frontend",
"cranelift-module",
"cranelift-native",
"libc",
"log",
Switch from `memmap` to `memmap2`. See https://rustsec.org/advisories/RUSTSEC-2020-0077
4 years ago
"memmap2",
Rename SimpleJIT to JIT as it isn't simple anymore
4 years ago
"region",
"target-lexicon",
Migrate cranelift-jit from `winapi` to `windows-sys` (#4363) * Migrate cranelift-jit from `winapi` to `windows-sys` Following up on #4346, this migrates one more place in the tree from winapi to windows-sys.
2 years ago
"windows-sys",
Rename SimpleJIT to JIT as it isn't simple anymore
4 years ago
]
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "cranelift-module"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
dependencies = [
cranelift-faerie: upgrade to faerie 0.15.0, fix error reporting the `FaerieProduct` exposes faerie-specific types, so we can give the `faerie::ArtifactError` on those methods. `ModuleError::Backend` now expects an `anyhow::Error`, so we change a .to_string into .into() and retain better error information.
5 years ago
"anyhow",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"cranelift-codegen",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"hashbrown",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "cranelift-native"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"cranelift-codegen",
Remove the rsix dependency in cranelift-native. (#3395) Revert the part of 47490b4383bf48cbde8b1c33301a7f7d326ee7cc which changed cranelift-native to use rsix. It's just one call, and this lets Cranelift users that don't otherwise depend on rsix to avoid it.
3 years ago
"libc",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"target-lexicon",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "cranelift-object"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
dependencies = [
Bump object to 0.19.0 (#1767) * Bump object to 0.19.0
4 years ago
"anyhow",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"cranelift-codegen",
Fix usage of default_libcall_names (#2378) * Fix usage of default_libcall_names * Add basic cranelift-object test It is based on a test with the same name in cranelift-simplejit
4 years ago
"cranelift-entity",
"cranelift-frontend",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"cranelift-module",
Move a bit more logic out of Module
4 years ago
"log",
Update `object` to 0.26.0
3 years ago
"object",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"target-lexicon",
]
[[package]]
name = "cranelift-preopt"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
dependencies = [
"cranelift-codegen",
]
Merge cranelift/wasmtime fuzzing
5 years ago
[[package]]
name = "cranelift-reader"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Merge cranelift/wasmtime fuzzing
5 years ago
dependencies = [
"cranelift-codegen",
cranelift/reader/src/parser.rs: fn parse_inst_resuts: produce the results as a SmallVec<[Value; 1]>, not as a Vec<Value>. This isn't a useful change for any non-developer use of Cranelift, but it does significantly reduce the amount of allocation "noise" seen when tuning the new backend pipeline as driven by clif-util reading .clif files. In one case the number of malloc calls declined by about 20% with this change.
5 years ago
"smallvec",
Merge cranelift/wasmtime fuzzing
5 years ago
"target-lexicon",
]
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "cranelift-serde"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
dependencies = [
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"clap 3.2.8",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"cranelift-codegen",
"cranelift-reader",
"serde_json",
]
[[package]]
name = "cranelift-tools"
Bump versions: Wasmtime to 0.26.0, Cranelift to 0.73.0.
4 years ago
version = "0.73.0"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
dependencies = [
clif-util: Use `anyhow::Error` for errors instead of `String` Also does the same for `cranelift-filetests`.
4 years ago
"anyhow",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"capstone",
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"clap 3.2.8",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"cranelift",
"cranelift-codegen",
"cranelift-entity",
"cranelift-filetests",
"cranelift-frontend",
Add an `interpret` command to clif-util
5 years ago
"cranelift-interpreter",
Rename SimpleJIT to JIT as it isn't simple anymore
4 years ago
"cranelift-jit",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"cranelift-module",
"cranelift-native",
"cranelift-object",
"cranelift-preopt",
"cranelift-reader",
"cranelift-wasm",
"filecheck",
"indicatif",
Add an `interpret` command to clif-util
5 years ago
"log",
bump witx dep to 0.8.5
5 years ago
"pretty_env_logger",
Harvest left-hand side superoptimization candidates. Given a clif function, harvest all its integer subexpressions, so that they can be fed into [Souper](https://github.com/google/souper) as candidates for superoptimization. For some of these candidates, Souper will successfully synthesize a right-hand side that is equivalent but has lower cost than the left-hand side. Then, we can combine these left- and right-hand sides into a complete optimization, and add it to our peephole passes. To harvest the expression that produced a given value `x`, we do a post-order traversal of the dataflow graph starting from `x`. As we do this traversal, we maintain a map from clif values to their translated Souper values. We stop traversing when we reach anything that can't be translated into Souper IR: a memory load, a float-to-int conversion, a block parameter, etc. For values produced by these instructions, we create a Souper `var`, which is an input variable to the optimization. For instructions that have a direct mapping into Souper IR, we get the Souper version of each of its operands and then create the Souper version of the instruction itself. It should now be clear why we do a post-order traversal: we need an instruction's translated operands in order to translate the instruction itself. Once this instruction is translated, we update the clif-to-souper map with this new translation so that any other instruction that uses this result as an operand has access to the translated value. When the traversal is complete we return the translation of `x` as the root of left-hand side candidate.
4 years ago
"rayon",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"target-lexicon",
Switch from `term` to `termcolor`. See https://rustsec.org/advisories/RUSTSEC-2018-0015
4 years ago
"termcolor",
Add an `interpret` command to clif-util
5 years ago
"thiserror",
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
"walkdir",
"wat",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "cranelift-wasm"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "0.89.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"cranelift-codegen",
"cranelift-entity",
"cranelift-frontend",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"hashbrown",
Update criterion to remove duplicate itertools dep (#3579) Helps remove a crate in `deny.toml`
3 years ago
"itertools",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"log",
"serde",
wasm->CLIF translation: consistently bitcast V128 values that are block formal parameters. In the current translation of wasm (128-bit) SIMD into CLIF, we work around differences in the type system models of wasm vs CLIF by inserting `bitcast` (a no-op cast) CLIF instructions before more or less every use of a SIMD value. Unfortunately this was not being done consistently and even small examples with a single if-then-else diamond that produces a SIMD value, could cause a verification failure downstream. In this case, the jump out of the "else" block needed a bitcast, but didn't have one. This patch wraps creation of CLIF jumps and conditional branches up into three functions, `canonicalise_then_jump` and `canonicalise_then_br{z,nz}`, and uses them consistently. They first cast the relevant block formal parameters, then generate the relevant kind of branch/jump. Hence, provided they are also used consistently in future to generate branches/jumps in this file, we are protected against such failures. The patch also adds a large(ish) comment at the top explaining this in more detail.
4 years ago
"smallvec",
Hook up all crates via path dependencies
5 years ago
"target-lexicon",
upgrade all wasmparser to 0.71 new simd instructions are left as ubsupported in cranelift-wasm
4 years ago
"wasmparser",
Remove `wasmtime-environ`'s dependency on `cranelift-codegen` (#3199) * Move `CompiledFunction` into wasmtime-cranelift This commit moves the `wasmtime_environ::CompiledFunction` type into the `wasmtime-cranelift` crate. This type has lots of Cranelift-specific pieces of compilation and doesn't need to be generated by all Wasmtime compilers. This replaces the usage in the `Compiler` trait with a `Box<Any>` type that each compiler can select. Each compiler must still produce a `FunctionInfo`, however, which is shared information we'll deserialize for each module. The `wasmtime-debug` crate is also folded into the `wasmtime-cranelift` crate as a result of this commit. One possibility was to move the `CompiledFunction` commit into its own crate and have `wasmtime-debug` depend on that, but since `wasmtime-debug` is Cranelift-specific at this time it didn't seem like it was too too necessary to keep it separate. If `wasmtime-debug` supports other backends in the future we can recreate a new crate, perhaps with it refactored to not depend on Cranelift. * Move wasmtime_environ::reference_type This now belongs in wasmtime-cranelift and nowhere else * Remove `Type` reexport in wasmtime-environ One less dependency on `cranelift-codegen`! * Remove `types` reexport from `wasmtime-environ` Less cranelift! * Remove `SourceLoc` from wasmtime-environ Change the `srcloc`, `start_srcloc`, and `end_srcloc` fields to a custom `FilePos` type instead of `ir::SourceLoc`. These are only used in a few places so there's not much to lose from an extra abstraction for these leaf use cases outside of cranelift. * Remove wasmtime-environ's dep on cranelift's `StackMap` This commit "clones" the `StackMap` data structure in to `wasmtime-environ` to have an independent representation that that chosen by Cranelift. This allows Wasmtime to decouple this runtime dependency of stack map information and let the two evolve independently, if necessary. An alternative would be to refactor cranelift's implementation into a separate crate and have wasmtime depend on that but it seemed a bit like overkill to do so and easier to clone just a few lines for this. * Define code offsets in wasmtime-environ with `u32` Don't use Cranelift's `binemit::CodeOffset` alias to define this field type since the `wasmtime-environ` crate will be losing the `cranelift-codegen` dependency soon. * Commit to using `cranelift-entity` in Wasmtime This commit removes the reexport of `cranelift-entity` from the `wasmtime-environ` crate and instead directly depends on the `cranelift-entity` crate in all referencing crates. The original reason for the reexport was to make cranelift version bumps easier since it's less versions to change, but nowadays we have a script to do that. Otherwise this encourages crates to use whatever they want from `cranelift-entity` since we'll always depend on the whole crate. It's expected that the `cranelift-entity` crate will continue to be a lean crate in dependencies and suitable for use at both runtime and compile time. Consequently there's no need to avoid its usage in Wasmtime at runtime, since "remove Cranelift at compile time" is primarily about the `cranelift-codegen` crate. * Remove most uses of `cranelift-codegen` in `wasmtime-environ` There's only one final use remaining, which is the reexport of `TrapCode`, which will get handled later. * Limit the glob-reexport of `cranelift_wasm` This commit removes the glob reexport of `cranelift-wasm` from the `wasmtime-environ` crate. This is intended to explicitly define what we're reexporting and is a transitionary step to curtail the amount of dependencies taken on `cranelift-wasm` throughout the codebase. For example some functions used by debuginfo mapping are better imported directly from the crate since they're Cranelift-specific. Note that this is intended to be a temporary state affairs, soon this reexport will be gone entirely. Additionally this commit reduces imports from `cranelift_wasm` and also primarily imports from `crate::wasm` within `wasmtime-environ` to get a better sense of what's imported from where and what will need to be shared. * Extract types from cranelift-wasm to cranelift-wasm-types This commit creates a new crate called `cranelift-wasm-types` and extracts type definitions from the `cranelift-wasm` crate into this new crate. The purpose of this crate is to be a shared definition of wasm types that can be shared both by compilers (like Cranelift) as well as wasm runtimes (e.g. Wasmtime). This new `cranelift-wasm-types` crate doesn't depend on `cranelift-codegen` and is the final step in severing the unconditional dependency from Wasmtime to `cranelift-codegen`. The final refactoring in this commit is to then reexport this crate from `wasmtime-environ`, delete the `cranelift-codegen` dependency, and then update all `use` paths to point to these new types. The main change of substance here is that the `TrapCode` enum is mirrored from Cranelift into this `cranelift-wasm-types` crate. While this unfortunately results in three definitions (one more which is non-exhaustive in Wasmtime itself) it's hopefully not too onerous and ideally something we can patch up in the future. * Get lightbeam compiling * Remove unnecessary dependency * Fix compile with uffd * Update publish script * Fix more uffd tests * Rename cranelift-wasm-types to wasmtime-types This reflects the purpose a bit more where it's types specifically intended for Wasmtime and its support. * Fix publish script
3 years ago
"wasmtime-types",
Hook up all crates via path dependencies
5 years ago
"wat",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Adds perf jitdump support (#360) Patch adds support for the perf jitdump file specification. With this patch it should be possible to see profile data for code generated and maped at runtime. Specifically the patch adds support for the JIT_CODE_LOAD and the JIT_DEBUG_INFO record as described in the specification. Dumping jitfiles is enabled with the --jitdump flag. When the -g flag is also used there is an attempt to dump file and line number information where this option would be most useful when the WASM file already includes DWARF debug information. The generation of the jitdump files has been tested on only a few wasm files. This patch is expected to be useful/serviceable where currently there is no means for jit profiling, but future patches may benefit line mapping and add support for additional jitdump record types. Usage Example: Record sudo perf record -k 1 -e instructions:u target/debug/wasmtime -g --jitdump test.wasm Combine sudo perf inject -v -j -i perf.data -o perf.jit.data Report sudo perf report -i perf.jit.data -F+period,srcline
5 years ago
[[package]]
name = "crc32fast"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.3.2"
Adds perf jitdump support (#360) Patch adds support for the perf jitdump file specification. With this patch it should be possible to see profile data for code generated and maped at runtime. Specifically the patch adds support for the JIT_CODE_LOAD and the JIT_DEBUG_INFO record as described in the specification. Dumping jitfiles is enabled with the --jitdump flag. When the -g flag is also used there is an attempt to dump file and line number information where this option would be most useful when the WASM file already includes DWARF debug information. The generation of the jitdump files has been tested on only a few wasm files. This patch is expected to be useful/serviceable where currently there is no means for jit profiling, but future patches may benefit line mapping and add support for additional jitdump record types. Usage Example: Record sudo perf record -k 1 -e instructions:u target/debug/wasmtime -g --jitdump test.wasm Combine sudo perf inject -v -j -i perf.data -o perf.jit.data Report sudo perf report -i perf.jit.data -F+period,srcline
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "b540bd8bc810d3885c6ea91e2018302f68baba2129ab3e88f32389ee9370880d"
Adds perf jitdump support (#360) Patch adds support for the perf jitdump file specification. With this patch it should be possible to see profile data for code generated and maped at runtime. Specifically the patch adds support for the JIT_CODE_LOAD and the JIT_DEBUG_INFO record as described in the specification. Dumping jitfiles is enabled with the --jitdump flag. When the -g flag is also used there is an attempt to dump file and line number information where this option would be most useful when the WASM file already includes DWARF debug information. The generation of the jitdump files has been tested on only a few wasm files. This patch is expected to be useful/serviceable where currently there is no means for jit profiling, but future patches may benefit line mapping and add support for additional jitdump record types. Usage Example: Record sudo perf record -k 1 -e instructions:u target/debug/wasmtime -g --jitdump test.wasm Combine sudo perf inject -v -j -i perf.data -o perf.jit.data Report sudo perf report -i perf.jit.data -F+period,srcline
5 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "criterion"
Drop a few crates from our dependency graph (#5009) A minor update of a few other crates drops `semver` and `rustc_version` from `Cargo.lock`. I've audited the deltas in versions for the other crates here as well and they all look good.
2 years ago
version = "0.3.6"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Drop a few crates from our dependency graph (#5009) A minor update of a few other crates drops `semver` and `rustc_version` from `Cargo.lock`. I've audited the deltas in versions for the other crates here as well and they all look good.
2 years ago
checksum = "b01d6de93b2b6c65e17c634a26653a29d107b3c98c607c765bf38d041531cd8f"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"atty",
"cast",
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
"clap 2.34.0",
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
"criterion-plot",
"csv",
Update criterion to remove duplicate itertools dep (#3579) Helps remove a crate in `deny.toml`
3 years ago
"itertools",
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
"lazy_static",
"num-traits",
"oorandom",
"plotters",
"rayon",
"regex",
"serde",
"serde_cbor",
"serde_derive",
"serde_json",
"tinytemplate",
"walkdir",
]
[[package]]
name = "criterion-plot"
Drop a few crates from our dependency graph (#5009) A minor update of a few other crates drops `semver` and `rustc_version` from `Cargo.lock`. I've audited the deltas in versions for the other crates here as well and they all look good.
2 years ago
version = "0.4.5"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Drop a few crates from our dependency graph (#5009) A minor update of a few other crates drops `semver` and `rustc_version` from `Cargo.lock`. I've audited the deltas in versions for the other crates here as well and they all look good.
2 years ago
checksum = "2673cc8207403546f45f5fd319a974b1e6983ad1a3ee7e6041650013be041876"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"cast",
Update criterion to remove duplicate itertools dep (#3579) Helps remove a crate in `deny.toml`
3 years ago
"itertools",
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
]
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
[[package]]
name = "crossbeam-channel"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.5.4"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "5aaa7bd5fb665c6864b5f963dd9097905c54125909c7aa94c9e18507cdbe6c53"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
cargo update
4 years ago
"crossbeam-utils",
Adds perf jitdump support (#360) Patch adds support for the perf jitdump file specification. With this patch it should be possible to see profile data for code generated and maped at runtime. Specifically the patch adds support for the JIT_CODE_LOAD and the JIT_DEBUG_INFO record as described in the specification. Dumping jitfiles is enabled with the --jitdump flag. When the -g flag is also used there is an attempt to dump file and line number information where this option would be most useful when the WASM file already includes DWARF debug information. The generation of the jitdump files has been tested on only a few wasm files. This patch is expected to be useful/serviceable where currently there is no means for jit profiling, but future patches may benefit line mapping and add support for additional jitdump record types. Usage Example: Record sudo perf record -k 1 -e instructions:u target/debug/wasmtime -g --jitdump test.wasm Combine sudo perf inject -v -j -i perf.data -o perf.jit.data Report sudo perf report -i perf.jit.data -F+period,srcline
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "crossbeam-deque"
Update crossbeam-deque to appease cargo-deny (#3227) Hopefully unblocks some CI
3 years ago
version = "0.8.1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update crossbeam-deque to appease cargo-deny (#3227) Hopefully unblocks some CI
3 years ago
checksum = "6455c0ca19f0d2fbf751b908d5c55c1f5cbc65e03c4225427254b46890bdde1e"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"crossbeam-epoch",
cargo update
4 years ago
"crossbeam-utils",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "crossbeam-epoch"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
version = "0.9.9"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
checksum = "07db9d94cbd326813772c968ccd25999e5f8ae22f4f8d1b11effa37ef6ce281d"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"autocfg 1.1.0",
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
cargo update
4 years ago
"crossbeam-utils",
"memoffset",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"once_cell",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"scopeguard",
]
[[package]]
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
name = "crossbeam-utils"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
version = "0.8.10"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
checksum = "7d82ee10ce34d7bc12c2122495e7593a9c41347ecdd64185af4ecf72cb1a7f83"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"once_cell",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
[[package]]
name = "crypto-bigint"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.2.11"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "f83bd3bb4314701c568e340cd8cf78c975aa0ca79e03d3f6d1677d5b0c9c0c03"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
dependencies = [
"generic-array",
"rand_core 0.6.3",
"subtle",
"zeroize",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "crypto-mac"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.11.1"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "b1d1a86f49236c215f271d40892d5fc950490551400b02ef360692c29815c714"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"generic-array",
"subtle",
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "csv"
version = "1.1.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "22813a6dc45b335f9bade10bf7271dc477e81113e89eb251a0bc2a8a81c536e1"
dependencies = [
"bstr",
"csv-core",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"itoa 0.4.8",
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
"ryu",
"serde",
]
[[package]]
name = "csv-core"
version = "0.1.10"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2b2466559f260f48ad25fe6317b3c8dac77b5bdb5763ac7d9d6103530663bc90"
dependencies = [
"memchr",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "ctr"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.8.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "049bb91fb4aaf0e3c7efa6cd5ef877dbbbd15b39dad06d9948de4ec8a75761ea"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"cipher",
]
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
[[package]]
name = "cty"
version = "0.2.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b365fabc795046672053e29c954733ec3b05e4be654ab130fe8f1f94d7051f35"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "curve25519-dalek"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "3.2.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "0b9fdf9972b2bd6af2d913799d9ebc165ea4d2e65878e329d9c6b372c4491b61"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"byteorder",
"digest",
"rand_core 0.5.1",
"subtle",
"zeroize",
]
[[package]]
name = "der"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.4.5"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "79b71cca7d95d7681a4b3b9cdf63c8dbc3730d0584c2c74e31416d64a90493f4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"const-oid",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"crypto-bigint",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
]
[[package]]
name = "derivative"
Merge remote-tracking branch 'origin/main' into pch/wasi_common_cap_std
4 years ago
version = "2.2.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Merge remote-tracking branch 'origin/main' into pch/wasi_common_cap_std
4 years ago
checksum = "fcc3dd5e9e9c0b295d6e1e4d811fb6f157d5ffd784b8d202fc62eac8035a770b"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"proc-macro2",
"quote",
"syn",
]
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
[[package]]
name = "derive_arbitrary"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.1.0"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "98e23c06c035dac87bd802d98f368df73a7f2cb05a66ffbd1f377e821fac4af9"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
dependencies = [
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"proc-macro2",
Update deps and tests for `anyref` --> `externref` * Update to using `wasmparser` 0.55.0 * Update wasmprinter to 0.2.5 * Update `wat` to 1.0.18, and `wast` to 17.0.0
5 years ago
"quote",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"syn",
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "digest"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
version = "0.9.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
checksum = "d3dd60d1080a57a05ab032377049e0591415d2b31afd7028356dbf3cc6dcb066"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"generic-array",
]
[[package]]
Replace unmaintained directories crate Fixes RUSTSEC-2020-0054 warning from cargo-audit/cargo-deny, follows the recommendation to switch to the new maintained `directories-next` crate fork Only affects the cache directory determination for the environment and was a simple search'n'replace to this fork so don't think behavior has changed. https://rustsec.org/advisories/RUSTSEC-2020-0054
4 years ago
name = "directories-next"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
version = "2.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
checksum = "339ee130d97a610ea5a5872d2bbb130fdf68884ff09d3028b81bec8a1ac23bbc"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Replace unmaintained directories crate Fixes RUSTSEC-2020-0054 warning from cargo-audit/cargo-deny, follows the recommendation to switch to the new maintained `directories-next` crate fork Only affects the cache directory determination for the environment and was a simple search'n'replace to this fork so don't think behavior has changed. https://rustsec.org/advisories/RUSTSEC-2020-0054
4 years ago
"dirs-sys-next",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Upgrade shellexpand dep (#2529) The previous version depended on the deprecated `dirs` crate.
4 years ago
[[package]]
name = "dirs-next"
version = "2.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b98cf8ebf19c3d1b223e151f99a4f9f0690dca41414773390fc824184ac833e1"
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Upgrade shellexpand dep (#2529) The previous version depended on the deprecated `dirs` crate.
4 years ago
"dirs-sys-next",
]
Replace unmaintained directories crate Fixes RUSTSEC-2020-0054 warning from cargo-audit/cargo-deny, follows the recommendation to switch to the new maintained `directories-next` crate fork Only affects the cache directory determination for the environment and was a simple search'n'replace to this fork so don't think behavior has changed. https://rustsec.org/advisories/RUSTSEC-2020-0054
4 years ago
[[package]]
name = "dirs-sys-next"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
version = "0.1.2"
Replace unmaintained directories crate Fixes RUSTSEC-2020-0054 warning from cargo-audit/cargo-deny, follows the recommendation to switch to the new maintained `directories-next` crate fork Only affects the cache directory determination for the environment and was a simple search'n'replace to this fork so don't think behavior has changed. https://rustsec.org/advisories/RUSTSEC-2020-0054
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
checksum = "4ebda144c4fe02d1f7ea1a7d9641b6fc6b580adcfa024ae48797ecdeb6825b4d"
Replace unmaintained directories crate Fixes RUSTSEC-2020-0054 warning from cargo-audit/cargo-deny, follows the recommendation to switch to the new maintained `directories-next` crate fork Only affects the cache directory determination for the environment and was a simple search'n'replace to this fork so don't think behavior has changed. https://rustsec.org/advisories/RUSTSEC-2020-0054
4 years ago
dependencies = [
"libc",
Switch from `term` to `termcolor`. See https://rustsec.org/advisories/RUSTSEC-2018-0015
4 years ago
"redox_users",
Replace unmaintained directories crate Fixes RUSTSEC-2020-0054 warning from cargo-audit/cargo-deny, follows the recommendation to switch to the new maintained `directories-next` crate fork Only affects the cache directory determination for the environment and was a simple search'n'replace to this fork so don't think behavior has changed. https://rustsec.org/advisories/RUSTSEC-2020-0054
4 years ago
"winapi",
]
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
[[package]]
name = "downcast-rs"
version = "1.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9ea835d29036a4087793836fa931b08837ad5e957da9e23886b29586fb9b6650"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
[[package]]
name = "dunce"
version = "1.0.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "453440c271cf5577fd2a40e4942540cb7d0d2f85e27c8d07dd0023c925a67541"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "ecdsa"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.12.4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "43ee23aa5b4f68c7a092b5c3beb25f50c406adc75e2363634f242f28ab255372"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"der",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"elliptic-curve",
"hmac",
"signature",
]
[[package]]
name = "ed25519"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "1.4.1"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "3d5c4b5e5959dc2c2b89918d8e2cc40fcdd623cef026ed09d2f0ee05199dc8e4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"signature",
]
[[package]]
name = "ed25519-dalek"
version = "1.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c762bae6dcaf24c4c84667b8579785430908723d5c889f469d76a41d59cc7a9d"
dependencies = [
"curve25519-dalek",
"ed25519",
"rand 0.7.3",
"serde",
"sha2",
"zeroize",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
[[package]]
name = "egg"
version = "0.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "05a6c0bbc92278f84e742f08c0ab9cb16a987376cd2bc39d228ef9c74d98d6f7"
dependencies = [
"indexmap",
"instant",
"log",
"once_cell",
"smallvec",
"symbolic_expressions",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "either"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
version = "1.6.1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
checksum = "e78d4f1cc4ae33bbfc157ed5d5a5ef3bc29227303d595861deb238fcec4e9457"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "elliptic-curve"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.10.6"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "beca177dcb8eb540133e7680baff45e7cc4d93bf22002676cec549f82343721b"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"crypto-bigint",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"ff",
"generic-array",
"group",
"pkcs8",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"rand_core 0.6.3",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"subtle",
"zeroize",
]
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "encode_unicode"
version = "0.3.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a357d28ed41a50f9c765dbfe56cbc04a64e53e5fc58ba79fbc34c10ef3df831f"
Implement strings in adapter modules (#4623) * Implement strings in adapter modules This commit is a hefty addition to Wasmtime's support for the component model. This implements the final remaining type (in the current type hierarchy) unimplemented in adapter module trampolines: strings. Strings are the most complicated type to implement in adapter trampolines because they are highly structured chunks of data in memory (according to specific encodings). Additionally each lift/lower operation can choose its own encoding for strings meaning that Wasmtime, the host, may have to convert between any pairwise ordering of string encodings. The `CanonicalABI.md` in the component-model repo in general specifies all the fiddly bits of string encoding so there's not a ton of wiggle room for Wasmtime to get creative. This PR largely "just" implements that. The high-level architecture of this implementation is: * Fused adapters are first identified to determine src/dst string encodings. This statically fixes what transcoding operation is being performed. * The generated adapter will be responsible for managing calls to `realloc` and performing bounds checks. The adapter itself does not perform memory copies or validation of string contents, however. Instead each transcoding operation is modeled as an imported function into the adapter module. This means that the adapter module dynamically, during compile time, determines what string transcoders are needed. Note that an imported transcoder is not only parameterized over the transcoding operation but additionally which memory is the source and which is the destination. * The imported core wasm functions are modeled as a new `CoreDef::Transcoder` structure. These transcoders end up being small Cranelift-compiled trampolines. The Cranelift-compiled trampoline will load the actual base pointer of memory and add it to the relative pointers passed as function arguments. This trampoline then calls a transcoder "libcall" which enters Rust-defined functions for actual transcoding operations. * Each possible transcoding operation is implemented in Rust with a unique name and a unique signature depending on the needs of the transcoder. I've tried to document inline what each transcoder does. This means that the `Module::translate_string` in adapter modules is by far the largest translation method. The main reason for this is due to the management around calling the imported transcoder functions in the face of validating string pointer/lengths and performing the dance of `realloc`-vs-transcode at the right time. I've tried to ensure that each individual case in transcoding is documented well enough to understand what's going on as well. Additionally in this PR is a full implementation in the host for the `latin1+utf16` encoding which means that both lifting and lowering host strings now works with this encoding. Currently the implementation of each transcoder function is likely far from optimal. Where possible I've leaned on the standard library itself and for latin1-related things I'm leaning on the `encoding_rs` crate. I initially tried to implement everything with `encoding_rs` but was unable to uniformly do so easily. For now I settled on trying to get a known-correct (even in the face of endianness) implementation for all of these transcoders. If an when performance becomes an issue it should be possible to implement more optimized versions of each of these transcoding operations. Testing this commit has been somewhat difficult and my general plan, like with the `(list T)` type, is to rely heavily on fuzzing to cover the various cases here. In this PR though I've added a simple test that pushes some statically known strings through all the pairs of encodings between source and destination. I've attempted to pick "interesting" strings that one way or another stress the various paths in each transcoding operation to ideally get full branch coverage there. Additionally a suite of "negative" tests have also been added to ensure that validity of encoding is actually checked. * Fix a temporarily commented out case * Fix wasmtime-runtime tests * Update deny.toml configuration * Add `BSD-3-Clause` for the `encoding_rs` crate * Remove some unused licenses * Add an exemption for `encoding_rs` for now * Split up the `translate_string` method Move out all the closures and package up captured state into smaller lists of arguments. * Test out-of-bounds for zero-length strings
2 years ago
[[package]]
name = "encoding_rs"
version = "0.8.31"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9852635589dc9f9ea1b6fe9f05b50ef208c85c834a562f0c6abb1c475736ec2b"
dependencies = [
"cfg-if",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "env_logger"
version = "0.7.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "44533bbbb3bb3c1fa17d9f2e4e38bbbaf8396ba82193c4cb1b6445d711445d36"
dependencies = [
"atty",
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
"humantime 1.3.0",
"log",
"regex",
"termcolor",
]
Make ISLE part of the root Cargo workspace.
3 years ago
[[package]]
name = "env_logger"
version = "0.9.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0b2cf0344971ee6c64c31be0d530793fba457d322dfec2810c453d0ef228f9c3"
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"atty",
"humantime 2.1.0",
Make ISLE part of the root Cargo workspace.
3 years ago
"log",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"regex",
"termcolor",
Make ISLE part of the root Cargo workspace.
3 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "errno"
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
version = "0.2.8"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
checksum = "f639046355ee4f37944e44f60642c6f3a7efa3cf6b78c78a0d989a8ce6c396a1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"errno-dragonfly",
"libc",
"winapi",
]
[[package]]
name = "errno-dragonfly"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "aa68f1b12764fab894d2755d2518754e71b4fd80ecfb822714a1206c2aab39bf"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"cc",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"libc",
]
Move all examples to a top-level directory (#1286) * Move all examples to a top-level directory This commit moves all API examples (Rust and C) to a top-level `examples` directory. This is intended to make it more discoverable and conventional as to where examples are located. Additionally all examples are now available in both Rust and C to see how to execute the example in the language you're familiar with. The intention is that as more languages are supported we'd add more languages as examples here too. Each example is also accompanied by either a `*.wat` file which is parsed as input, or a Rust project in a `wasm` folder which is compiled as input. A simple driver crate was also added to `crates/misc` which executes all the examples on CI, ensuring the C and Rust examples all execute successfully.
5 years ago
[[package]]
name = "example-fib-debug-wasm"
Wasmtime 0.13.0 and Cranelift 0.61.0. (#1398) This also updates the publishing scripts to work with newly added and reorganized crates.
5 years ago
version = "0.0.0"
Move all examples to a top-level directory (#1286) * Move all examples to a top-level directory This commit moves all API examples (Rust and C) to a top-level `examples` directory. This is intended to make it more discoverable and conventional as to where examples are located. Additionally all examples are now available in both Rust and C to see how to execute the example in the language you're familiar with. The intention is that as more languages are supported we'd add more languages as examples here too. Each example is also accompanied by either a `*.wat` file which is parsed as input, or a Rust project in a `wasm` folder which is compiled as input. A simple driver crate was also added to `crates/misc` which executes all the examples on CI, ensuring the C and Rust examples all execute successfully.
5 years ago
add tokio example Co-authored-by: Alex Crichton <alex@alexcrichton.com>
4 years ago
[[package]]
name = "example-tokio-wasm"
version = "0.0.0"
Add examples of linking and WASI (#1369) * Add examples of linking and WASI This commit adds two example programs, one for linking two modules together and one for instantiating WASI. The linkage example additionally uses WASI to get some meaningful output at this time. cc #1272 * Add examples to the book as well * More links! * Ignore examples from rustdoc testsing * More example updates * More ignored
5 years ago
[[package]]
name = "example-wasi-wasm"
Wasmtime 0.13.0 and Cranelift 0.61.0. (#1398) This also updates the publishing scripts to work with newly added and reorganized crates.
5 years ago
version = "0.0.0"
Add examples of linking and WASI (#1369) * Add examples of linking and WASI This commit adds two example programs, one for linking two modules together and one for instantiating WASI. The linkage example additionally uses WASI to get some meaningful output at this time. cc #1272 * Add examples to the book as well * More links! * Ignore examples from rustdoc testsing * More example updates * More ignored
5 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "fallible-iterator"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4443176a9f2c162692bd3d352d745ef9413eec5782a80d8fd6f8a1ac692a07f7"
Fuzz using precompiled modules on CI (#3788) In working on #3787 I see now that our coverage of loading precompiled files specifically is somewhat lacking, so this adds a config option to the fuzzers where, if enabled, will round-trip all compiled modules through the filesystem to test out the mmapped-file case.
3 years ago
[[package]]
name = "fastrand"
version = "1.7.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c3fcf0cee53519c866c09b5de1f6c56ff9d647101f81c1964fa632e148896cdf"
dependencies = [
"instant",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "ff"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.10.1"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "d0f40b2dcd8bc322217a5f6559ae5f9e9d1de202a2ecee2e9eafcbece7562a4f"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"rand_core 0.6.3",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"subtle",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "file-per-thread-logger"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.5"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "21e16290574b39ee41c71aeb90ae960c504ebaf1e2a1c87bd52aa56ed6e1a02f"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"env_logger 0.9.0",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"log",
]
Test basic DWARF generation (#931) * Add obj generation with debug info * Add simple transform check
5 years ago
[[package]]
name = "filecheck"
Update the `filecheck` dependency (#1348) Removes an edge towards the `synstructure` dependency in our dependency graph which, if removed entirely, is hoped to reduce build times locally and on CI as you switch between `cargo build` and `cargo test` because deep dependencies like `syn` won't have their features alternating back and forth.
5 years ago
version = "0.5.0"
Test basic DWARF generation (#931) * Add obj generation with debug info * Add simple transform check
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the `filecheck` dependency (#1348) Removes an edge towards the `synstructure` dependency in our dependency graph which, if removed entirely, is hoped to reduce build times locally and on CI as you switch between `cargo build` and `cargo test` because deep dependencies like `syn` won't have their features alternating back and forth.
5 years ago
checksum = "2fe00b427b7c4835f8b82170eb7b9a63634376b63d73b9a9093367e82570bbaa"
Test basic DWARF generation (#931) * Add obj generation with debug info * Add simple transform check
5 years ago
dependencies = [
"regex",
Update the `filecheck` dependency (#1348) Removes an edge towards the `synstructure` dependency in our dependency graph which, if removed entirely, is hoped to reduce build times locally and on CI as you switch between `cargo build` and `cargo test` because deep dependencies like `syn` won't have their features alternating back and forth.
5 years ago
"thiserror",
Test basic DWARF generation (#931) * Add obj generation with debug info * Add simple transform check
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "filetime"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.16"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "c0408e2626025178a6a7f7ffc05a25bc47103229f19c113755de7bf63816290c"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"libc",
Update version for fs-set-times to 3.1
4 years ago
"redox_syscall",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"winapi",
]
Update wasm-{smith,encoder} (#3835) Ended up being a routine update but seemed good to go ahead and hook up updates. While I was at it I went ahead and hooked up multi-value swarm fuzzing as well now that wasm-smith implements it.
3 years ago
[[package]]
name = "flagset"
version = "0.4.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "cda653ca797810c02f7ca4b804b40b8b95ae046eb989d356bce17919a8c25499"
Fix wiggle's tests
5 years ago
[[package]]
name = "fnv"
externref: Address review feedback
4 years ago
version = "1.0.7"
Fix wiggle's tests
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
externref: Address review feedback
4 years ago
checksum = "3f9eec918d3f24069decb9af1554cad7c880e2da24a9afd88aca000531ab82c1"
Fix wiggle's tests
5 years ago
impl WasiFile for cap_std::fs::File
4 years ago
[[package]]
name = "fs-set-times"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
version = "0.17.0"
impl WasiFile for cap_std::fs::File
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
checksum = "344a9d25719061ed11379a5ff2f7222486df7d7211f3c228a1d78fa387706576"
impl WasiFile for cap_std::fs::File
4 years ago
dependencies = [
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"io-lifetimes",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
impl WasiFile for cap_std::fs::File
4 years ago
]
Add differential fuzzing against V8 (#3264) * Add differential fuzzing against V8 This commit adds a differential fuzzing target to Wasmtime along the lines of the wasmi and spec interpreters we already have, but with V8 instead. The intention here is that wasmi is unlikely to receive updates over time (e.g. for SIMD), and the spec interpreter is not suitable for fuzzing against in general due to its performance characteristics. The hope is that V8 is indeed appropriate to fuzz against because it's naturally receiving updates and it also is expected to have good performance. Here the `rusty_v8` crate is used which provides bindings to V8 as well as precompiled binaries by default. This matches exactly the use case we need and at least for now I think the `rusty_v8` crate will be maintained by the Deno folks as they continue to develop it. If it becomes an issue though maintaining we can evaluate other options to have differential fuzzing against. For now this commit enables the SIMD and bulk-memory feature of fuzz-target-generation which should enable them to get differentially-fuzzed with V8 in addition to the compilation fuzzing we're already getting. * Use weak linkage for GDB jit helpers This should help us deduplicate our symbol with other JIT runtimes, if any. For now this leans on some C helpers to define the weak linkage since Rust doesn't support that on stable yet. * Don't use rusty_v8 on MinGW They don't have precompiled libraries there. * Fix msvc build * Comment about execution
3 years ago
[[package]]
name = "fslock"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.8"
Add differential fuzzing against V8 (#3264) * Add differential fuzzing against V8 This commit adds a differential fuzzing target to Wasmtime along the lines of the wasmi and spec interpreters we already have, but with V8 instead. The intention here is that wasmi is unlikely to receive updates over time (e.g. for SIMD), and the spec interpreter is not suitable for fuzzing against in general due to its performance characteristics. The hope is that V8 is indeed appropriate to fuzz against because it's naturally receiving updates and it also is expected to have good performance. Here the `rusty_v8` crate is used which provides bindings to V8 as well as precompiled binaries by default. This matches exactly the use case we need and at least for now I think the `rusty_v8` crate will be maintained by the Deno folks as they continue to develop it. If it becomes an issue though maintaining we can evaluate other options to have differential fuzzing against. For now this commit enables the SIMD and bulk-memory feature of fuzz-target-generation which should enable them to get differentially-fuzzed with V8 in addition to the compilation fuzzing we're already getting. * Use weak linkage for GDB jit helpers This should help us deduplicate our symbol with other JIT runtimes, if any. For now this leans on some C helpers to define the weak linkage since Rust doesn't support that on stable yet. * Don't use rusty_v8 on MinGW They don't have precompiled libraries there. * Fix msvc build * Comment about execution
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "57eafdd0c16f57161105ae1b98a1238f97645f2f588438b2949c99a2af9616bf"
Add differential fuzzing against V8 (#3264) * Add differential fuzzing against V8 This commit adds a differential fuzzing target to Wasmtime along the lines of the wasmi and spec interpreters we already have, but with V8 instead. The intention here is that wasmi is unlikely to receive updates over time (e.g. for SIMD), and the spec interpreter is not suitable for fuzzing against in general due to its performance characteristics. The hope is that V8 is indeed appropriate to fuzz against because it's naturally receiving updates and it also is expected to have good performance. Here the `rusty_v8` crate is used which provides bindings to V8 as well as precompiled binaries by default. This matches exactly the use case we need and at least for now I think the `rusty_v8` crate will be maintained by the Deno folks as they continue to develop it. If it becomes an issue though maintaining we can evaluate other options to have differential fuzzing against. For now this commit enables the SIMD and bulk-memory feature of fuzz-target-generation which should enable them to get differentially-fuzzed with V8 in addition to the compilation fuzzing we're already getting. * Use weak linkage for GDB jit helpers This should help us deduplicate our symbol with other JIT runtimes, if any. For now this leans on some C helpers to define the weak linkage since Rust doesn't support that on stable yet. * Don't use rusty_v8 on MinGW They don't have precompiled libraries there. * Fix msvc build * Comment about execution
3 years ago
dependencies = [
"libc",
"winapi",
]
Switch Cranelift over to regalloc2. (#3989) This PR switches Cranelift over to the new register allocator, regalloc2. See [this document](https://gist.github.com/cfallin/08553421a91f150254fe878f67301801) for a summary of the design changes. This switchover has implications for core VCode/MachInst types and the lowering pass. Overall, this change brings improvements to both compile time and speed of generated code (runtime), as reported in #3942: ``` Benchmark Compilation (wallclock) Execution (wallclock) blake3-scalar 25% faster 28% faster blake3-simd no diff no diff meshoptimizer 19% faster 17% faster pulldown-cmark 17% faster no diff bz2 15% faster no diff SpiderMonkey, 21% faster 2% faster fib(30) clang.wasm 42% faster N/A ```
3 years ago
[[package]]
name = "fxhash"
version = "0.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c31b6d751ae2c7f11320402d34e41349dd1016f8d5d45e48c4312bc8625af50c"
dependencies = [
"byteorder",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "generic-array"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.14.5"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "fd48d33ec7f05fbfa152300fdad764757cbded343c1aa1cff2fbaf4134851803"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"typenum",
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
"version_check",
]
[[package]]
name = "getrandom"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
version = "0.1.16"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
checksum = "8fc3cb4d91f53b50155bdcfd23f6a4c39ae1969c2ae85982b135750cccaf5fce"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
"libc",
"wasi 0.9.0+wasi-snapshot-preview1",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "getrandom"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.6"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "9be70c98951c83b8d2f8f60d7065fa6d5146873094452a1008da8c2f1e4205ad"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"libc",
Merge remote-tracking branch 'origin/main' into pch/wasi_common_cap_std
4 years ago
"wasi 0.10.2+wasi-snapshot-preview1",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
]
[[package]]
name = "ghash"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.4.4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "1583cc1656d7839fd3732b80cf4f38850336cdb9b8ded1cd399ca62958de3c99"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"opaque-debug",
"polyval",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Update `gimli` to 0.25; `addr2line` to 0.16
3 years ago
[[package]]
name = "gimli"
Update addr2line and gimli deps (#3580) Just a routine update, figured it was good to stay close to their most recent versions
3 years ago
version = "0.26.1"
Update `gimli` to 0.25; `addr2line` to 0.16
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update addr2line and gimli deps (#3580) Just a routine update, figured it was good to stay close to their most recent versions
3 years ago
checksum = "78cc372d058dcf6d5ecd98510e7fbc9e5aec4d21de70f65fea8fecebcd881bd4"
Update to cranelift 0.58.0 and enable (but ignore) reference types and bulk memory tests (#926) * Update cranelift to 0.58.0 * Update `wasmprinter` dep to require 0.2.1 We already had it in the lock file, but this ensures we won't ever go back down. * Ensure that our error messages match `assert_invalid`'s The bulk of this work was done in https://github.com/bytecodealliance/wasmparser/pull/186 but now we can test it at the `wasmtime` level as well. Fixes #492 * Stop feeling guilty about not matching `assert_malformed` messages Remove the "TODO" and stop printing warning messages. These would just be busy work to implement, and getting all the messages the exact same relies on using the same structure as the spec interpreter's parser, which means that where you have a helper function and they don't, then things go wrong, and vice versa. Not worth it. Fixes #492 * Enable (but ignore) the reference-types proposal tests * Match test suite directly, instead of roundabout starts/endswith * Enable (but ignore) bulk memory operations proposal test suite
5 years ago
dependencies = [
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"fallible-iterator",
Update to cranelift 0.58.0 and enable (but ignore) reference types and bulk memory tests (#926) * Update cranelift to 0.58.0 * Update `wasmprinter` dep to require 0.2.1 We already had it in the lock file, but this ensures we won't ever go back down. * Ensure that our error messages match `assert_invalid`'s The bulk of this work was done in https://github.com/bytecodealliance/wasmparser/pull/186 but now we can test it at the `wasmtime` level as well. Fixes #492 * Stop feeling guilty about not matching `assert_malformed` messages Remove the "TODO" and stop printing warning messages. These would just be busy work to implement, and getting all the messages the exact same relies on using the same structure as the spec interpreter's parser, which means that where you have a helper function and they don't, then things go wrong, and vice versa. Not worth it. Fixes #492 * Enable (but ignore) the reference-types proposal tests * Match test suite directly, instead of roundabout starts/endswith * Enable (but ignore) bulk memory operations proposal test suite
5 years ago
"indexmap",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"stable_deref_trait",
Update to cranelift 0.58.0 and enable (but ignore) reference types and bulk memory tests (#926) * Update cranelift to 0.58.0 * Update `wasmprinter` dep to require 0.2.1 We already had it in the lock file, but this ensures we won't ever go back down. * Ensure that our error messages match `assert_invalid`'s The bulk of this work was done in https://github.com/bytecodealliance/wasmparser/pull/186 but now we can test it at the `wasmtime` level as well. Fixes #492 * Stop feeling guilty about not matching `assert_malformed` messages Remove the "TODO" and stop printing warning messages. These would just be busy work to implement, and getting all the messages the exact same relies on using the same structure as the spec interpreter's parser, which means that where you have a helper function and they don't, then things go wrong, and vice versa. Not worth it. Fixes #492 * Enable (but ignore) the reference-types proposal tests * Match test suite directly, instead of roundabout starts/endswith * Enable (but ignore) bulk memory operations proposal test suite
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "glob"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9b919933a397b79c37e33b77bb2aa3dc8eb6e165ad809e58ff75bc7db2e34574"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "group"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.10.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "1c363a5301b8f153d80747126a04b3c82073b9fe3130571a9d170cacdeaf7912"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"ff",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"rand_core 0.6.3",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"subtle",
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "half"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.8.2"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "eabb4a44450da02c90444cf74558da904edde8fb4e9035a9a6a4e15445af0bd7"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
Hook up all crates via path dependencies
5 years ago
[[package]]
name = "hashbrown"
Add the aegraph (acyclic e-graph) implementation crate. (#4909) * Add the aegraph (acyclic egraph) implementation crate. * fix crate-dep version for cranelift-entity (rebase error) * Review feedback. * Fix link in Markdown doc comment. * Doc link fix again. * add cranelift-egraph to publish list.
2 years ago
version = "0.12.3"
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Add the aegraph (acyclic e-graph) implementation crate. (#4909) * Add the aegraph (acyclic egraph) implementation crate. * fix crate-dep version for cranelift-entity (rebase error) * Review feedback. * Fix link in Markdown doc comment. * Doc link fix again. * add cranelift-egraph to publish list.
2 years ago
checksum = "8a9ee70c43aaf417c914396645a0fa852624801b24ebb7ae78fe8272889ac888"
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
dependencies = [
Update the hashbrown to use the same version (#2338) Signed-off-by: koushiro <koushiro.cqx@gmail.com>
4 years ago
"ahash",
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "heck"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
version = "0.4.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
checksum = "2540771e65fc8cb83cd6e8a237f70c319bd5c29f78ed1084ba5d50eeac86f7f9"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "hermit-abi"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.19"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "62b467343b94ba476dcb2500d242dadbb39557df889310ac77c5d99100aaac33"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"libc",
]
Use is-terminal instead of atty. Following up on #3696, use the new is-terminal crate to test for a tty rather than having platform-specific logic in Wasmtime. The is-terminal crate has a platform-independent API which takes a handle. This also updates the tree to cap-std 0.24 etc., to avoid depending on multiple versions of io-lifetimes at once, as enforced by the cargo deny check.
3 years ago
[[package]]
name = "hermit-abi"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1ab7905ea95c6d9af62940f9d7dd9596d54c334ae2c15300c482051292d5637f"
dependencies = [
"libc",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "hkdf"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.11.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "01706d578d5c281058480e673ae4086a9f4710d8df1ad80a5b03e39ece5f886b"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"digest",
"hmac",
]
[[package]]
name = "hmac"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.11.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "2a2a2320eb7ec0ebe8da8f744d7812d9fc4cb4d09344ac01898dbcb6a20ae69b"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"crypto-mac",
"digest",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "humantime"
version = "1.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "df004cfca50ef23c36850aaaa59ad52cc70d0e90243c3c7737a4dd32dc7a3c4f"
dependencies = [
Bump dependencies to get a single version of rand (#2733) This removes a few crates in the dependencies, and a few exceptions (at the price of a new one) in the cargo-deny configuration.
4 years ago
"quick-error 1.2.3",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
[[package]]
name = "humantime"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
version = "2.1.0"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
checksum = "9a3a5bfb195931eeb336b2a7b4d761daec841b97f947d34394601737a7bba5e4"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
Convert Souper optimizations into Peepmatic DSL Conversion from Souper into Peepmatic is implemented with a straightforward, top-down recursive traversal of the optimization's left- and right-hand side expression DAGs. Most Souper instructions have a corresponding Peepmatic instruction. If we run into an instruction where that isn't the case, we skip that Souper optimization and move on to the next one. Note that Souper fully supports DAGs, for example: ```text %0 = var %1 = add 1, %0 %2 = add %1, %1 ;; Two edges to `%1` makes this a DAG. ``` On the other hand, Peepmatic only currently supports trees, so shared subexpressions are duplicated: ```text (iadd (iadd 1 $x) (iadd 1 $x)) ;; The shared subexpression is duplicated. ``` This does not affect correctness.
4 years ago
[[package]]
name = "id-arena"
version = "2.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "25a2bc672d1148e28034f176e01fffebb08b35768468cc954630da77a1449005"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "indexmap"
Update some dependency versions used by Wasmtime (#4405) No major motivation here, mostly just dependency gardening.
2 years ago
version = "1.9.1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependency versions used by Wasmtime (#4405) No major motivation here, mostly just dependency gardening.
2 years ago
checksum = "10a35a97730320ffe8e2d410b5d3b69279b98d2c14bdb8b70ea89ecf7888d41e"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"autocfg 1.1.0",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"hashbrown",
Make wasmtime_environ::Module serializable (#2005) * Define WasmType/WasmFuncType in the Cranelift * Make `Module` serializable
4 years ago
"serde",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "indicatif"
version = "0.13.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8572bccfb0665e70b7faf44ee28841b8e0823450cd4ad562a76b5a3c4bf48487"
dependencies = [
"console",
"lazy_static",
"number_prefix",
"regex",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "instant"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.12"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "7a5bbe824c507c5da5956355e86a746d82e0e1464f65d862cc5e71da70e94b2c"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
]
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
[[package]]
name = "io-extras"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
version = "0.15.0"
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
checksum = "4a5d8c2ab5becd8720e30fd25f8fa5500d8dc3fceadd8378f05859bd7b46fc49"
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
dependencies = [
"io-lifetimes",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
]
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
[[package]]
name = "io-lifetimes"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
version = "0.7.2"
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
checksum = "24c3f4eff5495aee4c0399d7b6a0dc2b6e81be84242ffbfcf253ebacccc1d0cb"
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
dependencies = [
Use is-terminal instead of atty. Following up on #3696, use the new is-terminal crate to test for a tty rather than having platform-specific logic in Wasmtime. The is-terminal crate has a platform-independent API which takes a handle. This also updates the tree to cap-std 0.24 etc., to avoid depending on multiple versions of io-lifetimes at once, as enforced by the cargo deny check.
3 years ago
"libc",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
]
impl WasiFile for cap_std::fs::File
4 years ago
[[package]]
name = "ipnet"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "2.5.0"
impl WasiFile for cap_std::fs::File
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "879d54834c8c76457ef4293a689b2a8c59b076067ad77b15efafbb05f92a592b"
impl WasiFile for cap_std::fs::File
4 years ago
Use is-terminal instead of atty. Following up on #3696, use the new is-terminal crate to test for a tty rather than having platform-specific logic in Wasmtime. The is-terminal crate has a platform-independent API which takes a handle. This also updates the tree to cap-std 0.24 etc., to avoid depending on multiple versions of io-lifetimes at once, as enforced by the cargo deny check.
3 years ago
[[package]]
name = "is-terminal"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
version = "0.3.0"
Use is-terminal instead of atty. Following up on #3696, use the new is-terminal crate to test for a tty rather than having platform-specific logic in Wasmtime. The is-terminal crate has a platform-independent API which takes a handle. This also updates the tree to cap-std 0.24 etc., to avoid depending on multiple versions of io-lifetimes at once, as enforced by the cargo deny check.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
checksum = "0d508111813f9af3afd2f92758f77e4ed2cc9371b642112c6a48d22eb73105c5"
Use is-terminal instead of atty. Following up on #3696, use the new is-terminal crate to test for a tty rather than having platform-specific logic in Wasmtime. The is-terminal crate has a platform-independent API which takes a handle. This also updates the tree to cap-std 0.24 etc., to avoid depending on multiple versions of io-lifetimes at once, as enforced by the cargo deny check.
3 years ago
dependencies = [
"hermit-abi 0.2.0",
"io-lifetimes",
"rustix",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
Use is-terminal instead of atty. Following up on #3696, use the new is-terminal crate to test for a tty rather than having platform-specific logic in Wasmtime. The is-terminal crate has a platform-independent API which takes a handle. This also updates the tree to cap-std 0.24 etc., to avoid depending on multiple versions of io-lifetimes at once, as enforced by the cargo deny check.
3 years ago
]
Make ISLE part of the root Cargo workspace.
3 years ago
[[package]]
name = "is_ci"
version = "1.1.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "616cde7c720bb2bb5824a224687d8f77bfd38922027f01d825cd7453be5099fb"
[[package]]
name = "isle-fuzz"
version = "0.0.0"
dependencies = [
Rename the `isle` crate to `cranelift-isle` The `isle` crate name is already taken on crates.io :(
3 years ago
"cranelift-isle",
Make ISLE part of the root Cargo workspace.
3 years ago
"env_logger 0.9.0",
"libfuzzer-sys",
"log",
]
[[package]]
name = "islec"
version = "0.1.0"
dependencies = [
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"clap 3.2.8",
Rename the `isle` crate to `cranelift-isle` The `isle` crate name is already taken on crates.io :(
3 years ago
"cranelift-isle",
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
"env_logger 0.9.0",
Make ISLE part of the root Cargo workspace.
3 years ago
"miette",
]
Update a number of dependencies (#2594) This commit goes through the dependencies that wasmtime has and updates versions where possible. This notably brings in a wasmparser/wast update which has some simd spec changes with new instructions. Otherwise most of these are just routine updates.
4 years ago
[[package]]
name = "itertools"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.10.3"
Update a number of dependencies (#2594) This commit goes through the dependencies that wasmtime has and updates versions where possible. This notably brings in a wasmparser/wast update which has some simd spec changes with new instructions. Otherwise most of these are just routine updates.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "a9a9d19fa1e79b6215ff29b9d6880b706147f16e9b1dbb1e4e5947b5b02bc5e3"
Update a number of dependencies (#2594) This commit goes through the dependencies that wasmtime has and updates versions where possible. This notably brings in a wasmparser/wast update which has some simd spec changes with new instructions. Otherwise most of these are just routine updates.
4 years ago
dependencies = [
"either",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "itoa"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.4.8"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "b71991ff56294aa922b450139ee08b3bfc70982c6b2c7562771375cf73542dd4"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Update to cap-std 0.22.0. (#3611) * Update to cap-std 0.22.0. The main change relevant to Wasmtime here is that this includes the rustix fix for compilation errors on Rust nightly with the `asm!` macro. * Add itoa to deny.toml. * Update the doc and fuzz builds to the latest Rust nightly. * Update to libc 0.2.112 to pick up the `POLLRDHUP` fix. * Update to cargo-fuzz 0.11, for compatibility with Rust nightly. This appears to be the fix for rust-fuzz/cargo-fuzz#277.
3 years ago
[[package]]
name = "itoa"
version = "1.0.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "1aab8fc367588b89dcee83ab0fd66b72b50b72fa1904d7095045ace2b0c81c35"
Adds JIT profiling support for VTune (#819) This patch adds initial support for ittapi which is an open source profiling api for instrumentation and tracing and profiling of jitted code. Result files can be read by VTune for analysis Build: cargo build --features=vtune Profile: // Using amplxe-cl from VTune amplxe-cl -v -collect hostpost target/debug/wasmtime --vtune test.wasm
5 years ago
[[package]]
Upgrade to the high-level `ittapi` v0.3.0 crate (#4003) * Upgrade to the high-level ittapi v0.3.0 crate * Add exclusion for windows mingw
2 years ago
name = "ittapi"
version = "0.3.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "663fe0550070071ff59e981864a9cd3ee1c869ed0a088140d9ac4dc05ea6b1a1"
dependencies = [
"anyhow",
"ittapi-sys",
"log",
]
[[package]]
name = "ittapi-sys"
version = "0.3.1"
Adds JIT profiling support for VTune (#819) This patch adds initial support for ittapi which is an open source profiling api for instrumentation and tracing and profiling of jitted code. Result files can be read by VTune for analysis Build: cargo build --features=vtune Profile: // Using amplxe-cl from VTune amplxe-cl -v -collect hostpost target/debug/wasmtime --vtune test.wasm
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Upgrade to the high-level `ittapi` v0.3.0 crate (#4003) * Upgrade to the high-level ittapi v0.3.0 crate * Add exclusion for windows mingw
2 years ago
checksum = "e21911b7183f38c71d75ab478a527f314e28db51027037ece2e5511ed9410703"
Adds JIT profiling support for VTune (#819) This patch adds initial support for ittapi which is an open source profiling api for instrumentation and tracing and profiling of jitted code. Result files can be read by VTune for analysis Build: cargo build --features=vtune Profile: // Using amplxe-cl from VTune amplxe-cl -v -collect hostpost target/debug/wasmtime --vtune test.wasm
5 years ago
dependencies = [
x64: upgrade ittapi-rs crate (for VTune support) (#3623) This update is no real change in functionality but brings in several of the latest changes to the `ittapi-rs` library: minor fixes to the C library, a new license expression for the Cargo crate, better documentation, updated Rust bindings, and the removal of `cmake` as a dependency (uses `cc` directly instead).
3 years ago
"cc",
Adds JIT profiling support for VTune (#819) This patch adds initial support for ittapi which is an open source profiling api for instrumentation and tracing and profiling of jitted code. Result files can be read by VTune for analysis Build: cargo build --features=vtune Profile: // Using amplxe-cl from VTune amplxe-cl -v -collect hostpost target/debug/wasmtime --vtune test.wasm
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "jobserver"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.24"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "af25a77299a7f711a01975c35a6a424eb6862092cc2d6c72c4ed6cbc56dfc1fa"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"libc",
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "js-sys"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.3.57"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "671a26f820db17c2a2750743f1dd03bafd15b98c9f30c7c2628c024c05d73397"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"wasm-bindgen",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "k256"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.9.6"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "903ae2481bcdfdb7b68e0a9baa4b7c9aff600b9ae2e8e5bb5833b8c91ab851ea"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"ecdsa",
"elliptic-curve",
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
"sha2",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "lazy_static"
version = "1.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e2abad23fbc42b3700f2f279844dc832adb2b2eb069b2df918f455c4e18cc646"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"spin",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "leb128"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.2.5"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "884e2677b40cc8c339eaefcb701c32ef1fd2493d71118dc0ca4b6a736c93bd67"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "libc"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
version = "0.2.133"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
checksum = "c0f80d65747a3e43d1596c7c5492d95d5edddaabd45a7fcdb02b95f644164966"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
[[package]]
name = "libfuzzer-sys"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.4.3"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "336244aaeab6a12df46480dc585802aa743a72d66b11937844c61bbca84c991d"
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
dependencies = [
Update to arbitrary@0.4.0 and libfuzzer-sys@0.3.1
5 years ago
"arbitrary",
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
"cc",
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
"once_cell",
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
]
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
[[package]]
name = "libloading"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.7.3"
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "efbc0f03f9a775e9f6aed295c6a1ba2253c5757a9e03d55c6caa46a681abcddd"
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
"winapi",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "libm"
cranelift: Upgrade libm to 0.2.4 (#4670) * cranelift: Upgrade libm to 0.2.4 This resolves an issue with incorrect fmaf on the x86_64-pc-windows-gnu target under some inputs. See: #4517 * supply-chain: Vet `libm` 0.2.4
2 years ago
version = "0.2.4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
cranelift: Upgrade libm to 0.2.4 (#4670) * cranelift: Upgrade libm to 0.2.4 This resolves an issue with incorrect fmaf on the x86_64-pc-windows-gnu target under some inputs. See: #4517 * supply-chain: Vet `libm` 0.2.4
2 years ago
checksum = "c7ce35d4899fa3c0558d4f5082c98927789a01024270711cf113999b66ced65a"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
[[package]]
name = "linux-raw-sys"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
version = "0.0.46"
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
checksum = "d4d2456c373231a208ad294c33dc5bff30051eafd954cd4caae83a712b12854d"
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
wasmtime: add CLI options for pre-opened TCP listen sockets (#3729) This patch implements CLI options to insert pre-opened sockets. `--listenfd` : Inherit environment variables and file descriptors following the systemd listen fd specification (UNIX only). `--tcplisten <SOCKET ADDRESS>`: Grant access to the given TCP listen socket. Signed-off-by: Harald Hoyer <harald@profian.com>
3 years ago
[[package]]
name = "listenfd"
Upgrade listenfd to v1.0.0 (#4197) Previously, `listenfd` depended on an old version of the `uuid` crate which caused cargo deny failures. https://github.com/mitsuhiko/listenfd/pull/13 upgrades the `uuid` dependency and a new version of `listenfd` is published. This change moves to the latest version of `listenfd`.
2 years ago
version = "1.0.0"
wasmtime: add CLI options for pre-opened TCP listen sockets (#3729) This patch implements CLI options to insert pre-opened sockets. `--listenfd` : Inherit environment variables and file descriptors following the systemd listen fd specification (UNIX only). `--tcplisten <SOCKET ADDRESS>`: Grant access to the given TCP listen socket. Signed-off-by: Harald Hoyer <harald@profian.com>
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Upgrade listenfd to v1.0.0 (#4197) Previously, `listenfd` depended on an old version of the `uuid` crate which caused cargo deny failures. https://github.com/mitsuhiko/listenfd/pull/13 upgrades the `uuid` dependency and a new version of `listenfd` is published. This change moves to the latest version of `listenfd`.
2 years ago
checksum = "14e4fcc00ff6731d94b70e16e71f43bda62883461f31230742e3bc6dddf12988"
wasmtime: add CLI options for pre-opened TCP listen sockets (#3729) This patch implements CLI options to insert pre-opened sockets. `--listenfd` : Inherit environment variables and file descriptors following the systemd listen fd specification (UNIX only). `--tcplisten <SOCKET ADDRESS>`: Grant access to the given TCP listen socket. Signed-off-by: Harald Hoyer <harald@profian.com>
3 years ago
dependencies = [
"libc",
Upgrade listenfd to v1.0.0 (#4197) Previously, `listenfd` depended on an old version of the `uuid` crate which caused cargo deny failures. https://github.com/mitsuhiko/listenfd/pull/13 upgrades the `uuid` dependency and a new version of `listenfd` is published. This change moves to the latest version of `listenfd`.
2 years ago
"uuid",
wasmtime: add CLI options for pre-opened TCP listen sockets (#3729) This patch implements CLI options to insert pre-opened sockets. `--listenfd` : Inherit environment variables and file descriptors following the systemd listen fd specification (UNIX only). `--tcplisten <SOCKET ADDRESS>`: Grant access to the given TCP listen socket. Signed-off-by: Harald Hoyer <harald@profian.com>
3 years ago
"winapi",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
name = "lock_api"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.4.7"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "327fa5b6a6940e4699ec49a9beae1ea4845c6bab9314e4f84ac68742139d8c53"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
dependencies = [
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"autocfg 1.1.0",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"scopeguard",
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
]
[[package]]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
name = "log"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "0.4.17"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "abb12e687cfb44aa40f41fc3978ef76448f9b6038cad6aef4259d3c095a2382e"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "mach"
externref: Address review feedback
4 years ago
version = "0.3.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
externref: Address review feedback
4 years ago
checksum = "b823e83b2affd8f40a9ee8c29dbc56404c1e34cd2710921f2801e2cf29527afa"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"libc",
]
stdio compiles on windows!
4 years ago
[[package]]
name = "maybe-owned"
version = "0.3.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4facc753ae494aeb6e3c22f839b158aebd4f9270f55cd3c79906c45476c47ab4"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "memchr"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "2.5.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "2dffe52ecf27772e601905b7522cb4ef790d2cc203488bbd0e2fe85fcb74566d"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Add a pooling allocator mode based on copy-on-write mappings of memfds. As first suggested by Jan on the Zulip here [1], a cheap and effective way to obtain copy-on-write semantics of a "backing image" for a Wasm memory is to mmap a file with `MAP_PRIVATE`. The `memfd` mechanism provided by the Linux kernel allows us to create anonymous, in-memory-only files that we can use for this mapping, so we can construct the image contents on-the-fly then effectively create a CoW overlay. Furthermore, and importantly, `madvise(MADV_DONTNEED, ...)` will discard the CoW overlay, returning the mapping to its original state. By itself this is almost enough for a very fast instantiation-termination loop of the same image over and over, without changing the address space mapping at all (which is expensive). The only missing bit is how to implement heap *growth*. But here memfds can help us again: if we create another anonymous file and map it where the extended parts of the heap would go, we can take advantage of the fact that a `mmap()` mapping can be *larger than the file itself*, with accesses beyond the end generating a `SIGBUS`, and the fact that we can cheaply resize the file with `ftruncate`, even after a mapping exists. So we can map the "heap extension" file once with the maximum memory-slot size and grow the memfd itself as `memory.grow` operations occur. The above CoW technique and heap-growth technique together allow us a fastpath of `madvise()` and `ftruncate()` only when we re-instantiate the same module over and over, as long as we can reuse the same slot. This fastpath avoids all whole-process address-space locks in the Linux kernel, which should mean it is highly scalable. It also avoids the cost of copying data on read, as the `uffd` heap backend does when servicing pagefaults; the kernel's own optimized CoW logic (same as used by all file mmaps) is used instead. [1] https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/Copy.20on.20write.20based.20instance.20reuse/near/266657772
3 years ago
[[package]]
name = "memfd"
Do one `add_seals` call, rather than one per flag. (#4366) When setting up a copy on write image, we add several seals, to prevent the image from being resized or modified. Set all the seals in a single call, rather than doing one call per seal.
2 years ago
version = "0.6.1"
Add a pooling allocator mode based on copy-on-write mappings of memfds. As first suggested by Jan on the Zulip here [1], a cheap and effective way to obtain copy-on-write semantics of a "backing image" for a Wasm memory is to mmap a file with `MAP_PRIVATE`. The `memfd` mechanism provided by the Linux kernel allows us to create anonymous, in-memory-only files that we can use for this mapping, so we can construct the image contents on-the-fly then effectively create a CoW overlay. Furthermore, and importantly, `madvise(MADV_DONTNEED, ...)` will discard the CoW overlay, returning the mapping to its original state. By itself this is almost enough for a very fast instantiation-termination loop of the same image over and over, without changing the address space mapping at all (which is expensive). The only missing bit is how to implement heap *growth*. But here memfds can help us again: if we create another anonymous file and map it where the extended parts of the heap would go, we can take advantage of the fact that a `mmap()` mapping can be *larger than the file itself*, with accesses beyond the end generating a `SIGBUS`, and the fact that we can cheaply resize the file with `ftruncate`, even after a mapping exists. So we can map the "heap extension" file once with the maximum memory-slot size and grow the memfd itself as `memory.grow` operations occur. The above CoW technique and heap-growth technique together allow us a fastpath of `madvise()` and `ftruncate()` only when we re-instantiate the same module over and over, as long as we can reuse the same slot. This fastpath avoids all whole-process address-space locks in the Linux kernel, which should mean it is highly scalable. It also avoids the cost of copying data on read, as the `uffd` heap backend does when servicing pagefaults; the kernel's own optimized CoW logic (same as used by all file mmaps) is used instead. [1] https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/Copy.20on.20write.20based.20instance.20reuse/near/266657772
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Do one `add_seals` call, rather than one per flag. (#4366) When setting up a copy on write image, we add several seals, to prevent the image from being resized or modified. Set all the seals in a single call, rather than doing one call per seal.
2 years ago
checksum = "480b5a5de855d11ff13195950bdc8b98b5e942ef47afc447f6615cdcc4e15d80"
Add a pooling allocator mode based on copy-on-write mappings of memfds. As first suggested by Jan on the Zulip here [1], a cheap and effective way to obtain copy-on-write semantics of a "backing image" for a Wasm memory is to mmap a file with `MAP_PRIVATE`. The `memfd` mechanism provided by the Linux kernel allows us to create anonymous, in-memory-only files that we can use for this mapping, so we can construct the image contents on-the-fly then effectively create a CoW overlay. Furthermore, and importantly, `madvise(MADV_DONTNEED, ...)` will discard the CoW overlay, returning the mapping to its original state. By itself this is almost enough for a very fast instantiation-termination loop of the same image over and over, without changing the address space mapping at all (which is expensive). The only missing bit is how to implement heap *growth*. But here memfds can help us again: if we create another anonymous file and map it where the extended parts of the heap would go, we can take advantage of the fact that a `mmap()` mapping can be *larger than the file itself*, with accesses beyond the end generating a `SIGBUS`, and the fact that we can cheaply resize the file with `ftruncate`, even after a mapping exists. So we can map the "heap extension" file once with the maximum memory-slot size and grow the memfd itself as `memory.grow` operations occur. The above CoW technique and heap-growth technique together allow us a fastpath of `madvise()` and `ftruncate()` only when we re-instantiate the same module over and over, as long as we can reuse the same slot. This fastpath avoids all whole-process address-space locks in the Linux kernel, which should mean it is highly scalable. It also avoids the cost of copying data on read, as the `uffd` heap backend does when servicing pagefaults; the kernel's own optimized CoW logic (same as used by all file mmaps) is used instead. [1] https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/Copy.20on.20write.20based.20instance.20reuse/near/266657772
3 years ago
dependencies = [
Do one `add_seals` call, rather than one per flag. (#4366) When setting up a copy on write image, we add several seals, to prevent the image from being resized or modified. Set all the seals in a single call, rather than doing one call per seal.
2 years ago
"rustix",
Add a pooling allocator mode based on copy-on-write mappings of memfds. As first suggested by Jan on the Zulip here [1], a cheap and effective way to obtain copy-on-write semantics of a "backing image" for a Wasm memory is to mmap a file with `MAP_PRIVATE`. The `memfd` mechanism provided by the Linux kernel allows us to create anonymous, in-memory-only files that we can use for this mapping, so we can construct the image contents on-the-fly then effectively create a CoW overlay. Furthermore, and importantly, `madvise(MADV_DONTNEED, ...)` will discard the CoW overlay, returning the mapping to its original state. By itself this is almost enough for a very fast instantiation-termination loop of the same image over and over, without changing the address space mapping at all (which is expensive). The only missing bit is how to implement heap *growth*. But here memfds can help us again: if we create another anonymous file and map it where the extended parts of the heap would go, we can take advantage of the fact that a `mmap()` mapping can be *larger than the file itself*, with accesses beyond the end generating a `SIGBUS`, and the fact that we can cheaply resize the file with `ftruncate`, even after a mapping exists. So we can map the "heap extension" file once with the maximum memory-slot size and grow the memfd itself as `memory.grow` operations occur. The above CoW technique and heap-growth technique together allow us a fastpath of `madvise()` and `ftruncate()` only when we re-instantiate the same module over and over, as long as we can reuse the same slot. This fastpath avoids all whole-process address-space locks in the Linux kernel, which should mean it is highly scalable. It also avoids the cost of copying data on read, as the `uffd` heap backend does when servicing pagefaults; the kernel's own optimized CoW logic (same as used by all file mmaps) is used instead. [1] https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/Copy.20on.20write.20based.20instance.20reuse/near/266657772
3 years ago
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "memmap2"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "0.2.3"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "723e3ebdcdc5c023db1df315364573789f8857c11b631a2fdfad7c00f5c046b4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"libc",
]
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
[[package]]
name = "memoffset"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.6.5"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "5aa361d4faea93603064a027415f07bd8e1d5c88c9fbf68bf56a285428fd79ce"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"autocfg 1.1.0",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
[[package]]
name = "memory_units"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "71d96e3f3c0b6325d8ccd83c33b28acb183edcb6c67938ba104ec546854b0882"
Make ISLE part of the root Cargo workspace.
3 years ago
[[package]]
name = "miette"
Update miette dependency to 5.1 (#4412) Just some dependency gardening, no other external motivation.
2 years ago
version = "5.1.0"
Make ISLE part of the root Cargo workspace.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update miette dependency to 5.1 (#4412) Just some dependency gardening, no other external motivation.
2 years ago
checksum = "6ec753a43fd71bb5f28751c9ec17fbe89d6d26ca8282d1e1f82f5ac3dbd5581e"
Make ISLE part of the root Cargo workspace.
3 years ago
dependencies = [
"atty",
"backtrace",
"miette-derive",
"once_cell",
"owo-colors",
"supports-color",
"supports-hyperlinks",
"supports-unicode",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"terminal_size",
Cranelift: do not check in generated ISLE code; regenerate on every compile. (#4143) This PR fixes #4066: it modifies the Cranelift `build.rs` workflow to invoke the ISLE DSL compiler on every compilation, rather than only when the user specifies a special "rebuild ISLE" feature. The main benefit of this change is that it vastly simplifies the mental model required of developers, and removes a bunch of failure modes we have tried to work around in other ways. There is now just one "source of truth", the ISLE source itself, in the repository, and so there is no need to understand a special "rebuild" step and how to handle merge errors. There is no special process needed to develop the compiler when modifying the DSL. And there is no "noise" in the git history produced by constantly-regenerated files. The two main downsides we discussed in #4066 are: - Compile time could increase, by adding more to the "meta" step before the main build; - It becomes less obvious where the source definitions are (everything becomes more "magic"), which makes exploration and debugging harder. This PR addresses each of these concerns: 1. To maintain reasonable compile time, it includes work to cut down the dependencies of the `cranelift-isle` crate to *nothing* (only the Rust stdlib), in the default build. It does this by putting the error-reporting bits (`miette` crate) under an optional feature, and the logging (`log` crate) under a feature-controlled macro, and manually writing an `Error` impl rather than using `thiserror`. This completely avoids proc macros and the `syn` build slowness. The user can still get nice errors out of `miette`: this is enabled by specifying a Cargo feature `--features isle-errors`. 2. To allow the user to optionally inspect the generated source, which nominally lives in a hard-to-find path inside `target/` now, this PR adds a feature `isle-in-source-tree` that, as implied by the name, moves the target for ISLE generated source into the source tree, at `cranelift/codegen/isle_generated_source/`. It seems reasonable to do this when an explicit feature (opt-in) is specified because this is how ISLE regeneration currently works as well. To prevent surprises, if the feature is *not* specified, the build fails if this directory exists.
3 years ago
"textwrap 0.15.0",
Make ISLE part of the root Cargo workspace.
3 years ago
"thiserror",
Cranelift: do not check in generated ISLE code; regenerate on every compile. (#4143) This PR fixes #4066: it modifies the Cranelift `build.rs` workflow to invoke the ISLE DSL compiler on every compilation, rather than only when the user specifies a special "rebuild ISLE" feature. The main benefit of this change is that it vastly simplifies the mental model required of developers, and removes a bunch of failure modes we have tried to work around in other ways. There is now just one "source of truth", the ISLE source itself, in the repository, and so there is no need to understand a special "rebuild" step and how to handle merge errors. There is no special process needed to develop the compiler when modifying the DSL. And there is no "noise" in the git history produced by constantly-regenerated files. The two main downsides we discussed in #4066 are: - Compile time could increase, by adding more to the "meta" step before the main build; - It becomes less obvious where the source definitions are (everything becomes more "magic"), which makes exploration and debugging harder. This PR addresses each of these concerns: 1. To maintain reasonable compile time, it includes work to cut down the dependencies of the `cranelift-isle` crate to *nothing* (only the Rust stdlib), in the default build. It does this by putting the error-reporting bits (`miette` crate) under an optional feature, and the logging (`log` crate) under a feature-controlled macro, and manually writing an `Error` impl rather than using `thiserror`. This completely avoids proc macros and the `syn` build slowness. The user can still get nice errors out of `miette`: this is enabled by specifying a Cargo feature `--features isle-errors`. 2. To allow the user to optionally inspect the generated source, which nominally lives in a hard-to-find path inside `target/` now, this PR adds a feature `isle-in-source-tree` that, as implied by the name, moves the target for ISLE generated source into the source tree, at `cranelift/codegen/isle_generated_source/`. It seems reasonable to do this when an explicit feature (opt-in) is specified because this is how ISLE regeneration currently works as well. To prevent surprises, if the feature is *not* specified, the build fails if this directory exists.
3 years ago
"unicode-width",
Make ISLE part of the root Cargo workspace.
3 years ago
]
[[package]]
name = "miette-derive"
Update miette dependency to 5.1 (#4412) Just some dependency gardening, no other external motivation.
2 years ago
version = "5.1.0"
Make ISLE part of the root Cargo workspace.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update miette dependency to 5.1 (#4412) Just some dependency gardening, no other external motivation.
2 years ago
checksum = "fdfc33ea15c5446600f91d319299dd40301614afff7143cdfa9bf4c09da3ca64"
Make ISLE part of the root Cargo workspace.
3 years ago
dependencies = [
"proc-macro2",
"quote",
"syn",
]
externref: implement stack map-based garbage collection For host VM code, we use plain reference counting, where cloning increments the reference count, and dropping decrements it. We can avoid many of the on-stack increment/decrement operations that typically plague the performance of reference counting via Rust's ownership and borrowing system. Moving a `VMExternRef` avoids mutating its reference count, and borrowing it either avoids the reference count increment or delays it until if/when the `VMExternRef` is cloned. When passing a `VMExternRef` into compiled Wasm code, we don't want to do reference count mutations for every compiled `local.{get,set}`, nor for every function call. Therefore, we use a variation of **deferred reference counting**, where we only mutate reference counts when storing `VMExternRef`s somewhere that outlives the activation: into a global or table. Simultaneously, we over-approximate the set of `VMExternRef`s that are inside Wasm function activations. Periodically, we walk the stack at GC safe points, and use stack map information to precisely identify the set of `VMExternRef`s inside Wasm activations. Then we take the difference between this precise set and our over-approximation, and decrement the reference count for each of the `VMExternRef`s that are in our over-approximation but not in the precise set. Finally, the over-approximation is replaced with the precise set. The `VMExternRefActivationsTable` implements the over-approximized set of `VMExternRef`s referenced by Wasm activations. Calling a Wasm function and passing it a `VMExternRef` moves the `VMExternRef` into the table, and the compiled Wasm function logically "borrows" the `VMExternRef` from the table. Similarly, `global.get` and `table.get` operations clone the gotten `VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the reference out of the table. When a `VMExternRef` is returned to host code from a Wasm function, the host increments the reference count (because the reference is logically "borrowed" from the `VMExternRefActivationsTable` and the reference count from the table will be dropped at the next GC). For more general information on deferred reference counting, see *An Examination of Deferred Reference Counting and Cycle Detection* by Quinane: https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf cc #929 Fixes #1804
4 years ago
[[package]]
name = "miniz_oxide"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.5.1"
externref: implement stack map-based garbage collection For host VM code, we use plain reference counting, where cloning increments the reference count, and dropping decrements it. We can avoid many of the on-stack increment/decrement operations that typically plague the performance of reference counting via Rust's ownership and borrowing system. Moving a `VMExternRef` avoids mutating its reference count, and borrowing it either avoids the reference count increment or delays it until if/when the `VMExternRef` is cloned. When passing a `VMExternRef` into compiled Wasm code, we don't want to do reference count mutations for every compiled `local.{get,set}`, nor for every function call. Therefore, we use a variation of **deferred reference counting**, where we only mutate reference counts when storing `VMExternRef`s somewhere that outlives the activation: into a global or table. Simultaneously, we over-approximate the set of `VMExternRef`s that are inside Wasm function activations. Periodically, we walk the stack at GC safe points, and use stack map information to precisely identify the set of `VMExternRef`s inside Wasm activations. Then we take the difference between this precise set and our over-approximation, and decrement the reference count for each of the `VMExternRef`s that are in our over-approximation but not in the precise set. Finally, the over-approximation is replaced with the precise set. The `VMExternRefActivationsTable` implements the over-approximized set of `VMExternRef`s referenced by Wasm activations. Calling a Wasm function and passing it a `VMExternRef` moves the `VMExternRef` into the table, and the compiled Wasm function logically "borrows" the `VMExternRef` from the table. Similarly, `global.get` and `table.get` operations clone the gotten `VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the reference out of the table. When a `VMExternRef` is returned to host code from a Wasm function, the host increments the reference count (because the reference is logically "borrowed" from the `VMExternRefActivationsTable` and the reference count from the table will be dropped at the next GC). For more general information on deferred reference counting, see *An Examination of Deferred Reference Counting and Cycle Detection* by Quinane: https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf cc #929 Fixes #1804
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "d2b29bd4bc3f33391105ebee3589c19197c4271e3e5a9ec9bfe8127eeff8f082"
externref: implement stack map-based garbage collection For host VM code, we use plain reference counting, where cloning increments the reference count, and dropping decrements it. We can avoid many of the on-stack increment/decrement operations that typically plague the performance of reference counting via Rust's ownership and borrowing system. Moving a `VMExternRef` avoids mutating its reference count, and borrowing it either avoids the reference count increment or delays it until if/when the `VMExternRef` is cloned. When passing a `VMExternRef` into compiled Wasm code, we don't want to do reference count mutations for every compiled `local.{get,set}`, nor for every function call. Therefore, we use a variation of **deferred reference counting**, where we only mutate reference counts when storing `VMExternRef`s somewhere that outlives the activation: into a global or table. Simultaneously, we over-approximate the set of `VMExternRef`s that are inside Wasm function activations. Periodically, we walk the stack at GC safe points, and use stack map information to precisely identify the set of `VMExternRef`s inside Wasm activations. Then we take the difference between this precise set and our over-approximation, and decrement the reference count for each of the `VMExternRef`s that are in our over-approximation but not in the precise set. Finally, the over-approximation is replaced with the precise set. The `VMExternRefActivationsTable` implements the over-approximized set of `VMExternRef`s referenced by Wasm activations. Calling a Wasm function and passing it a `VMExternRef` moves the `VMExternRef` into the table, and the compiled Wasm function logically "borrows" the `VMExternRef` from the table. Similarly, `global.get` and `table.get` operations clone the gotten `VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the reference out of the table. When a `VMExternRef` is returned to host code from a Wasm function, the host increments the reference count (because the reference is logically "borrowed" from the `VMExternRefActivationsTable` and the reference count from the table will be dropped at the next GC). For more general information on deferred reference counting, see *An Examination of Deferred Reference Counting and Cycle Detection* by Quinane: https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf cc #929 Fixes #1804
4 years ago
dependencies = [
Wasmtime 0.19.0 and Cranelift 0.66.0 (#2027) This commit updates Wasmtime's version to 0.19.0, Cranelift's version to 0.66.0, and updates the release notes as well.
4 years ago
"adler",
externref: implement stack map-based garbage collection For host VM code, we use plain reference counting, where cloning increments the reference count, and dropping decrements it. We can avoid many of the on-stack increment/decrement operations that typically plague the performance of reference counting via Rust's ownership and borrowing system. Moving a `VMExternRef` avoids mutating its reference count, and borrowing it either avoids the reference count increment or delays it until if/when the `VMExternRef` is cloned. When passing a `VMExternRef` into compiled Wasm code, we don't want to do reference count mutations for every compiled `local.{get,set}`, nor for every function call. Therefore, we use a variation of **deferred reference counting**, where we only mutate reference counts when storing `VMExternRef`s somewhere that outlives the activation: into a global or table. Simultaneously, we over-approximate the set of `VMExternRef`s that are inside Wasm function activations. Periodically, we walk the stack at GC safe points, and use stack map information to precisely identify the set of `VMExternRef`s inside Wasm activations. Then we take the difference between this precise set and our over-approximation, and decrement the reference count for each of the `VMExternRef`s that are in our over-approximation but not in the precise set. Finally, the over-approximation is replaced with the precise set. The `VMExternRefActivationsTable` implements the over-approximized set of `VMExternRef`s referenced by Wasm activations. Calling a Wasm function and passing it a `VMExternRef` moves the `VMExternRef` into the table, and the compiled Wasm function logically "borrows" the `VMExternRef` from the table. Similarly, `global.get` and `table.get` operations clone the gotten `VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the reference out of the table. When a `VMExternRef` is returned to host code from a Wasm function, the host increments the reference count (because the reference is logically "borrowed" from the `VMExternRefActivationsTable` and the reference count from the table will be dropped at the next GC). For more general information on deferred reference counting, see *An Examination of Deferred Reference Counting and Cycle Detection* by Quinane: https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf cc #929 Fixes #1804
4 years ago
]
follow the types
4 years ago
[[package]]
name = "mio"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.8.2"
follow the types
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "52da4364ffb0e4fe33a9841a98a3f3014fb964045ce4f7a45a398243c8d6b0c9"
follow the types
4 years ago
dependencies = [
"libc",
"log",
"miow",
"ntapi",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"wasi 0.11.0+wasi-snapshot-preview1",
follow the types
4 years ago
"winapi",
]
[[package]]
name = "miow"
version = "0.3.7"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "b9f1c5b025cda876f66ef43a113f91ebc9f4ccef34843000e0adf6ebbab84e21"
dependencies = [
"winapi",
]
[[package]]
name = "ntapi"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.3.7"
follow the types
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "c28774a7fd2fbb4f0babd8237ce554b73af68021b5f695a3cebd6c59bac0980f"
follow the types
4 years ago
dependencies = [
"winapi",
]
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
[[package]]
name = "num-bigint"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
version = "0.4.3"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
checksum = "f93ab6289c7b344a8a9f60f88d80aa20032336fe78da341afc91c8a2341fc75f"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"autocfg 1.1.0",
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
"num-integer",
"num-traits",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "num-bigint-dig"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.7.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "4547ee5541c18742396ae2c895d0717d0f886d8823b8399cdaf7b07d63ad0480"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"autocfg 0.1.8",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"byteorder",
"lazy_static",
"libm",
"num-integer",
"num-iter",
"num-traits",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"rand 0.8.5",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"serde",
"smallvec",
"zeroize",
]
wiggle: can swap in `tracing` for args
5 years ago
[[package]]
name = "num-integer"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "0.1.45"
wiggle: can swap in `tracing` for args
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "225d3389fb3509a24c93f5c29eb6bde2586b98d9f016636dff58d7c6f7569cd9"
wiggle: can swap in `tracing` for args
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"autocfg 1.1.0",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"num-traits",
]
[[package]]
name = "num-iter"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.1.43"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "7d03e6c028c5dc5cac6e2dec0efda81fc887605bb3d884578bb6d6bf7514e252"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"autocfg 1.1.0",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"num-integer",
wiggle: can swap in `tracing` for args
5 years ago
"num-traits",
]
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
[[package]]
name = "num-rational"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
version = "0.4.1"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
checksum = "0638a1c9d0a3c0914158145bc76cff373a75a627e6ecbfb71cbe6f453a5a19b0"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"autocfg 1.1.0",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"num-bigint",
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
"num-integer",
"num-traits",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "num-traits"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "0.2.15"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "578ede34cf02f8924ab9447f50c28075b4d3e5b269972345e7e0372b38c6cdcd"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"autocfg 1.1.0",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"libm",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "num_cpus"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.13.1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "19e64526ebdee182341572e50e9ad03965aa510cd94427a4549448f285e957a1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"hermit-abi 0.1.19",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"libc",
]
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "number_prefix"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "17b02fc0ff9a9e4b35b3342880f48e896ebf69f2967921fe8646bf5b7125956a"
Update `backtrace` to 0.3.61
3 years ago
[[package]]
name = "object"
Update some dependency versions used by Wasmtime (#4405) No major motivation here, mostly just dependency gardening.
2 years ago
version = "0.29.0"
Update `backtrace` to 0.3.61
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependency versions used by Wasmtime (#4405) No major motivation here, mostly just dependency gardening.
2 years ago
checksum = "21158b2c33aa6d4561f1c0a6ea283ca92bc54802a93b263e910746d679a7eb53"
Update `backtrace` to 0.3.61
3 years ago
dependencies = [
Update `object` to 0.26.0
3 years ago
"crc32fast",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"hashbrown",
Update `object` to 0.26.0
3 years ago
"indexmap",
Update `backtrace` to 0.3.61
3 years ago
"memchr",
]
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
[[package]]
name = "ocaml-boxroot-sys"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5186393bfbee4ce2bc5bbb82beafb77e85c1d0a557e3cfc8c8a0d63d7845fed5"
dependencies = [
"cc",
]
[[package]]
name = "ocaml-interop"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.8.8"
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "2e01e08412a7e072a90a225d2ae49a2860aeea853ce673bc63891dbf86aed063"
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
dependencies = [
"ocaml-boxroot-sys",
"ocaml-sys",
"static_assertions",
]
[[package]]
name = "ocaml-sys"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.22.3"
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "73ec6ca7d41458442627435afb8f4671e83fd642e8a560171d671a1f679aa3cf"
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
dependencies = [
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"cty",
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
]
Refactor and fill out wasmtime's C API (#1415) * Refactor and improve safety of C API This commit is intended to be a relatively large refactoring of the C API which is targeted at improving the safety of our C API definitions. Not all of the APIs have been updated yet but this is intended to be the start. The goal here is to make as many functions safe as we can, expressing inputs/outputs as native Rust types rather than raw pointers wherever possible. For example instead of `*const wasm_foo_t` we'd take `&wasm_foo_t`. Instead of returning `*mut wasm_foo_t` we'd return `Box<wasm_foo_t>`. No ABI/API changes are intended from this commit, it's supposed to only change how we define all these functions internally. This commit also additionally implements a few more API bindings for exposed vector types by unifying everything into one macro. Finally, this commit moves many internal caches in the C API to the `OnceCell` type which provides a safe interface for one-time initialization. * Split apart monolithic C API `lib.rs` This commit splits the monolithic `src/lib.rs` in the C API crate into lots of smaller files. The goal here is to make this a bit more readable and digestable. Each module now contains only API bindings for a particular type, roughly organized around the grouping in the wasm.h header file already. A few more extensions were added, such as filling out `*_as_*` conversions with both const and non-const versions. Additionally many APIs were made safer in the same style as the previous commit, generally preferring Rust types rather than raw pointer types. Overall no functional change is intended here, it should be mostly just code movement and minor refactorings! * Make a few wasi C bindings safer Use safe Rust types where we can and touch up a few APIs here and there. * Implement `wasm_*type_as_externtype*` APIs This commit restructures `wasm_externtype_t` to be similar to `wasm_extern_t` so type conversion between the `*_extern_*` variants to the concrete variants are all simple casts. (checked in the case of general to concrete, of course). * Consistently imlpement host info functions in the API This commit adds a small macro crate which is then used to consistently define the various host-info-related functions in the C API. The goal here is to try to mirror what the `wasm.h` header provides to provide a full implementation of the header.
5 years ago
[[package]]
name = "once_cell"
make backtrace collection a Config field rather than a cargo feature (#4183) * sorta working in runtime * wasmtime-runtime: get rid of wasm-backtrace feature * wasmtime: factor to make backtraces recording optional. not configurable yet * get rid of wasm-backtrace features * trap tests: now a Trap optionally contains backtrace * eliminate wasm-backtrace feature * code review fixes * ci: no more wasm-backtrace feature * c_api: backtraces always enabled * config: unwind required by backtraces and ref types * plumbed * test that disabling backtraces works * code review comments * fuzzing generator: wasm_backtrace is a runtime config now * doc fix
2 years ago
version = "1.12.0"
Refactor and fill out wasmtime's C API (#1415) * Refactor and improve safety of C API This commit is intended to be a relatively large refactoring of the C API which is targeted at improving the safety of our C API definitions. Not all of the APIs have been updated yet but this is intended to be the start. The goal here is to make as many functions safe as we can, expressing inputs/outputs as native Rust types rather than raw pointers wherever possible. For example instead of `*const wasm_foo_t` we'd take `&wasm_foo_t`. Instead of returning `*mut wasm_foo_t` we'd return `Box<wasm_foo_t>`. No ABI/API changes are intended from this commit, it's supposed to only change how we define all these functions internally. This commit also additionally implements a few more API bindings for exposed vector types by unifying everything into one macro. Finally, this commit moves many internal caches in the C API to the `OnceCell` type which provides a safe interface for one-time initialization. * Split apart monolithic C API `lib.rs` This commit splits the monolithic `src/lib.rs` in the C API crate into lots of smaller files. The goal here is to make this a bit more readable and digestable. Each module now contains only API bindings for a particular type, roughly organized around the grouping in the wasm.h header file already. A few more extensions were added, such as filling out `*_as_*` conversions with both const and non-const versions. Additionally many APIs were made safer in the same style as the previous commit, generally preferring Rust types rather than raw pointer types. Overall no functional change is intended here, it should be mostly just code movement and minor refactorings! * Make a few wasi C bindings safer Use safe Rust types where we can and touch up a few APIs here and there. * Implement `wasm_*type_as_externtype*` APIs This commit restructures `wasm_externtype_t` to be similar to `wasm_extern_t` so type conversion between the `*_extern_*` variants to the concrete variants are all simple casts. (checked in the case of general to concrete, of course). * Consistently imlpement host info functions in the API This commit adds a small macro crate which is then used to consistently define the various host-info-related functions in the C API. The goal here is to try to mirror what the `wasm.h` header provides to provide a full implementation of the header.
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
make backtrace collection a Config field rather than a cargo feature (#4183) * sorta working in runtime * wasmtime-runtime: get rid of wasm-backtrace feature * wasmtime: factor to make backtraces recording optional. not configurable yet * get rid of wasm-backtrace features * trap tests: now a Trap optionally contains backtrace * eliminate wasm-backtrace feature * code review fixes * ci: no more wasm-backtrace feature * c_api: backtraces always enabled * config: unwind required by backtraces and ref types * plumbed * test that disabling backtraces works * code review comments * fuzzing generator: wasm_backtrace is a runtime config now * doc fix
2 years ago
checksum = "7709cef83f0c1f58f666e746a08b21e0085f7440fa6a29cc194d68aac97a4225"
Refactor and fill out wasmtime's C API (#1415) * Refactor and improve safety of C API This commit is intended to be a relatively large refactoring of the C API which is targeted at improving the safety of our C API definitions. Not all of the APIs have been updated yet but this is intended to be the start. The goal here is to make as many functions safe as we can, expressing inputs/outputs as native Rust types rather than raw pointers wherever possible. For example instead of `*const wasm_foo_t` we'd take `&wasm_foo_t`. Instead of returning `*mut wasm_foo_t` we'd return `Box<wasm_foo_t>`. No ABI/API changes are intended from this commit, it's supposed to only change how we define all these functions internally. This commit also additionally implements a few more API bindings for exposed vector types by unifying everything into one macro. Finally, this commit moves many internal caches in the C API to the `OnceCell` type which provides a safe interface for one-time initialization. * Split apart monolithic C API `lib.rs` This commit splits the monolithic `src/lib.rs` in the C API crate into lots of smaller files. The goal here is to make this a bit more readable and digestable. Each module now contains only API bindings for a particular type, roughly organized around the grouping in the wasm.h header file already. A few more extensions were added, such as filling out `*_as_*` conversions with both const and non-const versions. Additionally many APIs were made safer in the same style as the previous commit, generally preferring Rust types rather than raw pointer types. Overall no functional change is intended here, it should be mostly just code movement and minor refactorings! * Make a few wasi C bindings safer Use safe Rust types where we can and touch up a few APIs here and there. * Implement `wasm_*type_as_externtype*` APIs This commit restructures `wasm_externtype_t` to be similar to `wasm_extern_t` so type conversion between the `*_extern_*` variants to the concrete variants are all simple casts. (checked in the case of general to concrete, of course). * Consistently imlpement host info functions in the API This commit adds a small macro crate which is then used to consistently define the various host-info-related functions in the C API. The goal here is to try to mirror what the `wasm.h` header provides to provide a full implementation of the header.
5 years ago
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "oorandom"
version = "11.1.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "0ab1bc2a289d34bd04a330323ac98a1b4bc82c9d9fcb1e66b63caa84da26b575"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "opaque-debug"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
version = "0.3.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
checksum = "624a8340c38c1b80fd549087862da4ba43e08858af025b236e509b6649fc13d5"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
[[package]]
name = "openvino"
wasi-nn: update openvino crate, use external CI action (#4383) * ci: replace OpenVINO installer action To test wasi-nn, we currently use an OpenVINO backend. The Wasmtime CI must install OpenVINO using a custom GitHub action. This CI action has not been updated in some time and in the meantime OpenVINO (and the OpenVINO crates) have released several new versions. https://github.com/abrown/install-openvino-action is an external action that we plan to keep up to date with the latest releases. This change replaces the current CI action with that one. * wasi-nn: upgrade openvino dependency to v0.4.1 This eliminates a `lazy_static` dependency and changes a few parameters to pass by reference. Importantly, it enables support for the latest versions of OpenVINO (v2022.*) in wasi-nn. * ci: update wasi-nn script to source correct env script * ci: really use the correct path for the env script Also, clarify which directory OpenVINO is installed in (the symlink may not be present).
2 years ago
version = "0.4.1"
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
wasi-nn: update openvino crate, use external CI action (#4383) * ci: replace OpenVINO installer action To test wasi-nn, we currently use an OpenVINO backend. The Wasmtime CI must install OpenVINO using a custom GitHub action. This CI action has not been updated in some time and in the meantime OpenVINO (and the OpenVINO crates) have released several new versions. https://github.com/abrown/install-openvino-action is an external action that we plan to keep up to date with the latest releases. This change replaces the current CI action with that one. * wasi-nn: upgrade openvino dependency to v0.4.1 This eliminates a `lazy_static` dependency and changes a few parameters to pass by reference. Importantly, it enables support for the latest versions of OpenVINO (v2022.*) in wasi-nn. * ci: update wasi-nn script to source correct env script * ci: really use the correct path for the env script Also, clarify which directory OpenVINO is installed in (the symlink may not be present).
2 years ago
checksum = "d9627908ea4af5766040aa191c8607479af7f70b45fdf6e999b450069fea851a"
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
dependencies = [
"openvino-sys",
"thiserror",
]
wasi-nn: turn it on by default (#2859) * wasi-nn: turn it on by default This change makes the wasi-nn Cargo feature a default feature. Previously, a wasi-nn user would have to build a separate Wasmtime binary (e.g. `cargo build --features wasi-nn ...`) to use wasi-nn and the resulting binary would require OpenVINO shared libraries to be present in the environment in order to run (otherwise it would fail immediately with linking errors). With recent changes to the `openvino` crate, the wasi-nn implementation can defer the loading of the OpenVINO shared libraries until runtime (i.e., when the user Wasm program calls `wasi_ephemeral_nn::load`) and display a user-level error if anything goes wrong (e.g., the OpenVINO libraries are not present on the system). This runtime-linking addition allows the wasi-nn feature to be turned on by default and shipped with upcoming releases of Wasmtime. This change should be transparent for users who do not use wasi-nn: the `openvino` crate is small and the newly-available wasi-nn imports only affect programs in which they are used. For those interested in reviewing the runtime linking approach added to the `openvino` crate, see https://github.com/intel/openvino-rs/pull/19. * wasi-nn spec path: don't use canonicalize * Allow dependencies using the ISC license The ISC license should be [just as permissive](https://choosealicense.com/licenses/isc) as MIT, e.g., with no additional limitations. * Add a `--wasi-modules` flag This flag controls which WASI modules are made available to the Wasm program. This initial commit enables `wasi-common` by default (equivalent to `--wasi-modules=all`) and allows `wasi-nn` and `wasi-crypto` to be added in either individually (e.g., `--wasi-modules=wasi-nn`) or as a group (e.g., `--wasi-modules=all-experimental`). * wasi-crypto: fix unused dependency Co-authored-by: Pat Hickey <pat@moreproductive.org>
4 years ago
[[package]]
name = "openvino-finder"
wasi-nn: update openvino crate, use external CI action (#4383) * ci: replace OpenVINO installer action To test wasi-nn, we currently use an OpenVINO backend. The Wasmtime CI must install OpenVINO using a custom GitHub action. This CI action has not been updated in some time and in the meantime OpenVINO (and the OpenVINO crates) have released several new versions. https://github.com/abrown/install-openvino-action is an external action that we plan to keep up to date with the latest releases. This change replaces the current CI action with that one. * wasi-nn: upgrade openvino dependency to v0.4.1 This eliminates a `lazy_static` dependency and changes a few parameters to pass by reference. Importantly, it enables support for the latest versions of OpenVINO (v2022.*) in wasi-nn. * ci: update wasi-nn script to source correct env script * ci: really use the correct path for the env script Also, clarify which directory OpenVINO is installed in (the symlink may not be present).
2 years ago
version = "0.4.1"
wasi-nn: turn it on by default (#2859) * wasi-nn: turn it on by default This change makes the wasi-nn Cargo feature a default feature. Previously, a wasi-nn user would have to build a separate Wasmtime binary (e.g. `cargo build --features wasi-nn ...`) to use wasi-nn and the resulting binary would require OpenVINO shared libraries to be present in the environment in order to run (otherwise it would fail immediately with linking errors). With recent changes to the `openvino` crate, the wasi-nn implementation can defer the loading of the OpenVINO shared libraries until runtime (i.e., when the user Wasm program calls `wasi_ephemeral_nn::load`) and display a user-level error if anything goes wrong (e.g., the OpenVINO libraries are not present on the system). This runtime-linking addition allows the wasi-nn feature to be turned on by default and shipped with upcoming releases of Wasmtime. This change should be transparent for users who do not use wasi-nn: the `openvino` crate is small and the newly-available wasi-nn imports only affect programs in which they are used. For those interested in reviewing the runtime linking approach added to the `openvino` crate, see https://github.com/intel/openvino-rs/pull/19. * wasi-nn spec path: don't use canonicalize * Allow dependencies using the ISC license The ISC license should be [just as permissive](https://choosealicense.com/licenses/isc) as MIT, e.g., with no additional limitations. * Add a `--wasi-modules` flag This flag controls which WASI modules are made available to the Wasm program. This initial commit enables `wasi-common` by default (equivalent to `--wasi-modules=all`) and allows `wasi-nn` and `wasi-crypto` to be added in either individually (e.g., `--wasi-modules=wasi-nn`) or as a group (e.g., `--wasi-modules=all-experimental`). * wasi-crypto: fix unused dependency Co-authored-by: Pat Hickey <pat@moreproductive.org>
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
wasi-nn: update openvino crate, use external CI action (#4383) * ci: replace OpenVINO installer action To test wasi-nn, we currently use an OpenVINO backend. The Wasmtime CI must install OpenVINO using a custom GitHub action. This CI action has not been updated in some time and in the meantime OpenVINO (and the OpenVINO crates) have released several new versions. https://github.com/abrown/install-openvino-action is an external action that we plan to keep up to date with the latest releases. This change replaces the current CI action with that one. * wasi-nn: upgrade openvino dependency to v0.4.1 This eliminates a `lazy_static` dependency and changes a few parameters to pass by reference. Importantly, it enables support for the latest versions of OpenVINO (v2022.*) in wasi-nn. * ci: update wasi-nn script to source correct env script * ci: really use the correct path for the env script Also, clarify which directory OpenVINO is installed in (the symlink may not be present).
2 years ago
checksum = "213893e484dcf3db4af79d498a955f7c4c209d06e7020779cda68fca779c2578"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"log",
]
wasi-nn: turn it on by default (#2859) * wasi-nn: turn it on by default This change makes the wasi-nn Cargo feature a default feature. Previously, a wasi-nn user would have to build a separate Wasmtime binary (e.g. `cargo build --features wasi-nn ...`) to use wasi-nn and the resulting binary would require OpenVINO shared libraries to be present in the environment in order to run (otherwise it would fail immediately with linking errors). With recent changes to the `openvino` crate, the wasi-nn implementation can defer the loading of the OpenVINO shared libraries until runtime (i.e., when the user Wasm program calls `wasi_ephemeral_nn::load`) and display a user-level error if anything goes wrong (e.g., the OpenVINO libraries are not present on the system). This runtime-linking addition allows the wasi-nn feature to be turned on by default and shipped with upcoming releases of Wasmtime. This change should be transparent for users who do not use wasi-nn: the `openvino` crate is small and the newly-available wasi-nn imports only affect programs in which they are used. For those interested in reviewing the runtime linking approach added to the `openvino` crate, see https://github.com/intel/openvino-rs/pull/19. * wasi-nn spec path: don't use canonicalize * Allow dependencies using the ISC license The ISC license should be [just as permissive](https://choosealicense.com/licenses/isc) as MIT, e.g., with no additional limitations. * Add a `--wasi-modules` flag This flag controls which WASI modules are made available to the Wasm program. This initial commit enables `wasi-common` by default (equivalent to `--wasi-modules=all`) and allows `wasi-nn` and `wasi-crypto` to be added in either individually (e.g., `--wasi-modules=wasi-nn`) or as a group (e.g., `--wasi-modules=all-experimental`). * wasi-crypto: fix unused dependency Co-authored-by: Pat Hickey <pat@moreproductive.org>
4 years ago
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
[[package]]
name = "openvino-sys"
wasi-nn: update openvino crate, use external CI action (#4383) * ci: replace OpenVINO installer action To test wasi-nn, we currently use an OpenVINO backend. The Wasmtime CI must install OpenVINO using a custom GitHub action. This CI action has not been updated in some time and in the meantime OpenVINO (and the OpenVINO crates) have released several new versions. https://github.com/abrown/install-openvino-action is an external action that we plan to keep up to date with the latest releases. This change replaces the current CI action with that one. * wasi-nn: upgrade openvino dependency to v0.4.1 This eliminates a `lazy_static` dependency and changes a few parameters to pass by reference. Importantly, it enables support for the latest versions of OpenVINO (v2022.*) in wasi-nn. * ci: update wasi-nn script to source correct env script * ci: really use the correct path for the env script Also, clarify which directory OpenVINO is installed in (the symlink may not be present).
2 years ago
version = "0.4.1"
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
wasi-nn: update openvino crate, use external CI action (#4383) * ci: replace OpenVINO installer action To test wasi-nn, we currently use an OpenVINO backend. The Wasmtime CI must install OpenVINO using a custom GitHub action. This CI action has not been updated in some time and in the meantime OpenVINO (and the OpenVINO crates) have released several new versions. https://github.com/abrown/install-openvino-action is an external action that we plan to keep up to date with the latest releases. This change replaces the current CI action with that one. * wasi-nn: upgrade openvino dependency to v0.4.1 This eliminates a `lazy_static` dependency and changes a few parameters to pass by reference. Importantly, it enables support for the latest versions of OpenVINO (v2022.*) in wasi-nn. * ci: update wasi-nn script to source correct env script * ci: really use the correct path for the env script Also, clarify which directory OpenVINO is installed in (the symlink may not be present).
2 years ago
checksum = "e2ba37c26ad2591acc48abee5350d65daa263bf0ab7a79d2ab6999d4b20130ec"
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
dependencies = [
wasi-nn: turn it on by default (#2859) * wasi-nn: turn it on by default This change makes the wasi-nn Cargo feature a default feature. Previously, a wasi-nn user would have to build a separate Wasmtime binary (e.g. `cargo build --features wasi-nn ...`) to use wasi-nn and the resulting binary would require OpenVINO shared libraries to be present in the environment in order to run (otherwise it would fail immediately with linking errors). With recent changes to the `openvino` crate, the wasi-nn implementation can defer the loading of the OpenVINO shared libraries until runtime (i.e., when the user Wasm program calls `wasi_ephemeral_nn::load`) and display a user-level error if anything goes wrong (e.g., the OpenVINO libraries are not present on the system). This runtime-linking addition allows the wasi-nn feature to be turned on by default and shipped with upcoming releases of Wasmtime. This change should be transparent for users who do not use wasi-nn: the `openvino` crate is small and the newly-available wasi-nn imports only affect programs in which they are used. For those interested in reviewing the runtime linking approach added to the `openvino` crate, see https://github.com/intel/openvino-rs/pull/19. * wasi-nn spec path: don't use canonicalize * Allow dependencies using the ISC license The ISC license should be [just as permissive](https://choosealicense.com/licenses/isc) as MIT, e.g., with no additional limitations. * Add a `--wasi-modules` flag This flag controls which WASI modules are made available to the Wasm program. This initial commit enables `wasi-common` by default (equivalent to `--wasi-modules=all`) and allows `wasi-nn` and `wasi-crypto` to be added in either individually (e.g., `--wasi-modules=wasi-nn`) or as a group (e.g., `--wasi-modules=all-experimental`). * wasi-crypto: fix unused dependency Co-authored-by: Pat Hickey <pat@moreproductive.org>
4 years ago
"libloading",
wasi-nn: update openvino crate, use external CI action (#4383) * ci: replace OpenVINO installer action To test wasi-nn, we currently use an OpenVINO backend. The Wasmtime CI must install OpenVINO using a custom GitHub action. This CI action has not been updated in some time and in the meantime OpenVINO (and the OpenVINO crates) have released several new versions. https://github.com/abrown/install-openvino-action is an external action that we plan to keep up to date with the latest releases. This change replaces the current CI action with that one. * wasi-nn: upgrade openvino dependency to v0.4.1 This eliminates a `lazy_static` dependency and changes a few parameters to pass by reference. Importantly, it enables support for the latest versions of OpenVINO (v2022.*) in wasi-nn. * ci: update wasi-nn script to source correct env script * ci: really use the correct path for the env script Also, clarify which directory OpenVINO is installed in (the symlink may not be present).
2 years ago
"once_cell",
wasi-nn: turn it on by default (#2859) * wasi-nn: turn it on by default This change makes the wasi-nn Cargo feature a default feature. Previously, a wasi-nn user would have to build a separate Wasmtime binary (e.g. `cargo build --features wasi-nn ...`) to use wasi-nn and the resulting binary would require OpenVINO shared libraries to be present in the environment in order to run (otherwise it would fail immediately with linking errors). With recent changes to the `openvino` crate, the wasi-nn implementation can defer the loading of the OpenVINO shared libraries until runtime (i.e., when the user Wasm program calls `wasi_ephemeral_nn::load`) and display a user-level error if anything goes wrong (e.g., the OpenVINO libraries are not present on the system). This runtime-linking addition allows the wasi-nn feature to be turned on by default and shipped with upcoming releases of Wasmtime. This change should be transparent for users who do not use wasi-nn: the `openvino` crate is small and the newly-available wasi-nn imports only affect programs in which they are used. For those interested in reviewing the runtime linking approach added to the `openvino` crate, see https://github.com/intel/openvino-rs/pull/19. * wasi-nn spec path: don't use canonicalize * Allow dependencies using the ISC license The ISC license should be [just as permissive](https://choosealicense.com/licenses/isc) as MIT, e.g., with no additional limitations. * Add a `--wasi-modules` flag This flag controls which WASI modules are made available to the Wasm program. This initial commit enables `wasi-common` by default (equivalent to `--wasi-modules=all`) and allows `wasi-nn` and `wasi-crypto` to be added in either individually (e.g., `--wasi-modules=wasi-nn`) or as a group (e.g., `--wasi-modules=all-experimental`). * wasi-crypto: fix unused dependency Co-authored-by: Pat Hickey <pat@moreproductive.org>
4 years ago
"openvino-finder",
wasi-nn: update openvino crate, use external CI action (#4383) * ci: replace OpenVINO installer action To test wasi-nn, we currently use an OpenVINO backend. The Wasmtime CI must install OpenVINO using a custom GitHub action. This CI action has not been updated in some time and in the meantime OpenVINO (and the OpenVINO crates) have released several new versions. https://github.com/abrown/install-openvino-action is an external action that we plan to keep up to date with the latest releases. This change replaces the current CI action with that one. * wasi-nn: upgrade openvino dependency to v0.4.1 This eliminates a `lazy_static` dependency and changes a few parameters to pass by reference. Importantly, it enables support for the latest versions of OpenVINO (v2022.*) in wasi-nn. * ci: update wasi-nn script to source correct env script * ci: really use the correct path for the env script Also, clarify which directory OpenVINO is installed in (the symlink may not be present).
2 years ago
"pretty_env_logger",
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "os_pipe"
externref: Address review feedback
4 years ago
version = "0.9.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
externref: Address review feedback
4 years ago
checksum = "fb233f06c2307e1f5ce2ecad9f8121cffbbee2c95428f44ea85222e460d0d213"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"libc",
"winapi",
]
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
[[package]]
name = "os_str_bytes"
version = "6.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8e22443d1643a904602595ba1cd8f7d896afe56d26712531c5ff73a15b2fbf64"
Make ISLE part of the root Cargo workspace.
3 years ago
[[package]]
name = "owo-colors"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "3.4.0"
Make ISLE part of the root Cargo workspace.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "decf7381921fea4dcb2549c5667eda59b3ec297ab7e2b5fc33eac69d2e7da87b"
Make ISLE part of the root Cargo workspace.
3 years ago
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "p256"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.9.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "d053368e1bae4c8a672953397bd1bd7183dde1c72b0b7612a15719173148d186"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"ecdsa",
"elliptic-curve",
"sha2",
]
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
[[package]]
name = "parity-wasm"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
version = "0.42.2"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
checksum = "be5e13c266502aadf83426d87d81a0f5d1ef45b8027f5a471c360abfe4bfae92"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "parking_lot"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.11.2"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "7d17b78036a60663b797adeaee46f5c9dfebb86948d1255007a1d6be0271ff99"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"instant",
"lock_api",
"parking_lot_core",
]
[[package]]
name = "parking_lot_core"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.8.5"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "d76e8e1493bcac0d2766c42737f34458f1c8c50c0d23bcb24ea953affb273216"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"instant",
"libc",
Update version for fs-set-times to 3.1
4 years ago
"redox_syscall",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"smallvec",
"winapi",
]
Implement support for `async` functions in Wasmtime (#2434) * Implement support for `async` functions in Wasmtime This is an implementation of [RFC 2] in Wasmtime which is to support `async`-defined host functions. At a high level support is added by executing WebAssembly code that might invoke an asynchronous host function on a separate native stack. When the host function's future is not ready we switch back to the main native stack to continue execution. There's a whole bunch of details in this commit, and it's a bit much to go over them all here in this commit message. The most important changes here are: * A new `wasmtime-fiber` crate has been written to manage the low-level details of stack-switching. Unixes use `mmap` to allocate a stack and Windows uses the native fibers implementation. We'll surely want to refactor this to move stack allocation elsewhere in the future. Fibers are intended to be relatively general with a lot of type paremters to fling values back and forth across suspension points. The whole crate is a giant wad of `unsafe` unfortunately and involves handwritten assembly with custom dwarf CFI directives to boot. Definitely deserves a close eye in review! * The `Store` type has two new methods -- `block_on` and `on_fiber` which bridge between the async and non-async worlds. Lots of unsafe fiddly bits here as we're trying to communicate context pointers between disparate portions of the code. Extra eyes and care in review is greatly appreciated. * The APIs for binding `async` functions are unfortunately pretty ugly in `Func`. This is mostly due to language limitations and compiler bugs (I believe) in Rust. Instead of `Func::wrap` we have a `Func::wrapN_async` family of methods, and we've also got a whole bunch of `Func::getN_async` methods now too. It may be worth rethinking the API of `Func` to try to make the documentation page actually grok'able. This isn't super heavily tested but the various test should suffice for engaging hopefully nearly all the infrastructure in one form or another. This is just the start though! [RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2 * Add wasmtime-fiber to publish script * Save vector/float registers on ARM too. * Fix a typo * Update lock file * Implement periodically yielding with fuel consumption This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures. * Fix compile without async * Save/restore the frame pointer in fiber switching Turns out this is another caller-saved register! * Simplify x86_64 fiber asm Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses. * Add x86 support to wasmtime-fiber * Add ARM32 support to fiber crate * Make fiber build file probing more flexible * Use CreateFiberEx on Windows * Remove a stray no-longer-used trait declaration * Don't reach into `Caller` internals * Tweak async fuel to eventually run out. With fuel it's probably best to not provide any way to inject infinite fuel. * Fix some typos * Cleanup asm a bit * Use a shared header file to deduplicate some directives * Guarantee hidden visibility for functions * Enable gc-sections on macOS x86_64 * Add `.type` annotations for ARM * Update lock file * Fix compile error * Review comments
4 years ago
[[package]]
name = "paste"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "1.0.7"
Implement support for `async` functions in Wasmtime (#2434) * Implement support for `async` functions in Wasmtime This is an implementation of [RFC 2] in Wasmtime which is to support `async`-defined host functions. At a high level support is added by executing WebAssembly code that might invoke an asynchronous host function on a separate native stack. When the host function's future is not ready we switch back to the main native stack to continue execution. There's a whole bunch of details in this commit, and it's a bit much to go over them all here in this commit message. The most important changes here are: * A new `wasmtime-fiber` crate has been written to manage the low-level details of stack-switching. Unixes use `mmap` to allocate a stack and Windows uses the native fibers implementation. We'll surely want to refactor this to move stack allocation elsewhere in the future. Fibers are intended to be relatively general with a lot of type paremters to fling values back and forth across suspension points. The whole crate is a giant wad of `unsafe` unfortunately and involves handwritten assembly with custom dwarf CFI directives to boot. Definitely deserves a close eye in review! * The `Store` type has two new methods -- `block_on` and `on_fiber` which bridge between the async and non-async worlds. Lots of unsafe fiddly bits here as we're trying to communicate context pointers between disparate portions of the code. Extra eyes and care in review is greatly appreciated. * The APIs for binding `async` functions are unfortunately pretty ugly in `Func`. This is mostly due to language limitations and compiler bugs (I believe) in Rust. Instead of `Func::wrap` we have a `Func::wrapN_async` family of methods, and we've also got a whole bunch of `Func::getN_async` methods now too. It may be worth rethinking the API of `Func` to try to make the documentation page actually grok'able. This isn't super heavily tested but the various test should suffice for engaging hopefully nearly all the infrastructure in one form or another. This is just the start though! [RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2 * Add wasmtime-fiber to publish script * Save vector/float registers on ARM too. * Fix a typo * Update lock file * Implement periodically yielding with fuel consumption This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures. * Fix compile without async * Save/restore the frame pointer in fiber switching Turns out this is another caller-saved register! * Simplify x86_64 fiber asm Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses. * Add x86 support to wasmtime-fiber * Add ARM32 support to fiber crate * Make fiber build file probing more flexible * Use CreateFiberEx on Windows * Remove a stray no-longer-used trait declaration * Don't reach into `Caller` internals * Tweak async fuel to eventually run out. With fuel it's probably best to not provide any way to inject infinite fuel. * Fix some typos * Cleanup asm a bit * Use a shared header file to deduplicate some directives * Guarantee hidden visibility for functions * Enable gc-sections on macOS x86_64 * Add `.type` annotations for ARM * Update lock file * Fix compile error * Review comments
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "0c520e05135d6e763148b6426a837e239041653ba7becd2e538c076c738025fc"
Implement support for `async` functions in Wasmtime (#2434) * Implement support for `async` functions in Wasmtime This is an implementation of [RFC 2] in Wasmtime which is to support `async`-defined host functions. At a high level support is added by executing WebAssembly code that might invoke an asynchronous host function on a separate native stack. When the host function's future is not ready we switch back to the main native stack to continue execution. There's a whole bunch of details in this commit, and it's a bit much to go over them all here in this commit message. The most important changes here are: * A new `wasmtime-fiber` crate has been written to manage the low-level details of stack-switching. Unixes use `mmap` to allocate a stack and Windows uses the native fibers implementation. We'll surely want to refactor this to move stack allocation elsewhere in the future. Fibers are intended to be relatively general with a lot of type paremters to fling values back and forth across suspension points. The whole crate is a giant wad of `unsafe` unfortunately and involves handwritten assembly with custom dwarf CFI directives to boot. Definitely deserves a close eye in review! * The `Store` type has two new methods -- `block_on` and `on_fiber` which bridge between the async and non-async worlds. Lots of unsafe fiddly bits here as we're trying to communicate context pointers between disparate portions of the code. Extra eyes and care in review is greatly appreciated. * The APIs for binding `async` functions are unfortunately pretty ugly in `Func`. This is mostly due to language limitations and compiler bugs (I believe) in Rust. Instead of `Func::wrap` we have a `Func::wrapN_async` family of methods, and we've also got a whole bunch of `Func::getN_async` methods now too. It may be worth rethinking the API of `Func` to try to make the documentation page actually grok'able. This isn't super heavily tested but the various test should suffice for engaging hopefully nearly all the infrastructure in one form or another. This is just the start though! [RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2 * Add wasmtime-fiber to publish script * Save vector/float registers on ARM too. * Fix a typo * Update lock file * Implement periodically yielding with fuel consumption This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures. * Fix compile without async * Save/restore the frame pointer in fiber switching Turns out this is another caller-saved register! * Simplify x86_64 fiber asm Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses. * Add x86 support to wasmtime-fiber * Add ARM32 support to fiber crate * Make fiber build file probing more flexible * Use CreateFiberEx on Windows * Remove a stray no-longer-used trait declaration * Don't reach into `Caller` internals * Tweak async fuel to eventually run out. With fuel it's probably best to not provide any way to inject infinite fuel. * Fix some typos * Cleanup asm a bit * Use a shared header file to deduplicate some directives * Guarantee hidden visibility for functions * Enable gc-sections on macOS x86_64 * Add `.type` annotations for ARM * Update lock file * Fix compile error * Review comments
4 years ago
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
name = "pem-rfc7468"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.2.4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "84e93a3b1cc0510b03020f33f21e62acdde3dcaef432edc95bea377fbd4c2cd4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"base64ct",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
]
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
[[package]]
name = "pin-project-lite"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.9"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "e0a7ae3ac2f1173085d398531c705756c94a4c56843785df85a60c1a0afac116"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
[[package]]
name = "pkcs1"
version = "0.2.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "116bee8279d783c0cf370efa1a94632f2108e5ef0bb32df31f051647810a4e2c"
dependencies = [
"der",
"pem-rfc7468",
"zeroize",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "pkcs8"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.7.6"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "ee3ef9b64d26bad0536099c816c6734379e45bbd5f14798def6809e5cc350447"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"der",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"pem-rfc7468",
"pkcs1",
"spki",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"zeroize",
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "plotters"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "0.3.1"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "32a3fd9ec30b9749ce28cd91f255d569591cdf937fe280c312143e3c4bad6f2a"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"num-traits",
"plotters-backend",
"plotters-svg",
"wasm-bindgen",
"web-sys",
]
[[package]]
name = "plotters-backend"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.3.2"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "d88417318da0eaf0fdcdb51a0ee6c3bed624333bff8f946733049380be67ac1c"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "plotters-svg"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.3.1"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "521fa9638fa597e1dc53e9412a4f9cefb01187ee1f7413076f9e6749e2885ba9"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"plotters-backend",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "poly1305"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.7.2"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "048aeb476be11a4b6ca432ca569e375810de9294ae78f4774e78ea98a9246ede"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
ISLE: guard against stale generated source in default build config. Currently, the `build.rs` script that generates Rust source from the ISLE DSL will only do this generation if the `rebuild-isle` Cargo feature is specified. By default, it is not. This is based on the principle that we (the build script) do not modify the source tree as managed by git; git-managed files are strictly a human-managed and human-edited resource. By adding the opt-in Cargo feature, a developer is requesting the build script to perform an explicit action. (In my understanding at least, this principle comes from the general philosophy of hermetic builds: the output should be a pure function of the input, and part of this is that the input is read-only. If we modify the source tree, then all bets are off.) Unfortunately, requiring the opt-in feature also creates a footgun that is easy to hit: if a developer modifies the ISLE DSL source, but forgets to specify the Cargo feature, then the compiler will silently be built successfully with stale source, and will silently exclude any changes that were made. The generated source is checked into git for a good reason: we want DSL compiler to not affect build times for the overwhelmingly common case that Cranelift is used as a dependency but the backends are not being actively developed. (This overhead comes mainly from building `islec` itself.) So, what to do? This PR implements a middle ground first described in [this conversation](https://github.com/bytecodealliance/wasmtime/pull/3506#discussion_r743113351), in which we: - Generate a hash (SHA-512) of the ISLE DSL source and produce a "manifest" of ISLE inputs alongside the generated source; and - Always read the ISLE DSL source, and see if the manifest is still valid, on builds that do not have the opt-in "rebuild" feature. This allows us to know whether the ISLE compiler output would have been the same (modulo changes to the DSL compiler itself, which are out-of-scope here), without actually building the ISLE compiler and running it. If the compiler-backend developer modifies an ISLE source file and then tries to build `cranelift-codegen` without adding the `rebuild-isle` Cargo feature, they get the following output: ```text Error: the ISLE source files that resulted in the generated Rust source * src/isa/x64/lower/isle/generated_code.rs have changed but the generated source was not rebuilt! These ISLE source files are: * src/clif.isle * src/prelude.isle * src/isa/x64/inst.isle * src/isa/x64/lower.isle Please add `--features rebuild-isle` to your `cargo build` command if you wish to rebuild the generated source, then include these changes in any git commits you make that include the changes to the ISLE. For example: $ cargo build -p cranelift-codegen --features rebuild-isle (This build script cannot do this for you by default because we cannot modify checked-into-git source without your explicit opt-in.) ``` which will tell them exactly what they need to do to fix the problem! Note that I am leaving the "Rebuild ISLE" CI job alone for now, because otherwise, we are trusting whomever submits a PR to generate the correct generated source. In other words, the manifest is a communication from the checked-in tree to the developer, but we still need to verify that the checked-in generated Rust source and the manifest are correct with respect to the checked-in ISLE source.
3 years ago
"cpufeatures",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"opaque-debug",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"universal-hash",
]
[[package]]
name = "polyval"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.5.3"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "8419d2b623c7c0896ff2d5d96e2cb4ede590fed28fcc34934f4c33c036e620a1"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
ISLE: guard against stale generated source in default build config. Currently, the `build.rs` script that generates Rust source from the ISLE DSL will only do this generation if the `rebuild-isle` Cargo feature is specified. By default, it is not. This is based on the principle that we (the build script) do not modify the source tree as managed by git; git-managed files are strictly a human-managed and human-edited resource. By adding the opt-in Cargo feature, a developer is requesting the build script to perform an explicit action. (In my understanding at least, this principle comes from the general philosophy of hermetic builds: the output should be a pure function of the input, and part of this is that the input is read-only. If we modify the source tree, then all bets are off.) Unfortunately, requiring the opt-in feature also creates a footgun that is easy to hit: if a developer modifies the ISLE DSL source, but forgets to specify the Cargo feature, then the compiler will silently be built successfully with stale source, and will silently exclude any changes that were made. The generated source is checked into git for a good reason: we want DSL compiler to not affect build times for the overwhelmingly common case that Cranelift is used as a dependency but the backends are not being actively developed. (This overhead comes mainly from building `islec` itself.) So, what to do? This PR implements a middle ground first described in [this conversation](https://github.com/bytecodealliance/wasmtime/pull/3506#discussion_r743113351), in which we: - Generate a hash (SHA-512) of the ISLE DSL source and produce a "manifest" of ISLE inputs alongside the generated source; and - Always read the ISLE DSL source, and see if the manifest is still valid, on builds that do not have the opt-in "rebuild" feature. This allows us to know whether the ISLE compiler output would have been the same (modulo changes to the DSL compiler itself, which are out-of-scope here), without actually building the ISLE compiler and running it. If the compiler-backend developer modifies an ISLE source file and then tries to build `cranelift-codegen` without adding the `rebuild-isle` Cargo feature, they get the following output: ```text Error: the ISLE source files that resulted in the generated Rust source * src/isa/x64/lower/isle/generated_code.rs have changed but the generated source was not rebuilt! These ISLE source files are: * src/clif.isle * src/prelude.isle * src/isa/x64/inst.isle * src/isa/x64/lower.isle Please add `--features rebuild-isle` to your `cargo build` command if you wish to rebuild the generated source, then include these changes in any git commits you make that include the changes to the ISLE. For example: $ cargo build -p cranelift-codegen --features rebuild-isle (This build script cannot do this for you by default because we cannot modify checked-into-git source without your explicit opt-in.) ``` which will tell them exactly what they need to do to fix the problem! Note that I am leaving the "Rebuild ISLE" CI job alone for now, because otherwise, we are trusting whomever submits a PR to generate the correct generated source. In other words, the manifest is a communication from the checked-in tree to the developer, but we still need to verify that the checked-in generated Rust source and the manifest are correct with respect to the checked-in ISLE source.
3 years ago
"cpufeatures",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"opaque-debug",
"universal-hash",
]
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "ppv-lite86"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.2.16"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "eb9f9e6e233e5c4a35559a617bf40a4ec447db2e84c20b55a6f83167b7e57872"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "pqcrypto"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.14.2"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "9da39bd0587bff4189521766c34f3203263926f7527906578a96d22a81a700d5"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"pqcrypto-kyber",
"pqcrypto-traits",
]
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
[[package]]
name = "pqcrypto-internals"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.4"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "0127cbc0239f585139a56effd7867921eae3425a000a72dde2b0a156062346b2"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
dependencies = [
"cc",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"dunce",
"getrandom 0.2.6",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"libc",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "pqcrypto-kyber"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.7.5"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "8a17989a978f7d7c1496e38806ad9ff11f36eb8e419c562eafddbbf176af4a8a"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"cc",
"glob",
"libc",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"pqcrypto-internals",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"pqcrypto-traits",
]
[[package]]
name = "pqcrypto-traits"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.3.4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "97e91cb6af081c6daad5fa705f8adb0634c027662052cb3174bdf2957bf07e25"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
[[package]]
name = "pretty_env_logger"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "926d36b9553851b8b0005f1275891b392ee4d2d833852c417ed025477350fb9d"
dependencies = [
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
"env_logger 0.7.1",
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
"log",
]
Use structopt instead of docopt. This commit refactors the Wasmtime CLI tools to use `structopt` instead of `docopt`. The `wasmtime` tool now has the following subcommands: * `config new` - creates a new Wasmtime configuration file. * `run` - runs a WebAssembly module. * `wasm2obj` - translates a Wasm module to native object file. * `wast` - runs a test script file. If no subcommand is specified, the `run` subcommand is used. Thus, `wasmtime foo.wasm` should continue to function as expected. The `wasm2obj` and `wast` tools still exist, but delegate to the same implementation as the `wasmtime` subcommands. The standalone `wasm2obj` and `wast` tools may be removed in the future in favor of simply using `wasmtime`. Included in this commit is a breaking change to the default Wasmtime configuration file: it has been renamed from `wasmtime-cache-config.toml` to simply `config.toml`. The new name is less specific which will allow for additional (non-cache-related) settings in the future. There are some breaking changes to improve command line UX: * The `--cache-config` option has been renamed to `--config`. * The `--create-config-file` option has moved to the `config new` subcommand. As a result, the `wasm2obj` and `wast` tools cannot be used to create a new config file. * The short form of the `--optimize` option has changed from `-o` to `-O` for consistency. * The `wasm2obj` command takes the output object file as a required positional argument rather than the former required output *option* (e.g. `wasmtime wasm2obj foo.wasm foo.obj`).
5 years ago
[[package]]
name = "proc-macro-error"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
version = "1.0.4"
Use structopt instead of docopt. This commit refactors the Wasmtime CLI tools to use `structopt` instead of `docopt`. The `wasmtime` tool now has the following subcommands: * `config new` - creates a new Wasmtime configuration file. * `run` - runs a WebAssembly module. * `wasm2obj` - translates a Wasm module to native object file. * `wast` - runs a test script file. If no subcommand is specified, the `run` subcommand is used. Thus, `wasmtime foo.wasm` should continue to function as expected. The `wasm2obj` and `wast` tools still exist, but delegate to the same implementation as the `wasmtime` subcommands. The standalone `wasm2obj` and `wast` tools may be removed in the future in favor of simply using `wasmtime`. Included in this commit is a breaking change to the default Wasmtime configuration file: it has been renamed from `wasmtime-cache-config.toml` to simply `config.toml`. The new name is less specific which will allow for additional (non-cache-related) settings in the future. There are some breaking changes to improve command line UX: * The `--cache-config` option has been renamed to `--config`. * The `--create-config-file` option has moved to the `config new` subcommand. As a result, the `wasm2obj` and `wast` tools cannot be used to create a new config file. * The short form of the `--optimize` option has changed from `-o` to `-O` for consistency. * The `wasm2obj` command takes the output object file as a required positional argument rather than the former required output *option* (e.g. `wasmtime wasm2obj foo.wasm foo.obj`).
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
checksum = "da25490ff9892aab3fcf7c36f08cfb902dd3e71ca0f9f9517bea02a73a5ce38c"
Use structopt instead of docopt. This commit refactors the Wasmtime CLI tools to use `structopt` instead of `docopt`. The `wasmtime` tool now has the following subcommands: * `config new` - creates a new Wasmtime configuration file. * `run` - runs a WebAssembly module. * `wasm2obj` - translates a Wasm module to native object file. * `wast` - runs a test script file. If no subcommand is specified, the `run` subcommand is used. Thus, `wasmtime foo.wasm` should continue to function as expected. The `wasm2obj` and `wast` tools still exist, but delegate to the same implementation as the `wasmtime` subcommands. The standalone `wasm2obj` and `wast` tools may be removed in the future in favor of simply using `wasmtime`. Included in this commit is a breaking change to the default Wasmtime configuration file: it has been renamed from `wasmtime-cache-config.toml` to simply `config.toml`. The new name is less specific which will allow for additional (non-cache-related) settings in the future. There are some breaking changes to improve command line UX: * The `--cache-config` option has been renamed to `--config`. * The `--create-config-file` option has moved to the `config new` subcommand. As a result, the `wasm2obj` and `wast` tools cannot be used to create a new config file. * The short form of the `--optimize` option has changed from `-o` to `-O` for consistency. * The `wasm2obj` command takes the output object file as a required positional argument rather than the former required output *option* (e.g. `wasmtime wasm2obj foo.wasm foo.obj`).
5 years ago
dependencies = [
Bump version to 0.9.0 (#790)
5 years ago
"proc-macro-error-attr",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"proc-macro2",
"quote",
"syn",
Wasmtime 0.13.0 and Cranelift 0.61.0. (#1398) This also updates the publishing scripts to work with newly added and reorganized crates.
5 years ago
"version_check",
Use structopt instead of docopt. This commit refactors the Wasmtime CLI tools to use `structopt` instead of `docopt`. The `wasmtime` tool now has the following subcommands: * `config new` - creates a new Wasmtime configuration file. * `run` - runs a WebAssembly module. * `wasm2obj` - translates a Wasm module to native object file. * `wast` - runs a test script file. If no subcommand is specified, the `run` subcommand is used. Thus, `wasmtime foo.wasm` should continue to function as expected. The `wasm2obj` and `wast` tools still exist, but delegate to the same implementation as the `wasmtime` subcommands. The standalone `wasm2obj` and `wast` tools may be removed in the future in favor of simply using `wasmtime`. Included in this commit is a breaking change to the default Wasmtime configuration file: it has been renamed from `wasmtime-cache-config.toml` to simply `config.toml`. The new name is less specific which will allow for additional (non-cache-related) settings in the future. There are some breaking changes to improve command line UX: * The `--cache-config` option has been renamed to `--config`. * The `--create-config-file` option has moved to the `config new` subcommand. As a result, the `wasm2obj` and `wast` tools cannot be used to create a new config file. * The short form of the `--optimize` option has changed from `-o` to `-O` for consistency. * The `wasm2obj` command takes the output object file as a required positional argument rather than the former required output *option* (e.g. `wasmtime wasm2obj foo.wasm foo.obj`).
5 years ago
]
Bump version to 0.9.0 (#790)
5 years ago
[[package]]
name = "proc-macro-error-attr"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
version = "1.0.4"
Bump version to 0.9.0 (#790)
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
checksum = "a1be40180e52ecc98ad80b184934baf3d0d29f979574e439af5a55274b35f869"
Bump version to 0.9.0 (#790)
5 years ago
dependencies = [
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"proc-macro2",
"quote",
Wasmtime 0.13.0 and Cranelift 0.61.0. (#1398) This also updates the publishing scripts to work with newly added and reorganized crates.
5 years ago
"version_check",
Bump version to 0.9.0 (#790)
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "proc-macro2"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "1.0.37"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "ec757218438d5fda206afc041538b2f6d889286160d649a86a24d37e1235afd1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"unicode-xid",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Fix wiggle's tests
5 years ago
[[package]]
name = "proptest"
Bump dependencies to get a single version of rand (#2733) This removes a few crates in the dependencies, and a few exceptions (at the price of a new one) in the cargo-deny configuration.
4 years ago
version = "1.0.0"
Fix wiggle's tests
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Bump dependencies to get a single version of rand (#2733) This removes a few crates in the dependencies, and a few exceptions (at the price of a new one) in the cargo-deny configuration.
4 years ago
checksum = "1e0d9cc07f18492d879586c92b485def06bc850da3118075cd45d50e9c95b0e5"
Fix wiggle's tests
5 years ago
dependencies = [
"bit-set",
"bitflags",
"byteorder",
"lazy_static",
"num-traits",
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
"quick-error 2.0.1",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"rand 0.8.5",
"rand_chacha 0.3.1",
Fix wiggle's tests
5 years ago
"rand_xorshift",
"regex-syntax",
"rusty-fork",
"tempfile",
]
Use the `psm` crate to figure out the current stack pointer (#2358) Currently the runtime needs to acquire the current stack pointer so it can set a limit for where if the wasm stack goes below that point it will abort the wasm code. Acquiring the stack pointer is done in a brittle way right now which involves looking at the address of what we hope is an on-stack structure. This turns out to not work at all with ASan as well. Instead this commit switches to the `psm` crate which is used by the Rust compiler team for stack manipulation, namely a coarse version of segmented stacks to avoid stack overflow in the compiler. We don't need most of the implementation of `psm`, just the `stack_pointer` function, but it shouldn't be a burden to bring in! Closes #2344
4 years ago
[[package]]
name = "psm"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.1.18"
Use the `psm` crate to figure out the current stack pointer (#2358) Currently the runtime needs to acquire the current stack pointer so it can set a limit for where if the wasm stack goes below that point it will abort the wasm code. Acquiring the stack pointer is done in a brittle way right now which involves looking at the address of what we hope is an on-stack structure. This turns out to not work at all with ASan as well. Instead this commit switches to the `psm` crate which is used by the Rust compiler team for stack manipulation, namely a coarse version of segmented stacks to avoid stack overflow in the compiler. We don't need most of the implementation of `psm`, just the `stack_pointer` function, but it shouldn't be a burden to bring in! Closes #2344
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "871372391786ccec00d3c5d3d6608905b3d4db263639cfe075d3b60a736d115a"
Use the `psm` crate to figure out the current stack pointer (#2358) Currently the runtime needs to acquire the current stack pointer so it can set a limit for where if the wasm stack goes below that point it will abort the wasm code. Acquiring the stack pointer is done in a brittle way right now which involves looking at the address of what we hope is an on-stack structure. This turns out to not work at all with ASan as well. Instead this commit switches to the `psm` crate which is used by the Rust compiler team for stack manipulation, namely a coarse version of segmented stacks to avoid stack overflow in the compiler. We don't need most of the implementation of `psm`, just the `stack_pointer` function, but it shouldn't be a burden to bring in! Closes #2344
4 years ago
dependencies = [
"cc",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "quick-error"
Bump version to 0.9.0 (#790)
5 years ago
version = "1.2.3"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Bump version to 0.9.0 (#790)
5 years ago
checksum = "a1d01941d82fa2ab50be1e79e6714289dd7cde78eba4c074bc5a4374f650dfe0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Bump dependencies to get a single version of rand (#2733) This removes a few crates in the dependencies, and a few exceptions (at the price of a new one) in the cargo-deny configuration.
4 years ago
[[package]]
name = "quick-error"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "2.0.1"
Bump dependencies to get a single version of rand (#2733) This removes a few crates in the dependencies, and a few exceptions (at the price of a new one) in the cargo-deny configuration.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "a993555f31e5a609f617c12db6250dedcac1b0a85076912c436e6fc9b2c8e6a3"
Bump dependencies to get a single version of rand (#2733) This removes a few crates in the dependencies, and a few exceptions (at the price of a new one) in the cargo-deny configuration.
4 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "quote"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "1.0.18"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "a1feb54ed693b93a84e14094943b84b7c4eae204c512b7ccb95ab0c66d278ad1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"proc-macro2",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "rand"
Run `cargo update` on dependencies (#868) Looks like we're able to actually drop a good number of various deps, especially some large-ish ones like syn 0.14! Adding proc-macro2 v1.0.8 Adding syn v1.0.14 Removing base64 v0.10.1 Removing cloudabi v0.0.3 Removing crossbeam-utils v0.6.6 Removing failure v0.1.6 Removing failure_derive v0.1.6 Removing fuchsia-cprng v0.1.1 Removing proc-macro2 v0.4.30 Removing proc-macro2 v1.0.7 Removing quote v0.6.13 Removing rand_core v0.3.1 Removing rand_core v0.4.2 Removing rand_os v0.1.3 Removing rdrand v0.4.0 Removing syn v0.14.9 Removing syn v1.0.13 Removing synstructure v0.9.0 Removing unicode-xid v0.1.0 Removing wincolor v1.0.2 Updating arbitrary v0.3.2 -> v0.3.3 Updating arrayref v0.3.5 -> v0.3.6 Updating constant_time_eq v0.1.4 -> v0.1.5 Updating crates.io index Updating derive_arbitrary v0.3.1 -> v0.3.3 Updating indexmap v1.3.0 -> v1.3.1 Updating itoa v0.4.4 -> v0.4.5 Updating jobserver v0.1.18 -> v0.1.19 Updating memchr v2.2.1 -> v2.3.0 Updating num_cpus v1.11.1 -> v1.12.0 Updating proc-macro-error v0.4.4 -> v0.4.5 Updating proc-macro-error-attr v0.4.3 -> v0.4.5 Updating quickcheck v0.9.0 -> v0.9.2 Updating rand v0.7.2 -> v0.7.3 Updating redox_users v0.3.1 -> v0.3.4 Updating rust-argon2 v0.5.1 -> v0.7.0 Updating rustversion v1.0.1 -> v1.0.2 Updating serde_json v1.0.44 -> v1.0.45 Updating structopt v0.3.7 -> v0.3.8 Updating structopt-derive v0.4.0 -> v0.4.1 Updating termcolor v1.0.5 -> v1.1.0 Updating thread_local v1.0.0 -> v1.0.1 Updating toml v0.5.5 -> v0.5.6 Updating winapi-util v0.1.2 -> v0.1.3
5 years ago
version = "0.7.3"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Run `cargo update` on dependencies (#868) Looks like we're able to actually drop a good number of various deps, especially some large-ish ones like syn 0.14! Adding proc-macro2 v1.0.8 Adding syn v1.0.14 Removing base64 v0.10.1 Removing cloudabi v0.0.3 Removing crossbeam-utils v0.6.6 Removing failure v0.1.6 Removing failure_derive v0.1.6 Removing fuchsia-cprng v0.1.1 Removing proc-macro2 v0.4.30 Removing proc-macro2 v1.0.7 Removing quote v0.6.13 Removing rand_core v0.3.1 Removing rand_core v0.4.2 Removing rand_os v0.1.3 Removing rdrand v0.4.0 Removing syn v0.14.9 Removing syn v1.0.13 Removing synstructure v0.9.0 Removing unicode-xid v0.1.0 Removing wincolor v1.0.2 Updating arbitrary v0.3.2 -> v0.3.3 Updating arrayref v0.3.5 -> v0.3.6 Updating constant_time_eq v0.1.4 -> v0.1.5 Updating crates.io index Updating derive_arbitrary v0.3.1 -> v0.3.3 Updating indexmap v1.3.0 -> v1.3.1 Updating itoa v0.4.4 -> v0.4.5 Updating jobserver v0.1.18 -> v0.1.19 Updating memchr v2.2.1 -> v2.3.0 Updating num_cpus v1.11.1 -> v1.12.0 Updating proc-macro-error v0.4.4 -> v0.4.5 Updating proc-macro-error-attr v0.4.3 -> v0.4.5 Updating quickcheck v0.9.0 -> v0.9.2 Updating rand v0.7.2 -> v0.7.3 Updating redox_users v0.3.1 -> v0.3.4 Updating rust-argon2 v0.5.1 -> v0.7.0 Updating rustversion v1.0.1 -> v1.0.2 Updating serde_json v1.0.44 -> v1.0.45 Updating structopt v0.3.7 -> v0.3.8 Updating structopt-derive v0.4.0 -> v0.4.1 Updating termcolor v1.0.5 -> v1.1.0 Updating thread_local v1.0.0 -> v1.0.1 Updating toml v0.5.5 -> v0.5.6 Updating winapi-util v0.1.2 -> v0.1.3
5 years ago
checksum = "6a6b1679d49b24bbfe0c803429aa1874472f50d9b363131f0e89fc356b544d03"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"getrandom 0.1.16",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"libc",
upgrade to cap-std 0.9
4 years ago
"rand_chacha 0.2.2",
"rand_core 0.5.1",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"rand_hc",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
upgrade to cap-std 0.9
4 years ago
[[package]]
name = "rand"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.8.5"
upgrade to cap-std 0.9
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "34af8d1a0e25924bc5b7c43c079c942339d8f0a8b57c39049bef581b46327404"
upgrade to cap-std 0.9
4 years ago
dependencies = [
"libc",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"rand_chacha 0.3.1",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"rand_core 0.6.3",
upgrade to cap-std 0.9
4 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "rand_chacha"
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
version = "0.2.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
checksum = "f4c8ed856279c9737206bf725bf36935d8666ead7aa69b52be55af369d193402"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update a number of wasmtime's dependencies (#1355) * Run `cargo update` * Use `cargo outdated` to guide some manual version bumps
5 years ago
"ppv-lite86",
upgrade to cap-std 0.9
4 years ago
"rand_core 0.5.1",
]
[[package]]
name = "rand_chacha"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.3.1"
upgrade to cap-std 0.9
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "e6c10a63a0fa32252be49d21e7709d4d4baf8d231c2dbce1eaa8141b9b127d88"
upgrade to cap-std 0.9
4 years ago
dependencies = [
"ppv-lite86",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"rand_core 0.6.3",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "rand_core"
version = "0.5.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "90bde5296fc891b0cef12a6d03ddccc162ce7b2aff54160af9338f8d40df6d19"
dependencies = [
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"getrandom 0.1.16",
Fix wiggle's tests
5 years ago
]
upgrade to cap-std 0.9
4 years ago
[[package]]
name = "rand_core"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.6.3"
upgrade to cap-std 0.9
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "d34f1408f55294453790c48b2f1ebbb1c5b4b7563eb1f418bcfcfdbb06ebb4e7"
upgrade to cap-std 0.9
4 years ago
dependencies = [
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"getrandom 0.2.6",
upgrade to cap-std 0.9
4 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "rand_hc"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ca3129af7b92a17112d59ad498c6f81eaf463253766b90396d39ea7a39d6613c"
dependencies = [
upgrade to cap-std 0.9
4 years ago
"rand_core 0.5.1",
]
Fix wiggle's tests
5 years ago
[[package]]
name = "rand_xorshift"
Bump dependencies to get a single version of rand (#2733) This removes a few crates in the dependencies, and a few exceptions (at the price of a new one) in the cargo-deny configuration.
4 years ago
version = "0.3.0"
Fix wiggle's tests
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Bump dependencies to get a single version of rand (#2733) This removes a few crates in the dependencies, and a few exceptions (at the price of a new one) in the cargo-deny configuration.
4 years ago
checksum = "d25bf25ec5ae4a3f1b92f929810509a2f53d7dca2f50b794ff57e3face536c8f"
Fix wiggle's tests
5 years ago
dependencies = [
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"rand_core 0.6.3",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
name = "rawbytes"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "04d0088f16afb86d12c7f239d8de4637fa68ecc99a3db227e1ab58a294713e60"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "rayon"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "1.5.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "fd249e82c21598a9a426a4e00dd7adc1d640b22445ec8545feef801d1a74c221"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"autocfg 1.1.0",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"crossbeam-deque",
"either",
"rayon-core",
]
[[package]]
name = "rayon-core"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "1.9.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "9f51245e1e62e1f1629cbfec37b5793bbabcaeb90f30e94d2ba03564687353e4"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
"crossbeam-channel",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"crossbeam-deque",
cargo update
4 years ago
"crossbeam-utils",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"num_cpus",
]
[[package]]
name = "redox_syscall"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.13"
latest system-interface
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "62f25bc4c7e55e0b0b7a1d43fb893f4fa1361d0abe38b9ce4f323c2adfe6ef42"
latest system-interface
4 years ago
dependencies = [
"bitflags",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "redox_users"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.4.3"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "b033d837a7cf162d7993aded9304e30a83213c648b6e389db233191f891e5c2b"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"getrandom 0.2.6",
Update version for fs-set-times to 3.1
4 years ago
"redox_syscall",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"thiserror",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
]
ARM64 backend, part 3 / 11: MachInst infrastructure. This patch adds the MachInst, or Machine Instruction, infrastructure. This is the machine-independent portion of the new backend design. It contains the implementation of the "vcode" (virtual-registerized code) container, the top-level lowering algorithm and compilation pipeline, and the trait definitions that the machine backends will fill in. This backend infrastructure is included in the compilation of the `codegen` crate, but it is not yet tied into the public APIs; that patch will come last, after all the other pieces are filled in. This patch contains code written by Julian Seward <jseward@acm.org> and Benjamin Bouvier <public@benj.me>, originally developed on a side-branch before rebasing and condensing into this patch series. See the `arm64` branch at `https://github.com/cfallin/wasmtime` for original development history. Co-authored-by: Julian Seward <jseward@acm.org> Co-authored-by: Benjamin Bouvier <public@benj.me>
5 years ago
[[package]]
Switch Cranelift over to regalloc2. (#3989) This PR switches Cranelift over to the new register allocator, regalloc2. See [this document](https://gist.github.com/cfallin/08553421a91f150254fe878f67301801) for a summary of the design changes. This switchover has implications for core VCode/MachInst types and the lowering pass. Overall, this change brings improvements to both compile time and speed of generated code (runtime), as reported in #3942: ``` Benchmark Compilation (wallclock) Execution (wallclock) blake3-scalar 25% faster 28% faster blake3-simd no diff no diff meshoptimizer 19% faster 17% faster pulldown-cmark 17% faster no diff bz2 15% faster no diff SpiderMonkey, 21% faster 2% faster fib(30) clang.wasm 42% faster N/A ```
3 years ago
name = "regalloc2"
Upgrade to regalloc2 0.4.1. (#4945) * Upgrade to regalloc2 0.4.1. Incorporates bytecodealliance/regalloc2#85, which fixes a fuzzbug related to constraints and liverange splits. * Add audit of regalloc2 upgrade.
2 years ago
version = "0.4.1"
ARM64 backend, part 3 / 11: MachInst infrastructure. This patch adds the MachInst, or Machine Instruction, infrastructure. This is the machine-independent portion of the new backend design. It contains the implementation of the "vcode" (virtual-registerized code) container, the top-level lowering algorithm and compilation pipeline, and the trait definitions that the machine backends will fill in. This backend infrastructure is included in the compilation of the `codegen` crate, but it is not yet tied into the public APIs; that patch will come last, after all the other pieces are filled in. This patch contains code written by Julian Seward <jseward@acm.org> and Benjamin Bouvier <public@benj.me>, originally developed on a side-branch before rebasing and condensing into this patch series. See the `arm64` branch at `https://github.com/cfallin/wasmtime` for original development history. Co-authored-by: Julian Seward <jseward@acm.org> Co-authored-by: Benjamin Bouvier <public@benj.me>
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Upgrade to regalloc2 0.4.1. (#4945) * Upgrade to regalloc2 0.4.1. Incorporates bytecodealliance/regalloc2#85, which fixes a fuzzbug related to constraints and liverange splits. * Add audit of regalloc2 upgrade.
2 years ago
checksum = "69025b4a161879ba90719837c06621c3d73cffa147a000aeacf458f6a9572485"
ARM64 backend, part 3 / 11: MachInst infrastructure. This patch adds the MachInst, or Machine Instruction, infrastructure. This is the machine-independent portion of the new backend design. It contains the implementation of the "vcode" (virtual-registerized code) container, the top-level lowering algorithm and compilation pipeline, and the trait definitions that the machine backends will fill in. This backend infrastructure is included in the compilation of the `codegen` crate, but it is not yet tied into the public APIs; that patch will come last, after all the other pieces are filled in. This patch contains code written by Julian Seward <jseward@acm.org> and Benjamin Bouvier <public@benj.me>, originally developed on a side-branch before rebasing and condensing into this patch series. See the `arm64` branch at `https://github.com/cfallin/wasmtime` for original development history. Co-authored-by: Julian Seward <jseward@acm.org> Co-authored-by: Benjamin Bouvier <public@benj.me>
5 years ago
dependencies = [
Switch Cranelift over to regalloc2. (#3989) This PR switches Cranelift over to the new register allocator, regalloc2. See [this document](https://gist.github.com/cfallin/08553421a91f150254fe878f67301801) for a summary of the design changes. This switchover has implications for core VCode/MachInst types and the lowering pass. Overall, this change brings improvements to both compile time and speed of generated code (runtime), as reported in #3942: ``` Benchmark Compilation (wallclock) Execution (wallclock) blake3-scalar 25% faster 28% faster blake3-simd no diff no diff meshoptimizer 19% faster 17% faster pulldown-cmark 17% faster no diff bz2 15% faster no diff SpiderMonkey, 21% faster 2% faster fib(30) clang.wasm 42% faster N/A ```
3 years ago
"fxhash",
ARM64 backend, part 3 / 11: MachInst infrastructure. This patch adds the MachInst, or Machine Instruction, infrastructure. This is the machine-independent portion of the new backend design. It contains the implementation of the "vcode" (virtual-registerized code) container, the top-level lowering algorithm and compilation pipeline, and the trait definitions that the machine backends will fill in. This backend infrastructure is included in the compilation of the `codegen` crate, but it is not yet tied into the public APIs; that patch will come last, after all the other pieces are filled in. This patch contains code written by Julian Seward <jseward@acm.org> and Benjamin Bouvier <public@benj.me>, originally developed on a side-branch before rebasing and condensing into this patch series. See the `arm64` branch at `https://github.com/cfallin/wasmtime` for original development history. Co-authored-by: Julian Seward <jseward@acm.org> Co-authored-by: Benjamin Bouvier <public@benj.me>
5 years ago
"log",
mach backend: allow snapshotting IR graphs with the SNAPSHOT_REGALLOC env variable; This also requires the serde feature, which isn't enabled by default, thus it must be passed as a command-line argument to cargo.
4 years ago
"serde",
Switch Cranelift over to regalloc2. (#3989) This PR switches Cranelift over to the new register allocator, regalloc2. See [this document](https://gist.github.com/cfallin/08553421a91f150254fe878f67301801) for a summary of the design changes. This switchover has implications for core VCode/MachInst types and the lowering pass. Overall, this change brings improvements to both compile time and speed of generated code (runtime), as reported in #3942: ``` Benchmark Compilation (wallclock) Execution (wallclock) blake3-scalar 25% faster 28% faster blake3-simd no diff no diff meshoptimizer 19% faster 17% faster pulldown-cmark 17% faster no diff bz2 15% faster no diff SpiderMonkey, 21% faster 2% faster fib(30) clang.wasm 42% faster N/A ```
3 years ago
"slice-group-by",
MachInst backend: pass through SourceLoc information. This change adds SourceLoc information per instruction in a `VCode<Inst>` container, and keeps this information up-to-date across register allocation and branch reordering. The information is initially collected during instruction lowering, eventually collected on the MachSection, and finally provided to the environment that wraps the codegen crate for wasmtime.
5 years ago
"smallvec",
ARM64 backend, part 3 / 11: MachInst infrastructure. This patch adds the MachInst, or Machine Instruction, infrastructure. This is the machine-independent portion of the new backend design. It contains the implementation of the "vcode" (virtual-registerized code) container, the top-level lowering algorithm and compilation pipeline, and the trait definitions that the machine backends will fill in. This backend infrastructure is included in the compilation of the `codegen` crate, but it is not yet tied into the public APIs; that patch will come last, after all the other pieces are filled in. This patch contains code written by Julian Seward <jseward@acm.org> and Benjamin Bouvier <public@benj.me>, originally developed on a side-branch before rebasing and condensing into this patch series. See the `arm64` branch at `https://github.com/cfallin/wasmtime` for original development history. Co-authored-by: Julian Seward <jseward@acm.org> Co-authored-by: Benjamin Bouvier <public@benj.me>
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "regex"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "1.5.5"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "1a11647b6b25ff05a515cb92c365cec08801e83423a235b51e231e1808747286"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"aho-corasick",
"memchr",
"regex-syntax",
]
wiggle: can swap in `tracing` for args
5 years ago
[[package]]
name = "regex-automata"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "0.1.10"
wiggle: can swap in `tracing` for args
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "6c230d73fb8d8c1b9c0b3135c5142a8acee3a0558fb8db5cf1cb65f8d7862132"
wiggle: can swap in `tracing` for args
5 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "regex-syntax"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "0.6.25"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "f497285884f3fcff424ffc933e56d7cbca511def0c9831a7f9b5f6153e3cc89b"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "region"
externref: Address review feedback
4 years ago
version = "2.2.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
externref: Address review feedback
4 years ago
checksum = "877e54ea2adcd70d80e9179344c97f93ef0dffd6b03e1f4529e6e83ab2fa9ae0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"bitflags",
"libc",
"mach",
"winapi",
]
[[package]]
name = "remove_dir_all"
externref: Address review feedback
4 years ago
version = "0.5.3"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
externref: Address review feedback
4 years ago
checksum = "3acd125665422973a33ac9d3dd2df85edad0f4ae9b00dafb1a05e43a9f5ef8e7"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"winapi",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "rsa"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.5.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
checksum = "e05c2603e2823634ab331437001b411b9ed11660fbc4066f3908c84a9439260d"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"byteorder",
"digest",
"lazy_static",
"num-bigint-dig",
"num-integer",
"num-iter",
"num-traits",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"pkcs1",
"pkcs8",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"rand 0.8.5",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"serde",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"subtle",
"zeroize",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "rustc-demangle"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.21"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "7ef03e0a2b150c7a90d01faf6254c9c48a41e95fb2a8c2ac1c6f0d2b9aefc342"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
[[package]]
name = "rustix"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
version = "0.35.10"
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
checksum = "af895b90e5c071badc3136fc10ff0bcfc98747eadbaf43ed8f214e07ba8f8477"
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
dependencies = [
"bitflags",
"errno",
"io-lifetimes",
Update to cap-std 0.22.0. (#3611) * Update to cap-std 0.22.0. The main change relevant to Wasmtime here is that this includes the rustix fix for compilation errors on Rust nightly with the `asm!` macro. * Add itoa to deny.toml. * Update the doc and fuzz builds to the latest Rust nightly. * Update to libc 0.2.112 to pick up the `POLLRDHUP` fix. * Update to cargo-fuzz 0.11, for compatibility with Rust nightly. This appears to be the fix for rust-fuzz/cargo-fuzz#277.
3 years ago
"itoa 1.0.1",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"libc",
"linux-raw-sys",
"once_cell",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
]
Fix wiggle's tests
5 years ago
[[package]]
name = "rusty-fork"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
version = "0.3.0"
Fix wiggle's tests
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
checksum = "cb3dcc6e454c328bb824492db107ab7c0ae8fcffe4ad210136ef014458c1bc4f"
Fix wiggle's tests
5 years ago
dependencies = [
"fnv",
Bump dependencies to get a single version of rand (#2733) This removes a few crates in the dependencies, and a few exceptions (at the price of a new one) in the cargo-deny configuration.
4 years ago
"quick-error 1.2.3",
Fix wiggle's tests
5 years ago
"tempfile",
"wait-timeout",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "ryu"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.0.9"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "73b4b750c782965c211b42f022f59af1fbceabdd026623714f104152f1ec149f"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "same-file"
version = "1.0.6"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "93fc1dc3aaa9bfed95e02e6eadabb4baf7e3078b0bd1b4d7b6b0b68378900502"
dependencies = [
"winapi-util",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "scopeguard"
Adds perf jitdump support (#360) Patch adds support for the perf jitdump file specification. With this patch it should be possible to see profile data for code generated and maped at runtime. Specifically the patch adds support for the JIT_CODE_LOAD and the JIT_DEBUG_INFO record as described in the specification. Dumping jitfiles is enabled with the --jitdump flag. When the -g flag is also used there is an attempt to dump file and line number information where this option would be most useful when the WASM file already includes DWARF debug information. The generation of the jitdump files has been tested on only a few wasm files. This patch is expected to be useful/serviceable where currently there is no means for jit profiling, but future patches may benefit line mapping and add support for additional jitdump record types. Usage Example: Record sudo perf record -k 1 -e instructions:u target/debug/wasmtime -g --jitdump test.wasm Combine sudo perf inject -v -j -i perf.data -o perf.jit.data Report sudo perf report -i perf.jit.data -F+period,srcline
5 years ago
version = "1.1.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Adds perf jitdump support (#360) Patch adds support for the perf jitdump file specification. With this patch it should be possible to see profile data for code generated and maped at runtime. Specifically the patch adds support for the JIT_CODE_LOAD and the JIT_DEBUG_INFO record as described in the specification. Dumping jitfiles is enabled with the --jitdump flag. When the -g flag is also used there is an attempt to dump file and line number information where this option would be most useful when the WASM file already includes DWARF debug information. The generation of the jitdump files has been tested on only a few wasm files. This patch is expected to be useful/serviceable where currently there is no means for jit profiling, but future patches may benefit line mapping and add support for additional jitdump record types. Usage Example: Record sudo perf record -k 1 -e instructions:u target/debug/wasmtime -g --jitdump test.wasm Combine sudo perf inject -v -j -i perf.data -o perf.jit.data Report sudo perf report -i perf.jit.data -F+period,srcline
5 years ago
checksum = "d29ab0c6d3fc0ee92fe66e2d99f700eab17a8d57d1c1d3b748380fb20baa78cd"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "serde"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "1.0.137"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "61ea8d54c77f8315140a05f4c7237403bf38b72704d031543aa1d16abbf517d1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"serde_derive",
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "serde_cbor"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.11.2"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "2bef2ebfde456fb76bbcf9f59315333decc4fda0b2b44b420243c11e0f5ec1f5"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"half",
"serde",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "serde_derive"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "1.0.137"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "1f26faba0c3959972377d3b2d306ee9f71faee9714294e41bb777f83f88578be"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"proc-macro2",
"quote",
"syn",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "serde_json"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "1.0.80"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "f972498cf015f7c0746cac89ebe1d6ef10c293b94175a243a2d9442c163d9944"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"itoa 1.0.1",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"ryu",
"serde",
]
[[package]]
name = "sha2"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.9.9"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "4d58a1e1bf39749807d89cf2d98ac2dfa0ff1cb3faa38fbb64dd88ac8013d800"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"block-buffer",
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
ISLE: guard against stale generated source in default build config. Currently, the `build.rs` script that generates Rust source from the ISLE DSL will only do this generation if the `rebuild-isle` Cargo feature is specified. By default, it is not. This is based on the principle that we (the build script) do not modify the source tree as managed by git; git-managed files are strictly a human-managed and human-edited resource. By adding the opt-in Cargo feature, a developer is requesting the build script to perform an explicit action. (In my understanding at least, this principle comes from the general philosophy of hermetic builds: the output should be a pure function of the input, and part of this is that the input is read-only. If we modify the source tree, then all bets are off.) Unfortunately, requiring the opt-in feature also creates a footgun that is easy to hit: if a developer modifies the ISLE DSL source, but forgets to specify the Cargo feature, then the compiler will silently be built successfully with stale source, and will silently exclude any changes that were made. The generated source is checked into git for a good reason: we want DSL compiler to not affect build times for the overwhelmingly common case that Cranelift is used as a dependency but the backends are not being actively developed. (This overhead comes mainly from building `islec` itself.) So, what to do? This PR implements a middle ground first described in [this conversation](https://github.com/bytecodealliance/wasmtime/pull/3506#discussion_r743113351), in which we: - Generate a hash (SHA-512) of the ISLE DSL source and produce a "manifest" of ISLE inputs alongside the generated source; and - Always read the ISLE DSL source, and see if the manifest is still valid, on builds that do not have the opt-in "rebuild" feature. This allows us to know whether the ISLE compiler output would have been the same (modulo changes to the DSL compiler itself, which are out-of-scope here), without actually building the ISLE compiler and running it. If the compiler-backend developer modifies an ISLE source file and then tries to build `cranelift-codegen` without adding the `rebuild-isle` Cargo feature, they get the following output: ```text Error: the ISLE source files that resulted in the generated Rust source * src/isa/x64/lower/isle/generated_code.rs have changed but the generated source was not rebuilt! These ISLE source files are: * src/clif.isle * src/prelude.isle * src/isa/x64/inst.isle * src/isa/x64/lower.isle Please add `--features rebuild-isle` to your `cargo build` command if you wish to rebuild the generated source, then include these changes in any git commits you make that include the changes to the ISLE. For example: $ cargo build -p cranelift-codegen --features rebuild-isle (This build script cannot do this for you by default because we cannot modify checked-into-git source without your explicit opt-in.) ``` which will tell them exactly what they need to do to fix the problem! Note that I am leaving the "Rebuild ISLE" CI job alone for now, because otherwise, we are trusting whomever submits a PR to generate the correct generated source. In other words, the manifest is a communication from the checked-in tree to the developer, but we still need to verify that the checked-in generated Rust source and the manifest are correct with respect to the checked-in ISLE source.
3 years ago
"cpufeatures",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"digest",
"opaque-debug",
]
wiggle: can swap in `tracing` for args
5 years ago
[[package]]
name = "sharded-slab"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.1.4"
wiggle: can swap in `tracing` for args
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "900fba806f70c630b0a382d0d825e17a0f19fcd059a2ade1ff237bcddf446b31"
wiggle: can swap in `tracing` for args
5 years ago
dependencies = [
"lazy_static",
]
wiggle: witx paths use shell expansion instead of always being relative to CARGO_MANIFEST_DIR, each use site is responsible for either putting that variable or another one (set by a build.rs) at the start of witx paths.
4 years ago
[[package]]
name = "shellexpand"
Upgrade shellexpand dep (#2529) The previous version depended on the deprecated `dirs` crate.
4 years ago
version = "2.1.0"
wiggle: witx paths use shell expansion instead of always being relative to CARGO_MANIFEST_DIR, each use site is responsible for either putting that variable or another one (set by a build.rs) at the start of witx paths.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Upgrade shellexpand dep (#2529) The previous version depended on the deprecated `dirs` crate.
4 years ago
checksum = "83bdb7831b2d85ddf4a7b148aa19d0587eddbe8671a436b7bd1182eaad0f2829"
wiggle: witx paths use shell expansion instead of always being relative to CARGO_MANIFEST_DIR, each use site is responsible for either putting that variable or another one (set by a build.rs) at the start of witx paths.
4 years ago
dependencies = [
Upgrade shellexpand dep (#2529) The previous version depended on the deprecated `dirs` crate.
4 years ago
"dirs-next",
wiggle: witx paths use shell expansion instead of always being relative to CARGO_MANIFEST_DIR, each use site is responsible for either putting that variable or another one (set by a build.rs) at the start of witx paths.
4 years ago
]
wasmtime-bench-api: Randomize the locations of heap objects This helps us avoid measurement bias due to accidental locality of unrelated heap objects. See *Stabilizer: Statistically Sound Performance Evaluation* by Curtsinger and Berger for details (although Stabilizer deals with much more than just the location of heap allocations): https://people.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf
4 years ago
[[package]]
name = "shuffling-allocator"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
version = "1.1.2"
wasmtime-bench-api: Randomize the locations of heap objects This helps us avoid measurement bias due to accidental locality of unrelated heap objects. See *Stabilizer: Statistically Sound Performance Evaluation* by Curtsinger and Berger for details (although Stabilizer deals with much more than just the location of heap allocations): https://people.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
checksum = "4ee9977fa98489d9006f4ab26fc5cbe2a139985baed09d2ec08dee6e506fc496"
wasmtime-bench-api: Randomize the locations of heap objects This helps us avoid measurement bias due to accidental locality of unrelated heap objects. See *Stabilizer: Statistically Sound Performance Evaluation* by Curtsinger and Berger for details (although Stabilizer deals with much more than just the location of heap allocations): https://people.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
wasmtime-bench-api: Randomize the locations of heap objects This helps us avoid measurement bias due to accidental locality of unrelated heap objects. See *Stabilizer: Statistically Sound Performance Evaluation* by Curtsinger and Berger for details (although Stabilizer deals with much more than just the location of heap allocations): https://people.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf
4 years ago
"libc",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"rand 0.8.5",
wasmtime-bench-api: Randomize the locations of heap objects This helps us avoid measurement bias due to accidental locality of unrelated heap objects. See *Stabilizer: Statistically Sound Performance Evaluation* by Curtsinger and Berger for details (although Stabilizer deals with much more than just the location of heap allocations): https://people.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf
4 years ago
"winapi",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "signature"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.3.2"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "f2807892cfa58e081aa1f1111391c7a0649d4fa127a4ffbe34bcbfb35a1171a4"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"digest",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"rand_core 0.6.3",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
]
Use `similar` to diff expected and actual output in filetests (#4282)
2 years ago
[[package]]
name = "similar"
version = "2.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "2e24979f63a11545f5f2c60141afe249d4f19f84581ea2138065e400941d83d3"
Switch Cranelift over to regalloc2. (#3989) This PR switches Cranelift over to the new register allocator, regalloc2. See [this document](https://gist.github.com/cfallin/08553421a91f150254fe878f67301801) for a summary of the design changes. This switchover has implications for core VCode/MachInst types and the lowering pass. Overall, this change brings improvements to both compile time and speed of generated code (runtime), as reported in #3942: ``` Benchmark Compilation (wallclock) Execution (wallclock) blake3-scalar 25% faster 28% faster blake3-simd no diff no diff meshoptimizer 19% faster 17% faster pulldown-cmark 17% faster no diff bz2 15% faster no diff SpiderMonkey, 21% faster 2% faster fib(30) clang.wasm 42% faster N/A ```
3 years ago
[[package]]
name = "slice-group-by"
version = "0.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "03b634d87b960ab1a38c4fe143b508576f075e7c978bfad18217645ebfdfa2ec"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "smallvec"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.8.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "f2dd574626839106c320a323308629dcb1acfc96e32a8cba364ddc61ac23ee83"
Implement an incremental compilation cache for Cranelift (#4551) This is the implementation of https://github.com/bytecodealliance/wasmtime/issues/4155, using the "inverted API" approach suggested by @cfallin (thanks!) in Cranelift, and trait object to provide a backend for an all-included experience in Wasmtime. After the suggestion of Chris, `Function` has been split into mostly two parts: - on the one hand, `FunctionStencil` contains all the fields required during compilation, and that act as a compilation cache key: if two function stencils are the same, then the result of their compilation (`CompiledCodeBase<Stencil>`) will be the same. This makes caching trivial, as the only thing to cache is the `FunctionStencil`. - on the other hand, `FunctionParameters` contain the... function parameters that are required to finalize the result of compilation into a `CompiledCode` (aka `CompiledCodeBase<Final>`) with proper final relocations etc., by applying fixups and so on. Most changes are here to accomodate those requirements, in particular that `FunctionStencil` should be `Hash`able to be used as a key in the cache: - most source locations are now relative to a base source location in the function, and as such they're encoded as `RelSourceLoc` in the `FunctionStencil`. This required changes so that there's no need to explicitly mark a `SourceLoc` as the base source location, it's automatically detected instead the first time a non-default `SourceLoc` is set. - user-defined external names in the `FunctionStencil` (aka before this patch `ExternalName::User { namespace, index }`) are now references into an external table of `UserExternalNameRef -> UserExternalName`, present in the `FunctionParameters`, and must be explicitly declared using `Function::declare_imported_user_function`. - some refactorings have been made for function names: - `ExternalName` was used as the type for a `Function`'s name; while it thus allowed `ExternalName::Libcall` in this place, this would have been quite confusing to use it there. Instead, a new enum `UserFuncName` is introduced for this name, that's either a user-defined function name (the above `UserExternalName`) or a test case name. - The future of `ExternalName` is likely to become a full reference into the `FunctionParameters`'s mapping, instead of being "either a handle for user-defined external names, or the thing itself for other variants". I'm running out of time to do this, and this is not trivial as it implies touching ISLE which I'm less familiar with. The cache computes a sha256 hash of the `FunctionStencil`, and uses this as the cache key. No equality check (using `PartialEq`) is performed in addition to the hash being the same, as we hope that this is sufficient data to avoid collisions. A basic fuzz target has been introduced that tries to do the bare minimum: - check that a function successfully compiled and cached will be also successfully reloaded from the cache, and returns the exact same function. - check that a trivial modification in the external mapping of `UserExternalNameRef -> UserExternalName` hits the cache, and that other modifications don't hit the cache. - This last check is less efficient and less likely to happen, so probably should be rethought a bit. Thanks to both @alexcrichton and @cfallin for your very useful feedback on Zulip. Some numbers show that for a large wasm module we're using internally, this is a 20% compile-time speedup, because so many `FunctionStencil`s are the same, even within a single module. For a group of modules that have a lot of code in common, we get hit rates up to 70% when they're used together. When a single function changes in a wasm module, every other function is reloaded; that's still slower than I expect (between 10% and 50% of the overall compile time), so there's likely room for improvement. Fixes #4155.
2 years ago
dependencies = [
"serde",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Make ISLE part of the root Cargo workspace.
3 years ago
[[package]]
name = "smawk"
version = "0.3.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f67ad224767faa3c7d8b6d91985b78e70a1324408abcb1cfcc2be4c06bc06043"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
[[package]]
name = "socket2"
version = "0.4.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "66d72b759436ae32898a2af0a14218dbf55efde3feeb170eb623637db85ee1e0"
dependencies = [
"libc",
"winapi",
]
Convert Souper optimizations into Peepmatic DSL Conversion from Souper into Peepmatic is implemented with a straightforward, top-down recursive traversal of the optimization's left- and right-hand side expression DAGs. Most Souper instructions have a corresponding Peepmatic instruction. If we run into an instruction where that isn't the case, we skip that Souper optimization and move on to the next one. Note that Souper fully supports DAGs, for example: ```text %0 = var %1 = add 1, %0 %2 = add %1, %1 ;; Two edges to `%1` makes this a DAG. ``` On the other hand, Peepmatic only currently supports trees, so shared subexpressions are duplicated: ```text (iadd (iadd 1 $x) (iadd 1 $x)) ;; The shared subexpression is duplicated. ``` This does not affect correctness.
4 years ago
[[package]]
name = "souper-ir"
souper-harvest: ensure that `select` conditions are of type `i1`
4 years ago
version = "2.1.0"
Convert Souper optimizations into Peepmatic DSL Conversion from Souper into Peepmatic is implemented with a straightforward, top-down recursive traversal of the optimization's left- and right-hand side expression DAGs. Most Souper instructions have a corresponding Peepmatic instruction. If we run into an instruction where that isn't the case, we skip that Souper optimization and move on to the next one. Note that Souper fully supports DAGs, for example: ```text %0 = var %1 = add 1, %0 %2 = add %1, %1 ;; Two edges to `%1` makes this a DAG. ``` On the other hand, Peepmatic only currently supports trees, so shared subexpressions are duplicated: ```text (iadd (iadd 1 $x) (iadd 1 $x)) ;; The shared subexpression is duplicated. ``` This does not affect correctness.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
souper-harvest: ensure that `select` conditions are of type `i1`
4 years ago
checksum = "a50c18ce33988e1973003afbaa66e6a465ad7a614dc33f246879ccc209c2c044"
Convert Souper optimizations into Peepmatic DSL Conversion from Souper into Peepmatic is implemented with a straightforward, top-down recursive traversal of the optimization's left- and right-hand side expression DAGs. Most Souper instructions have a corresponding Peepmatic instruction. If we run into an instruction where that isn't the case, we skip that Souper optimization and move on to the next one. Note that Souper fully supports DAGs, for example: ```text %0 = var %1 = add 1, %0 %2 = add %1, %1 ;; Two edges to `%1` makes this a DAG. ``` On the other hand, Peepmatic only currently supports trees, so shared subexpressions are duplicated: ```text (iadd (iadd 1 $x) (iadd 1 $x)) ;; The shared subexpression is duplicated. ``` This does not affect correctness.
4 years ago
dependencies = [
"id-arena",
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "spin"
version = "0.5.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "6e63cff320ae2c57904679ba7cb63280a3dc4613885beafb148ee7bf9aa9042d"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
[[package]]
name = "spki"
version = "0.4.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "5c01a0c15da1b0b0e1494112e7af814a678fec9bd157881b49beac661e9b6f32"
dependencies = [
"der",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "stable_deref_trait"
Wasmtime 0.19.0 and Cranelift 0.66.0 (#2027) This commit updates Wasmtime's version to 0.19.0, Cranelift's version to 0.66.0, and updates the release notes as well.
4 years ago
version = "1.2.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Wasmtime 0.19.0 and Cranelift 0.66.0 (#2027) This commit updates Wasmtime's version to 0.19.0, Cranelift's version to 0.66.0, and updates the release notes as well.
4 years ago
checksum = "a8f112729512f8e442d81f95a8a7ddf2b7c6b8a1a6f509a95864142b30cab2d3"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
[[package]]
name = "static_assertions"
version = "1.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a2eb9349b6444b326872e140eb1cf5e7c522154d69e7a0ffb0fb81c06b37543f"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "strsim"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
version = "0.10.0"
Use structopt instead of docopt. This commit refactors the Wasmtime CLI tools to use `structopt` instead of `docopt`. The `wasmtime` tool now has the following subcommands: * `config new` - creates a new Wasmtime configuration file. * `run` - runs a WebAssembly module. * `wasm2obj` - translates a Wasm module to native object file. * `wast` - runs a test script file. If no subcommand is specified, the `run` subcommand is used. Thus, `wasmtime foo.wasm` should continue to function as expected. The `wasm2obj` and `wast` tools still exist, but delegate to the same implementation as the `wasmtime` subcommands. The standalone `wasm2obj` and `wast` tools may be removed in the future in favor of simply using `wasmtime`. Included in this commit is a breaking change to the default Wasmtime configuration file: it has been renamed from `wasmtime-cache-config.toml` to simply `config.toml`. The new name is less specific which will allow for additional (non-cache-related) settings in the future. There are some breaking changes to improve command line UX: * The `--cache-config` option has been renamed to `--config`. * The `--create-config-file` option has moved to the `config new` subcommand. As a result, the `wasm2obj` and `wast` tools cannot be used to create a new config file. * The short form of the `--optimize` option has changed from `-o` to `-O` for consistency. * The `wasm2obj` command takes the output object file as a required positional argument rather than the former required output *option* (e.g. `wasmtime wasm2obj foo.wasm foo.obj`).
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
checksum = "73473c0e59e6d5812c5dfe2a064a6444949f089e20eec9a2e5506596494e4623"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "subtle"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "2.4.1"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "6bdef32e8150c2a081110b42772ffe7d7c9032b606bc226c8260fd97e0976601"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
Make ISLE part of the root Cargo workspace.
3 years ago
[[package]]
name = "supports-color"
version = "1.3.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4872ced36b91d47bae8a214a683fe54e7078875b399dfa251df346c9b547d1f9"
dependencies = [
"atty",
"is_ci",
]
[[package]]
name = "supports-hyperlinks"
version = "1.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "590b34f7c5f01ecc9d78dba4b3f445f31df750a67621cf31626f3b7441ce6406"
dependencies = [
"atty",
]
[[package]]
name = "supports-unicode"
version = "1.0.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a8b945e45b417b125a8ec51f1b7df2f8df7920367700d1f98aedd21e5735f8b2"
dependencies = [
"atty",
]
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
[[package]]
name = "symbolic_expressions"
version = "5.0.3"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "7c68d531d83ec6c531150584c42a4290911964d5f0d79132b193b67252a23b71"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
[[package]]
name = "syn"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "1.0.92"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "7ff7c592601f11445996a06f8ad0c27f094a58857c2f89e97974ab9235b92c52"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
dependencies = [
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"proc-macro2",
"quote",
"unicode-xid",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "synstructure"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.12.6"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "f36bdaa60a83aca3921b5259d5400cbf5e90fc51931376a9bd4a0eb79aa7210f"
Update fuzz crates (#826) * deps: Update to arbitrary 0.3.x and libfuzzer-sys 0.2.0 * ci: Use cargo-fuzz 0.7.x in CI
5 years ago
dependencies = [
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"proc-macro2",
"quote",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"syn",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"unicode-xid",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
wasi-c2: rewrite wasi-common in terms of system-interface
4 years ago
[[package]]
name = "system-interface"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
version = "0.23.0"
cargo.lock
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update to cap-std 0.26. (#4940) * Update to cap-std 0.26. This is primarily to pull in bytecodealliance/cap-std#271, the fix for #4936, compilation on Rust nightly on Windows. It also updates to rustix 0.35.10, to pull in bytecodealliance/rustix#403, the fix for bytecodealliance/rustix#402, compilation on newer versions of the libc crate, which changed a public function from `unsafe` to safe. Fixes #4936. * Update the system-interface audit for 0.23. * Update the libc supply-chain config version.
2 years ago
checksum = "92adbaf536f5aff6986e1e62ba36cee72b1718c5153eee08b9e728ddde3f6029"
wasi-c2: rewrite wasi-common in terms of system-interface
4 years ago
dependencies = [
"atty",
latest system-interface
4 years ago
"bitflags",
system-interface 0.6
4 years ago
"cap-fs-ext",
"cap-std",
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"io-lifetimes",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
rename everything c2 related to the "real" names
4 years ago
"winx",
wasi-c2: rewrite wasi-common in terms of system-interface
4 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "target-lexicon"
Fuzz cranelift cpu flag settings with Wasmtime (#3800) * Fuzz cranelift cpu flag settings with Wasmtime This commit updates the `Config` fuzz-generator to consume some of the input as configuration settings for codegen flags we pass to cranelift. This should allow for ideally some more coverage where settings are disabled or enabled, ideally finding possible bugs in feature-specific implementations or generic implementations that are rarely used if the feature-specific ones almost always take precedent. The technique used in this commit is to weight selection of codegen settings less frequently than using the native settings. Afterwards each listed feature is individually enabled or disabled depending on the input fuzz data, and if a feature is enabled but the host doesn't actually support it then the fuzz input is rejected with a log message. The goal here is to still have many fuzz inputs accepted but also ensure determinism across hosts. If there's a bug specifically related to enabling a flag then running it on a host without the flag should indicate that the flag isn't supported rather than silently leaving it disabled and reporting the fuzz case a success. * Use built-in `Unstructured::ratio` method * Tweak macro * Bump arbitrary dep version
3 years ago
version = "0.12.3"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Fuzz cranelift cpu flag settings with Wasmtime (#3800) * Fuzz cranelift cpu flag settings with Wasmtime This commit updates the `Config` fuzz-generator to consume some of the input as configuration settings for codegen flags we pass to cranelift. This should allow for ideally some more coverage where settings are disabled or enabled, ideally finding possible bugs in feature-specific implementations or generic implementations that are rarely used if the feature-specific ones almost always take precedent. The technique used in this commit is to weight selection of codegen settings less frequently than using the native settings. Afterwards each listed feature is individually enabled or disabled depending on the input fuzz data, and if a feature is enabled but the host doesn't actually support it then the fuzz input is rejected with a log message. The goal here is to still have many fuzz inputs accepted but also ensure determinism across hosts. If there's a bug specifically related to enabling a flag then running it on a host without the flag should indicate that the flag isn't supported rather than silently leaving it disabled and reporting the fuzz case a success. * Use built-in `Unstructured::ratio` method * Tweak macro * Bump arbitrary dep version
3 years ago
checksum = "d7fa7e55043acb85fca6b3c01485a2eeb6b69c5d21002e273c79e465f43b7ac1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "tempfile"
Fuzz using precompiled modules on CI (#3788) In working on #3787 I see now that our coverage of loading precompiled files specifically is somewhat lacking, so this adds a config option to the fuzzers where, if enabled, will round-trip all compiled modules through the filesystem to test out the mmapped-file case.
3 years ago
version = "3.3.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Fuzz using precompiled modules on CI (#3788) In working on #3787 I see now that our coverage of loading precompiled files specifically is somewhat lacking, so this adds a config option to the fuzzers where, if enabled, will round-trip all compiled modules through the filesystem to test out the mmapped-file case.
3 years ago
checksum = "5cdb1ef4eaeeaddc8fbd371e5017057064af0911902ef36b39801f67cc6d79e4"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Fuzz using precompiled modules on CI (#3788) In working on #3787 I see now that our coverage of loading precompiled files specifically is somewhat lacking, so this adds a config option to the fuzzers where, if enabled, will round-trip all compiled modules through the filesystem to test out the mmapped-file case.
3 years ago
"fastrand",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"libc",
Update version for fs-set-times to 3.1
4 years ago
"redox_syscall",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"remove_dir_all",
"winapi",
]
[[package]]
name = "termcolor"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "1.1.3"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "bab24d30b911b2376f3a13cc2cd443142f0c81dda04c118693e35b3835757755"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Run `cargo update` on dependencies (#868) Looks like we're able to actually drop a good number of various deps, especially some large-ish ones like syn 0.14! Adding proc-macro2 v1.0.8 Adding syn v1.0.14 Removing base64 v0.10.1 Removing cloudabi v0.0.3 Removing crossbeam-utils v0.6.6 Removing failure v0.1.6 Removing failure_derive v0.1.6 Removing fuchsia-cprng v0.1.1 Removing proc-macro2 v0.4.30 Removing proc-macro2 v1.0.7 Removing quote v0.6.13 Removing rand_core v0.3.1 Removing rand_core v0.4.2 Removing rand_os v0.1.3 Removing rdrand v0.4.0 Removing syn v0.14.9 Removing syn v1.0.13 Removing synstructure v0.9.0 Removing unicode-xid v0.1.0 Removing wincolor v1.0.2 Updating arbitrary v0.3.2 -> v0.3.3 Updating arrayref v0.3.5 -> v0.3.6 Updating constant_time_eq v0.1.4 -> v0.1.5 Updating crates.io index Updating derive_arbitrary v0.3.1 -> v0.3.3 Updating indexmap v1.3.0 -> v1.3.1 Updating itoa v0.4.4 -> v0.4.5 Updating jobserver v0.1.18 -> v0.1.19 Updating memchr v2.2.1 -> v2.3.0 Updating num_cpus v1.11.1 -> v1.12.0 Updating proc-macro-error v0.4.4 -> v0.4.5 Updating proc-macro-error-attr v0.4.3 -> v0.4.5 Updating quickcheck v0.9.0 -> v0.9.2 Updating rand v0.7.2 -> v0.7.3 Updating redox_users v0.3.1 -> v0.3.4 Updating rust-argon2 v0.5.1 -> v0.7.0 Updating rustversion v1.0.1 -> v1.0.2 Updating serde_json v1.0.44 -> v1.0.45 Updating structopt v0.3.7 -> v0.3.8 Updating structopt-derive v0.4.0 -> v0.4.1 Updating termcolor v1.0.5 -> v1.1.0 Updating thread_local v1.0.0 -> v1.0.1 Updating toml v0.5.5 -> v0.5.6 Updating winapi-util v0.1.2 -> v0.1.3
5 years ago
"winapi-util",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Update deps and tests for `anyref` --> `externref` * Update to using `wasmparser` 0.55.0 * Update wasmprinter to 0.2.5 * Update `wat` to 1.0.18, and `wast` to 17.0.0
5 years ago
[[package]]
name = "terminal_size"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "0.1.17"
Update deps and tests for `anyref` --> `externref` * Update to using `wasmparser` 0.55.0 * Update wasmprinter to 0.2.5 * Update `wat` to 1.0.18, and `wast` to 17.0.0
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "633c1a546cee861a1a6d0dc69ebeca693bf4296661ba7852b9d21d159e0506df"
Update deps and tests for `anyref` --> `externref` * Update to using `wasmparser` 0.55.0 * Update wasmprinter to 0.2.5 * Update `wat` to 1.0.18, and `wast` to 17.0.0
5 years ago
dependencies = [
"libc",
"winapi",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "test-programs"
Wasmtime 0.19.0 and Cranelift 0.66.0 (#2027) This commit updates Wasmtime's version to 0.19.0, Cranelift's version to 0.66.0, and updates the release notes as well.
4 years ago
version = "0.19.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"anyhow",
system-interface 0.6
4 years ago
"cap-std",
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"os_pipe",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"target-lexicon",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"tempfile",
cargo.lock
4 years ago
"tokio",
feat: rely on `tracing-subscriber` in tests (#4950) `tracing` crate is already used within the codebase, this change allows developers to benefit from that functionality when running and debugging tests Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net> Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
2 years ago
"tracing-subscriber",
rename everything c2 related to the "real" names
4 years ago
"wasi-cap-std-sync",
"wasi-common",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime",
rename everything c2 related to the "real" names
4 years ago
"wasmtime-wasi",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wat",
]
[[package]]
name = "textwrap"
version = "0.11.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "d326610f408c7a4eb6f51c37c330e496b08506c9457c9d34287ecc38809fb060"
dependencies = [
"unicode-width",
]
Make ISLE part of the root Cargo workspace.
3 years ago
[[package]]
name = "textwrap"
Cranelift: do not check in generated ISLE code; regenerate on every compile. (#4143) This PR fixes #4066: it modifies the Cranelift `build.rs` workflow to invoke the ISLE DSL compiler on every compilation, rather than only when the user specifies a special "rebuild ISLE" feature. The main benefit of this change is that it vastly simplifies the mental model required of developers, and removes a bunch of failure modes we have tried to work around in other ways. There is now just one "source of truth", the ISLE source itself, in the repository, and so there is no need to understand a special "rebuild" step and how to handle merge errors. There is no special process needed to develop the compiler when modifying the DSL. And there is no "noise" in the git history produced by constantly-regenerated files. The two main downsides we discussed in #4066 are: - Compile time could increase, by adding more to the "meta" step before the main build; - It becomes less obvious where the source definitions are (everything becomes more "magic"), which makes exploration and debugging harder. This PR addresses each of these concerns: 1. To maintain reasonable compile time, it includes work to cut down the dependencies of the `cranelift-isle` crate to *nothing* (only the Rust stdlib), in the default build. It does this by putting the error-reporting bits (`miette` crate) under an optional feature, and the logging (`log` crate) under a feature-controlled macro, and manually writing an `Error` impl rather than using `thiserror`. This completely avoids proc macros and the `syn` build slowness. The user can still get nice errors out of `miette`: this is enabled by specifying a Cargo feature `--features isle-errors`. 2. To allow the user to optionally inspect the generated source, which nominally lives in a hard-to-find path inside `target/` now, this PR adds a feature `isle-in-source-tree` that, as implied by the name, moves the target for ISLE generated source into the source tree, at `cranelift/codegen/isle_generated_source/`. It seems reasonable to do this when an explicit feature (opt-in) is specified because this is how ISLE regeneration currently works as well. To prevent surprises, if the feature is *not* specified, the build fails if this directory exists.
3 years ago
version = "0.15.0"
Make ISLE part of the root Cargo workspace.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Cranelift: do not check in generated ISLE code; regenerate on every compile. (#4143) This PR fixes #4066: it modifies the Cranelift `build.rs` workflow to invoke the ISLE DSL compiler on every compilation, rather than only when the user specifies a special "rebuild ISLE" feature. The main benefit of this change is that it vastly simplifies the mental model required of developers, and removes a bunch of failure modes we have tried to work around in other ways. There is now just one "source of truth", the ISLE source itself, in the repository, and so there is no need to understand a special "rebuild" step and how to handle merge errors. There is no special process needed to develop the compiler when modifying the DSL. And there is no "noise" in the git history produced by constantly-regenerated files. The two main downsides we discussed in #4066 are: - Compile time could increase, by adding more to the "meta" step before the main build; - It becomes less obvious where the source definitions are (everything becomes more "magic"), which makes exploration and debugging harder. This PR addresses each of these concerns: 1. To maintain reasonable compile time, it includes work to cut down the dependencies of the `cranelift-isle` crate to *nothing* (only the Rust stdlib), in the default build. It does this by putting the error-reporting bits (`miette` crate) under an optional feature, and the logging (`log` crate) under a feature-controlled macro, and manually writing an `Error` impl rather than using `thiserror`. This completely avoids proc macros and the `syn` build slowness. The user can still get nice errors out of `miette`: this is enabled by specifying a Cargo feature `--features isle-errors`. 2. To allow the user to optionally inspect the generated source, which nominally lives in a hard-to-find path inside `target/` now, this PR adds a feature `isle-in-source-tree` that, as implied by the name, moves the target for ISLE generated source into the source tree, at `cranelift/codegen/isle_generated_source/`. It seems reasonable to do this when an explicit feature (opt-in) is specified because this is how ISLE regeneration currently works as well. To prevent surprises, if the feature is *not* specified, the build fails if this directory exists.
3 years ago
checksum = "b1141d4d61095b28419e22cb0bbf02755f5e54e0526f97f1e3d1d160e60885fb"
Make ISLE part of the root Cargo workspace.
3 years ago
dependencies = [
"smawk",
"unicode-linebreak",
"unicode-width",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "thiserror"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "1.0.31"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "bd829fe32373d27f76265620b5309d0340cb8550f523c1dda251d6298069069a"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"thiserror-impl",
]
[[package]]
name = "thiserror-impl"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "1.0.31"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "0396bc89e626244658bef819e22d0cc459e795a5ebe878e6ec336d1674a8d79a"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"proc-macro2",
"quote",
"syn",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "thread_local"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.1.4"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "5516c27b78311c50bf42c071425c560ac799b11c30b31f87e3081965fe5e0180"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Merge remote-tracking branch 'origin/main' into pch/wasi_common_cap_std
4 years ago
"once_cell",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "tinytemplate"
version = "1.2.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "be4d6b5f19ff7664e8c98d03e2139cb510db9b0a60b55f8e8709b689d939b6bc"
dependencies = [
"serde",
"serde_json",
]
wasi-cap-std-async: exactly like wasi-cap-std-sync but with a different WasiSched
4 years ago
[[package]]
name = "tokio"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "1.18.1"
wasi-cap-std-async: exactly like wasi-cap-std-sync but with a different WasiSched
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "dce653fb475565de9f6fb0614b28bca8df2c430c0cf84bcd9c843f15de5414cc"
wasi-cap-std-async: exactly like wasi-cap-std-sync but with a different WasiSched
4 years ago
dependencies = [
use some better traits
4 years ago
"bytes",
follow the types
4 years ago
"libc",
use some better traits
4 years ago
"memchr",
follow the types
4 years ago
"mio",
add tokio example Co-authored-by: Alex Crichton <alex@alexcrichton.com>
4 years ago
"num_cpus",
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"once_cell",
wasi-cap-std-async: exactly like wasi-cap-std-sync but with a different WasiSched
4 years ago
"pin-project-lite",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"socket2",
add tokio example Co-authored-by: Alex Crichton <alex@alexcrichton.com>
4 years ago
"tokio-macros",
Upgrade Tokio to 1.8.1 This contains a fix for a vulnerability reported as RUSTSEC-2021-0072.
3 years ago
"winapi",
add tokio example Co-authored-by: Alex Crichton <alex@alexcrichton.com>
4 years ago
]
[[package]]
name = "tokio-macros"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.7.0"
add tokio example Co-authored-by: Alex Crichton <alex@alexcrichton.com>
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "b557f72f448c511a979e2564e55d74e6c4432fc96ff4f6241bc6bded342643b7"
add tokio example Co-authored-by: Alex Crichton <alex@alexcrichton.com>
4 years ago
dependencies = [
"proc-macro2",
"quote",
"syn",
wasi-cap-std-async: exactly like wasi-cap-std-sync but with a different WasiSched
4 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "toml"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.5.9"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "8d82e1a7758622a465f8cee077614c73484dac5b836c02ff6a40d5d1010324d7"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"serde",
]
temporarily use tracing from git
4 years ago
[[package]]
name = "tracing"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.1.34"
wiggle: can swap in `tracing` for args
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "5d0ecdcb44a79f0fe9844f0c4f33a342cbcbb5117de8001e6ba0dc2351327d09"
wiggle: can swap in `tracing` for args
5 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
use tracing 0.1.15 release
4 years ago
"log",
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
"pin-project-lite",
use tracing 0.1.15 release
4 years ago
"tracing-attributes",
"tracing-core",
wiggle: can swap in `tracing` for args
5 years ago
]
[[package]]
name = "tracing-attributes"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.1.21"
wiggle: can swap in `tracing` for args
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "cc6b8ad3567499f98a1db7a752b07a7c8c7c7c34c332ec00effb2b0027974b7c"
wiggle: can swap in `tracing` for args
5 years ago
dependencies = [
"proc-macro2",
"quote",
"syn",
]
[[package]]
name = "tracing-core"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
version = "0.1.28"
wiggle: can swap in `tracing` for args
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
checksum = "7b7358be39f2f274f322d2aaed611acc57f382e8eb1e5b48cb9ae30933495ce7"
wiggle: can swap in `tracing` for args
5 years ago
dependencies = [
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"once_cell",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"valuable",
wiggle: can swap in `tracing` for args
5 years ago
]
[[package]]
name = "tracing-subscriber"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.3.11"
wiggle: can swap in `tracing` for args
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "4bc28f93baff38037f64e6f43d34cfa1605f27a49c34e8a04c5e78b0babf2596"
wiggle: can swap in `tracing` for args
5 years ago
dependencies = [
"sharded-slab",
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
"thread_local",
use tracing 0.1.15 release
4 years ago
"tracing-core",
wiggle: can swap in `tracing` for args
5 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "typenum"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.15.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "dcf81ac59edc17cc8697ff311e8f5ef2d99fcbd9817b34cec66f90b6c3dfd987"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Make ISLE part of the root Cargo workspace.
3 years ago
[[package]]
name = "unicode-linebreak"
version = "0.1.2"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "3a52dcaab0c48d931f7cc8ef826fa51690a08e1ea55117ef26f89864f532383f"
dependencies = [
"regex",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "unicode-width"
Update wasm-tools crates Nothing major here, just a routine update with a few extra things to handle here-and-there.
3 years ago
version = "0.1.9"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasm-tools crates Nothing major here, just a routine update with a few extra things to handle here-and-there.
3 years ago
checksum = "3ed742d4ea2bd1176e236172c8429aaf54486e7ac098db29ffe6529e0ce50973"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "unicode-xid"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
version = "0.2.3"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
checksum = "957e51f3646910546462e67d5f7599b9e4fb8acdd304b087a6494730f9eebf04"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
name = "universal-hash"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.4.1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "9f214e8f697e925001e66ec2c6e37a4ef93f0f78c2eed7814394e10c62025b05"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"generic-array",
"subtle",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
[[package]]
name = "uuid"
version = "1.0.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "8cfcd319456c4d6ea10087ed423473267e1a071f3bc0aa89f80d60997843c6f0"
wasi-tokio kinda sorta working
4 years ago
dependencies = [
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
"getrandom 0.2.6",
wasi-tokio kinda sorta working
4 years ago
]
Update v8 used during fuzzing (#3493) This commit updates the crate name from `rusty_v8` to `v8` as well since the upstream bindings have sinced moved. I originally wanted to do this to see if a fix for one of our fuzz bugs was pulled in but I don't think the fix has been pulled in yet. Despite that it seems reasonable to go ahead and update.
3 years ago
[[package]]
name = "v8"
Update v8 used when fuzzing (#4384) No particular reason for doing so,just seems good to loosely stay up-to-date with this dependency.
2 years ago
version = "0.44.3"
Update v8 used during fuzzing (#3493) This commit updates the crate name from `rusty_v8` to `v8` as well since the upstream bindings have sinced moved. I originally wanted to do this to see if a fix for one of our fuzz bugs was pulled in but I don't think the fix has been pulled in yet. Despite that it seems reasonable to go ahead and update.
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update v8 used when fuzzing (#4384) No particular reason for doing so,just seems good to loosely stay up-to-date with this dependency.
2 years ago
checksum = "f3f92c29dd66c7342443280695afc5bb79d773c3aa3eb02978cf24f058ae2b3d"
Update v8 used during fuzzing (#3493) This commit updates the crate name from `rusty_v8` to `v8` as well since the upstream bindings have sinced moved. I originally wanted to do this to see if a fix for one of our fuzz bugs was pulled in but I don't think the fix has been pulled in yet. Despite that it seems reasonable to go ahead and update.
3 years ago
dependencies = [
"bitflags",
"fslock",
"lazy_static",
"libc",
"which",
]
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
[[package]]
name = "valuable"
version = "0.1.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "830b7e5d4d90034032940e4ace0d9a9a057e7a45cd94e6c007832e39edb82f6d"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "version_check"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.9.4"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "49874b5167b65d7193b8aba1567f5c7d93d001cafc34600cee003eda787e483f"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Fix wiggle's tests
5 years ago
[[package]]
name = "wait-timeout"
version = "0.2.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9f200f5b12eb75f8c1ed65abd4b2db8a6e1b138a20de009dacee265a2498f3f6"
dependencies = [
"libc",
]
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
[[package]]
name = "walkdir"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
version = "2.3.2"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update `Cargo.lock`, remove `deny.toml` warning (#2965) This runs through and updates all our dependencies, additionally removing the need for ignoring a rustsec warning. Closes #2882
3 years ago
checksum = "808cf2735cd4b6866113f648b791c6adc5714537bc222d9347bb203386ffda56"
Fix build of cranelift-tools Accidentally left it out of the workspace members!
5 years ago
dependencies = [
"same-file",
"winapi",
"winapi-util",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "wasi"
Bump version to 0.9.0 (#790)
5 years ago
version = "0.9.0+wasi-snapshot-preview1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Bump version to 0.9.0 (#790)
5 years ago
checksum = "cccddf32554fecc6acb585f82a32a72e28b48f8c4c1883ddfeeeaa96f7d8e519"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
[[package]]
name = "wasi"
Merge remote-tracking branch 'origin/main' into pch/wasi_common_cap_std
4 years ago
version = "0.10.2+wasi-snapshot-preview1"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Merge remote-tracking branch 'origin/main' into pch/wasi_common_cap_std
4 years ago
checksum = "fd6fbd9a79829dd1ad0cc20627bf1ed606756a7f77edff7b66b7064f9cb327c6"
Update immediate and transitive dependencies I don't think this has happened in awhile but I've run a `cargo update` as well as trimming some of the duplicate/older dependencies in `Cargo.lock` by updating some of our immediate dependencies as well.
4 years ago
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
[[package]]
name = "wasi"
version = "0.11.0+wasi-snapshot-preview1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9c8d87e72b64a3b4db28d11ce29237c246188f4f51057d65a7eab63b7987e423"
wasi-c2: rewrite wasi-common in terms of system-interface
4 years ago
[[package]]
rename everything c2 related to the "real" names
4 years ago
name = "wasi-cap-std-sync"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
restructure cap-std impls into their own crate
4 years ago
dependencies = [
windows scheduler passes tests unfortunately this does essentially nothing to convince me of its correctness
4 years ago
"anyhow",
fix example
4 years ago
"async-trait",
system-interface 0.6
4 years ago
"cap-fs-ext",
restructure cap-std impls into their own crate
4 years ago
"cap-rand",
system-interface 0.6
4 years ago
"cap-std",
restructure cap-std impls into their own crate
4 years ago
"cap-time-ext",
"fs-set-times",
Implement `sock_accept` With the addition of `sock_accept()` in `wasi-0.11.0`, wasmtime can now implement basic networking for pre-opened sockets. For Windows `AsHandle` was replaced with `AsRawHandleOrSocket` to cope with the duality of Handles and Sockets. For Unix a `wasi_cap_std_sync::net::Socket` enum was created to handle the {Tcp,Unix}{Listener,Stream} more efficiently in `WasiCtxBuilder::preopened_socket()`. The addition of that many `WasiFile` implementors was mainly necessary, because of the difference in the `num_ready_bytes()` function. A known issue is Windows now busy polling on sockets, because except for `stdin`, nothing is querying the status of windows handles/sockets. Another know issue on Windows, is that there is no crate providing support for `fcntl(fd, F_GETFL, 0)` on a socket. Signed-off-by: Harald Hoyer <harald@profian.com>
3 years ago
"io-extras",
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"io-lifetimes",
Use is-terminal instead of atty. Following up on #3696, use the new is-terminal crate to test for a tty rather than having platform-specific logic in Wasmtime. The is-terminal crate has a platform-independent API which takes a handle. This also updates the tree to cap-std 0.24 etc., to avoid depending on multiple versions of io-lifetimes at once, as enforced by the cargo deny check.
3 years ago
"is-terminal",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"once_cell",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
restructure cap-std impls into their own crate
4 years ago
"system-interface",
cap-std-sync: test opening a tempdir as ambient and then WasiDir
4 years ago
"tempfile",
restructure cap-std impls into their own crate
4 years ago
"tracing",
rename everything c2 related to the "real" names
4 years ago
"wasi-common",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
restructure cap-std impls into their own crate
4 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "wasi-common"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"anyhow",
rename everything c2 related to the "real" names
4 years ago
"bitflags",
"cap-rand",
system-interface 0.6
4 years ago
"cap-std",
fix(wasi): enable all `WasiFile`s to be pollable (#3913) Currently, the use of the downcast method means that you have to use one of the hard-coded types. But Enarx needs to define its own `WasiFile` implementations. This works fine, except the resulting files cannot be used in poll because they aren't part of the hard-coded list. Replace this with an accessor method for the pollable type in `WasiFile`. Because we provide a default implementation of the method and manually implement it on all the hard-coded types, this is backwards compatible. Signed-off-by: Nathaniel McCallum <nathaniel@profian.com>
3 years ago
"io-extras",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"thiserror",
wasi-common: switch all logs from `log` to `tracing` tracing is already the dep that wiggle uses. I used tracing structured arguments wherever I could, but I skipped over it in all of the snapshot_0 code, because I'm going to delete that code and replace it with wiggle-based stuff real soon.
4 years ago
"tracing",
It's wiggle time! (#1202) * Use wiggle in place of wig in wasi-common This is a rather massive commit that introduces `wiggle` into the picture. We still use `wig`'s macro in `old` snapshot and to generate `wasmtime-wasi` glue, but everything else is now autogenerated by `wiggle`. In summary, thanks to `wiggle`, we no longer need to worry about serialising and deserialising to and from the guest memory, and all guest (WASI) types are now proper idiomatic Rust types. While we're here, in preparation for the ephemeral snapshot, I went ahead and reorganised the internal structure of the crate. Instead of modules like `hostcalls_impl` or `hostcalls_impl::fs`, the structure now resembles that in ephemeral with modules like `path`, `fd`, etc. Now, I'm not requiring we leave it like this, but I reckon it looks cleaner this way after all. * Fix wig to use new first-class access to caller's mem * Ignore warning in proc_exit for the moment * Group unsafes together in args and environ calls * Simplify pwrite; more unsafe blocks * Simplify fd_read * Bundle up unsafes in fd_readdir * Simplify fd_write * Add comment to path_readlink re zero-len buffers * Simplify unsafes in random_get * Hide GuestPtr<str> to &str in path::get * Rewrite pread and pwrite using SeekFrom and read/write_vectored I've left the implementation of VirtualFs pretty much untouched as I don't feel that comfortable in changing the API too much. Having said that, I reckon `pread` and `pwrite` could be refactored out, and `preadv` and `pwritev` could be entirely rewritten using `seek` and `read_vectored` and `write_vectored`. * Add comment about VirtFs unsafety * Fix all mentions of FdEntry to Entry * Fix warnings on Win * Add aux struct EntryTable responsible for Fds and Entries This commit adds aux struct `EntryTable` which is private to `WasiCtx` and is basically responsible for `Fd` alloc/dealloc as well as storing matching `Entry`s. This struct is entirely private to `WasiCtx` and as such as should remain transparent to `WasiCtx` users. * Remove redundant check for empty buffer in path_readlink * Preserve and rewind file cursor in pread/pwrite * Use GuestPtr<[u8]>::copy_from_slice wherever copying bytes directly * Use GuestPtr<[u8]>::copy_from_slice in fd_readdir * Clean up unsafes around WasiCtx accessors * Fix bugs in args_get and environ_get * Fix conflicts after rebase
5 years ago
"wiggle",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "wasi-crypto"
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
version = "0.1.5"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"aes-gcm",
"anyhow",
"bincode",
"byteorder",
"chacha20poly1305",
"curve25519-dalek",
"derivative",
"ed25519-dalek",
"hkdf",
"hmac",
"k256",
"p256",
"parking_lot",
"pqcrypto",
"rand_core 0.5.1",
Update wasi-crypto crate This pulls more recent versions of its dependencies.
3 years ago
"rand_core 0.6.3",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"rsa",
"serde",
"sha2",
"subtle",
"thiserror",
"xoodyak",
"zeroize",
]
wasi-cap-std-async is better named wasi-tokio
4 years ago
[[package]]
name = "wasi-tokio"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
wasi-cap-std-async is better named wasi-tokio
4 years ago
dependencies = [
wasi-tokio kinda sorta working
4 years ago
"anyhow",
use tokio's File with a cap-std Dir
4 years ago
"cap-std",
wasi-tokio kinda sorta working
4 years ago
"cap-tempfile",
Implement `sock_accept` With the addition of `sock_accept()` in `wasi-0.11.0`, wasmtime can now implement basic networking for pre-opened sockets. For Windows `AsHandle` was replaced with `AsRawHandleOrSocket` to cope with the duality of Handles and Sockets. For Unix a `wasi_cap_std_sync::net::Socket` enum was created to handle the {Tcp,Unix}{Listener,Stream} more efficiently in `WasiCtxBuilder::preopened_socket()`. The addition of that many `WasiFile` implementors was mainly necessary, because of the difference in the `num_ready_bytes()` function. A known issue is Windows now busy polling on sockets, because except for `stdin`, nothing is querying the status of windows handles/sockets. Another know issue on Windows, is that there is no crate providing support for `fcntl(fd, F_GETFL, 0)` on a socket. Signed-off-by: Harald Hoyer <harald@profian.com>
3 years ago
"io-extras",
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"io-lifetimes",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
use tokio's File with a cap-std Dir
4 years ago
"tempfile",
wasi-cap-std-async is better named wasi-tokio
4 years ago
"tokio",
"wasi-cap-std-sync",
"wasi-common",
"wiggle",
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "wasm-bindgen"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.80"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "27370197c907c55e3f1a9fbe26f44e937fe6451368324e009cba39e139dc08ad"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
"wasm-bindgen-macro",
]
[[package]]
name = "wasm-bindgen-backend"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.80"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "53e04185bfa3a779273da532f5025e33398409573f348985af9a1cbf3774d3f4"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"bumpalo",
"lazy_static",
"log",
"proc-macro2",
"quote",
"syn",
"wasm-bindgen-shared",
]
[[package]]
name = "wasm-bindgen-macro"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.80"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "17cae7ff784d7e83a2fe7611cfe766ecf034111b49deb850a3dc7699c08251f5"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"quote",
"wasm-bindgen-macro-support",
]
[[package]]
name = "wasm-bindgen-macro-support"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.80"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "99ec0dc7a4756fffc231aab1b9f2f578d23cd391390ab27f952ae0c9b3ece20b"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"proc-macro2",
"quote",
"syn",
"wasm-bindgen-backend",
"wasm-bindgen-shared",
]
[[package]]
name = "wasm-bindgen-shared"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.2.80"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "d554b7f530dee5964d9a9468d95c1f8b8acae4f282807e7d27d4b03099a46744"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
[[package]]
name = "wasm-encoder"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
version = "0.18.0"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
checksum = "c64ac98d5d61192cc45c701b7e4bd0b9aff91e2edfc7a088406cfe2288581e2c"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
dependencies = [
"leb128",
]
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
[[package]]
name = "wasm-mutate"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
version = "0.2.9"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
checksum = "00f7cead43549f0307a400df44218c00ccd9b275ed87edb8862b99b000dc9011"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
dependencies = [
"egg",
"log",
"rand 0.8.5",
"thiserror",
"wasm-encoder",
"wasmparser",
]
Add a fuzz target for instantiating `wasm-smith` modules
4 years ago
[[package]]
name = "wasm-smith"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
version = "0.11.6"
Add a fuzz target for instantiating `wasm-smith` modules
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
checksum = "16f88ad106766ae5817d526cbf70576e4fdb4356ccf6814adff5a8553964feba"
Add a fuzz target for instantiating `wasm-smith` modules
4 years ago
dependencies = [
"arbitrary",
Update wasm-{smith,encoder} (#3835) Ended up being a routine update but seemed good to go ahead and hook up updates. While I was at it I went ahead and hooked up multi-value swarm fuzzing as well now that wasm-smith implements it.
3 years ago
"flagset",
Update support for the module linking proposal This commit updates the various tooling used by wasmtime which has new updates to the module linking proposal. This is done primarily to sync with WebAssembly/module-linking#26. The main change implemented here is that wasmtime now supports creating instances from a set of values, nott just from instantiating a module. Additionally subtyping handling of modules with respect to imports is now properly handled by desugaring two-level imports to imports of instances. A number of small refactorings are included here as well, but most of them are in accordance with the changes to `wasmparser` and the updated binary format for module linking.
4 years ago
"indexmap",
Add a fuzz target for instantiating `wasm-smith` modules
4 years ago
"leb128",
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
"wasm-encoder",
Update wasm-tools crates (#3997) * Update wasm-tools crates This commit updates the wasm-tools family of crates as used in Wasmtime. Notably this brings in the update which removes module linking support as well as a number of internal refactorings around names and such within wasmparser itself. This updates all of the wasm translation support which binds to wasmparser as appropriate. Other crates all had API-compatible changes for at least what Wasmtime used so no further changes were necessary beyond updating version requirements. * Update a test expectation
3 years ago
"wasmparser",
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
]
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
[[package]]
name = "wasm-spec-interpreter"
version = "0.1.0"
dependencies = [
"ocaml-interop",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"once_cell",
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
"wat",
]
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
[[package]]
name = "wasmi"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
version = "0.11.0"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
checksum = "0a3cb58f98e4d6c944af18c2c9002f22d0b928dfbb8b6c2b7d78a8573a5216bf"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
dependencies = [
"downcast-rs",
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
"libm",
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
"memory_units",
"num-rational",
"num-traits",
"parity-wasm",
"wasmi-validation",
]
[[package]]
name = "wasmi-validation"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
version = "0.4.1"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasmi used for differential fuzzing (#4436) This fixes a bug recently found on oss-fuzz which was fixed in paritytech/wasmi#295 and paritytech/wasmi#293.
2 years ago
checksum = "165343ecd6c018fc09ebcae280752702c9a2ef3e6f8d02f1cfcbdb53ef6d7937"
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
dependencies = [
"parity-wasm",
Add a fuzz target for instantiating `wasm-smith` modules
4 years ago
]
Write ELF image and instantiate code_memory from it (#1931) - Create the ELF image from Compilation - Create CodeMemory from the ELF image - Link using ELF image - Remove creation of GDB JIT images from crates/debug - Move make_trampoline from compiler.rs
4 years ago
[[package]]
name = "wasmparser"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
version = "0.92.0"
Write ELF image and instantiate code_memory from it (#1931) - Create the ELF image from Compilation - Create CodeMemory from the ELF image - Link using ELF image - Remove creation of GDB JIT images from crates/debug - Move make_trampoline from compiler.rs
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
checksum = "7da34cec2a8c23db906cdf8b26e988d7a7f0d549eb5d51299129647af61a1b37"
Update wasm-tools crates (#3997) * Update wasm-tools crates This commit updates the wasm-tools family of crates as used in Wasmtime. Notably this brings in the update which removes module linking support as well as a number of internal refactorings around names and such within wasmparser itself. This updates all of the wasm translation support which binds to wasmparser as appropriate. Other crates all had API-compatible changes for at least what Wasmtime used so no further changes were necessary beyond updating version requirements. * Update a test expectation
3 years ago
dependencies = [
"indexmap",
]
Support wasm `select` instruction with V128-typed operands on AArch64. * this requires upgrading to wasmparser 0.67.0. * There are no CLIF side changes because the CLIF `select` instruction is polymorphic enough. * on aarch64, there is unfortunately no conditional-move (csel) instruction on vectors. This patch adds a synthetic instruction `VecCSel` which *does* behave like that. At emit time, this is emitted as an if-then-else diamond (4 insns). * aarch64 implementation is otherwise straightforwards.
4 years ago
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "wasmprinter"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
version = "0.2.41"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
checksum = "ca4374ec27194a12b85aa0e1681a42d5800e97f11c036fa85dea8087c8ccb10b"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"anyhow",
upgrade all wasmparser to 0.71 new simd instructions are left as ubsupported in cranelift-wasm
4 years ago
"wasmparser",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "wasmtime"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"anyhow",
give sychronous ResourceLimiter an async alternative
3 years ago
"async-trait",
Serialize and deserialize compilation artifacts. (#2020) * Serialize and deserialize Module * Use bincode to serialize * Add wasm_module_serialize; docs * Simple tests
4 years ago
"bincode",
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Implement strings in adapter modules (#4623) * Implement strings in adapter modules This commit is a hefty addition to Wasmtime's support for the component model. This implements the final remaining type (in the current type hierarchy) unimplemented in adapter module trampolines: strings. Strings are the most complicated type to implement in adapter trampolines because they are highly structured chunks of data in memory (according to specific encodings). Additionally each lift/lower operation can choose its own encoding for strings meaning that Wasmtime, the host, may have to convert between any pairwise ordering of string encodings. The `CanonicalABI.md` in the component-model repo in general specifies all the fiddly bits of string encoding so there's not a ton of wiggle room for Wasmtime to get creative. This PR largely "just" implements that. The high-level architecture of this implementation is: * Fused adapters are first identified to determine src/dst string encodings. This statically fixes what transcoding operation is being performed. * The generated adapter will be responsible for managing calls to `realloc` and performing bounds checks. The adapter itself does not perform memory copies or validation of string contents, however. Instead each transcoding operation is modeled as an imported function into the adapter module. This means that the adapter module dynamically, during compile time, determines what string transcoders are needed. Note that an imported transcoder is not only parameterized over the transcoding operation but additionally which memory is the source and which is the destination. * The imported core wasm functions are modeled as a new `CoreDef::Transcoder` structure. These transcoders end up being small Cranelift-compiled trampolines. The Cranelift-compiled trampoline will load the actual base pointer of memory and add it to the relative pointers passed as function arguments. This trampoline then calls a transcoder "libcall" which enters Rust-defined functions for actual transcoding operations. * Each possible transcoding operation is implemented in Rust with a unique name and a unique signature depending on the needs of the transcoder. I've tried to document inline what each transcoder does. This means that the `Module::translate_string` in adapter modules is by far the largest translation method. The main reason for this is due to the management around calling the imported transcoder functions in the face of validating string pointer/lengths and performing the dance of `realloc`-vs-transcode at the right time. I've tried to ensure that each individual case in transcoding is documented well enough to understand what's going on as well. Additionally in this PR is a full implementation in the host for the `latin1+utf16` encoding which means that both lifting and lowering host strings now works with this encoding. Currently the implementation of each transcoder function is likely far from optimal. Where possible I've leaned on the standard library itself and for latin1-related things I'm leaning on the `encoding_rs` crate. I initially tried to implement everything with `encoding_rs` but was unable to uniformly do so easily. For now I settled on trying to get a known-correct (even in the face of endianness) implementation for all of these transcoders. If an when performance becomes an issue it should be possible to implement more optimized versions of each of these transcoding operations. Testing this commit has been somewhat difficult and my general plan, like with the `(list T)` type, is to rely heavily on fuzzing to cover the various cases here. In this PR though I've added a simple test that pushes some statically known strings through all the pairs of encodings between source and destination. I've attempted to pick "interesting" strings that one way or another stress the various paths in each transcoding operation to ideally get full branch coverage there. Additionally a suite of "negative" tests have also been added to ensure that validity of encoding is actually checked. * Fix a temporarily commented out case * Fix wasmtime-runtime tests * Update deny.toml configuration * Add `BSD-3-Clause` for the `encoding_rs` crate * Remove some unused licenses * Add an exemption for `encoding_rs` for now * Split up the `translate_string` method Move out all the closures and package up captured state into smaller lists of arguments. * Test out-of-bounds for zero-length strings
2 years ago
"encoding_rs",
Implement imported/exported modules/instances (#2461) * Implement imported/exported modules/instances This commit implements the final piece of the module linking proposal which is to flesh out the support for importing/exporting instances and modules. This ended up having a few changes: * Two more `PrimaryMap` instances are now stored in an `Instance`. The value for instances is `InstanceHandle` (pretty easy) and for modules it's `Box<dyn Any>` (less easy). * The custom host state for `InstanceHandle` for `wasmtime` is now `Arc<TypeTables` to be able to fully reconstruct an instance's types just from its instance. * Type matching for imports now has been updated to take instances/modules into account. One of the main downsides of this implementation is that type matching of imports is duplicated between wasmparser and wasmtime, leading to posssible bugs especially in the subtelties of module linking. I'm not sure how best to unify these two pieces of validation, however, and it may be more trouble than it's worth. cc #2094 * Update wat/wast/wasmparser * Review comments * Fix a bug in publish script to vendor the right witx Currently there's two witx binaries in our repository given the two wasi spec submodules, so this updates the publication script to vendor the right one.
4 years ago
"indexmap",
Update Cargo.lock. Cargo.lock is checked into the repositoryu now, so we need to explicitly keep it up to date.
5 years ago
"libc",
Linker refactoring (#1773) * Minor code tidying. * Document that `Linker::iter`'s iteration order is arbitrary. * Add a few more tests for `wasmtime::Linker`. * Refactor `Linker::compute_imports`. - Extract the error message generation into a separate function. - In the error message, sort the candidates. * Fix a typo in a comment. * Add `__rtti_base` to the list of allowed but deprecated exports. * Don't print an Error message when a program exits normally. * Update comments to reflect the current code. * Also allow "table" as an exported table, which is used by AssemblyScript.
5 years ago
"log",
Use an mmap-friendly serialization format (#3257) * Use an mmap-friendly serialization format This commit reimplements the main serialization format for Wasmtime's precompiled artifacts. Previously they were generally a binary blob of `bincode`-encoded metadata prefixed with some versioning information. The downside of this format, though, is that loading a precompiled artifact required pushing all information through `bincode`. This is inefficient when some data, such as trap/address tables, are rarely accessed. The new format added in this commit is one which is designed to be `mmap`-friendly. This means that the relevant parts of the precompiled artifact are already page-aligned for updating permissions of pieces here and there. Additionally the artifact is optimized so that if data is rarely read then we can delay reading it until necessary. The new artifact format for serialized modules is an ELF file. This is not a public API guarantee, so it cannot be relied upon. In the meantime though this is quite useful for exploring precompiled modules with standard tooling like `objdump`. The ELF file is already constructed as part of module compilation, and this is the main contents of the serialized artifact. THere is some extra information, though, not encoded in each module's individual ELF file such as type information. This information continues to be `bincode`-encoded, but it's intended to be much smaller and much faster to deserialize. This extra information is appended to the end of the ELF file. This means that the original ELF file is still a valid ELF file, we just get to have extra bits at the end. More information on the new format can be found in the module docs of the serialization module of Wasmtime. Another refatoring implemented as part of this commit is to deserialize and store object files directly in `mmap`-backed storage. This avoids the need to copy bytes after the artifact is loaded into memory for each compiled module, and in a future commit it opens up the door to avoiding copying the text section into a `CodeMemory`. For now, though, the main change is that copies are not necessary when loading from a precompiled compilation artifact once the artifact is itself in mmap-based memory. To assist with managing `mmap`-based memory a new `MmapVec` type was added to `wasmtime_jit` which acts as a form of `Vec<T>` backed by a `wasmtime_runtime::Mmap`. This type notably supports `drain(..N)` to slice the buffer into disjoint regions that are all separately owned, such as having a separately owned window into one artifact for all object files contained within. Finally this commit implements a small refactoring in `wasmtime-cache` to use the standard artifact format for cache entries rather than a bincode-encoded version. This required some more hooks for serializing/deserializing but otherwise the crate still performs as before. * Review comments
3 years ago
"object",
Make memfd image creation lazy (on first instantiation). As a followup to the recent memfd allocator work, this PR makes the memfd image creation occur on the first instantiation, rather than immediately when the `Module` is loaded. This shaves off a potentially surprising cost spike that would have otherwise occurred: prior to the memfd work, no allocator eagerly read the module's initial heap state into RAM. The behavior should now more closely resemble what happened before (and the improvements in overall instantiation time and performance, as compared to either eager init with pure-mmap memory or user-mode pagefault handling with uffd, remain).
3 years ago
"once_cell",
Implement support for `async` functions in Wasmtime (#2434) * Implement support for `async` functions in Wasmtime This is an implementation of [RFC 2] in Wasmtime which is to support `async`-defined host functions. At a high level support is added by executing WebAssembly code that might invoke an asynchronous host function on a separate native stack. When the host function's future is not ready we switch back to the main native stack to continue execution. There's a whole bunch of details in this commit, and it's a bit much to go over them all here in this commit message. The most important changes here are: * A new `wasmtime-fiber` crate has been written to manage the low-level details of stack-switching. Unixes use `mmap` to allocate a stack and Windows uses the native fibers implementation. We'll surely want to refactor this to move stack allocation elsewhere in the future. Fibers are intended to be relatively general with a lot of type paremters to fling values back and forth across suspension points. The whole crate is a giant wad of `unsafe` unfortunately and involves handwritten assembly with custom dwarf CFI directives to boot. Definitely deserves a close eye in review! * The `Store` type has two new methods -- `block_on` and `on_fiber` which bridge between the async and non-async worlds. Lots of unsafe fiddly bits here as we're trying to communicate context pointers between disparate portions of the code. Extra eyes and care in review is greatly appreciated. * The APIs for binding `async` functions are unfortunately pretty ugly in `Func`. This is mostly due to language limitations and compiler bugs (I believe) in Rust. Instead of `Func::wrap` we have a `Func::wrapN_async` family of methods, and we've also got a whole bunch of `Func::getN_async` methods now too. It may be worth rethinking the API of `Func` to try to make the documentation page actually grok'able. This isn't super heavily tested but the various test should suffice for engaging hopefully nearly all the infrastructure in one form or another. This is just the start though! [RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2 * Add wasmtime-fiber to publish script * Save vector/float registers on ARM too. * Fix a typo * Update lock file * Implement periodically yielding with fuel consumption This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures. * Fix compile without async * Save/restore the frame pointer in fiber switching Turns out this is another caller-saved register! * Simplify x86_64 fiber asm Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses. * Add x86 support to wasmtime-fiber * Add ARM32 support to fiber crate * Make fiber build file probing more flexible * Use CreateFiberEx on Windows * Remove a stray no-longer-used trait declaration * Don't reach into `Caller` internals * Tweak async fuel to eventually run out. With fuel it's probably best to not provide any way to inject infinite fuel. * Fix some typos * Cleanup asm a bit * Use a shared header file to deduplicate some directives * Guarantee hidden visibility for functions * Enable gc-sections on macOS x86_64 * Add `.type` annotations for ARM * Update lock file * Fix compile error * Review comments
4 years ago
"paste",
More optimizations for calling into WebAssembly (#2759) * Combine stack-based cleanups for faster wasm calls This commit is an extension of #2757 where the goal is to optimize entry into WebAssembly. Currently wasmtime has two stack-based cleanups when entering wasm, one for the externref activation table and another for stack limits getting reset. This commit fuses these two cleanups together into one and moves some code around which enables less captures for fewer closures and such to speed up calls in to wasm a bit more. Overall this drops the execution time from 88ns to 80ns locally for me. This also updates the atomic orderings when updating the stack limit from `SeqCst` to `Relaxed`. While `SeqCst` is a reasonable starting point the usage here should be safe to use `Relaxed` since we're not using the atomics to actually protect any memory, it's simply receiving signals from other threads. * Determine whether a pc is wasm via a global map The macOS implementation of traps recently changed to using mach ports for handlers instead of signal handlers. This means that a previously relied upon invariant, each thread fixes its own trap, was broken. The macOS implementation worked around this by maintaining a global map from thread id to thread local information, however, to solve the problem. This global map is quite slow though. It involves taking a lock and updating a hash map on all calls into WebAssembly. In my local testing this accounts for >70% of the overhead of calling into WebAssembly on macOS. Naturally it'd be great to remove this! This commit fixes this issue and removes the global lock/map that is updated on all calls into WebAssembly. The fix is to maintain a global map of wasm modules and their trap addresses in the `wasmtime` crate. Doing so is relatively simple since we're already tracking this information at the `Store` level. Once we've got a global map then the macOS implementation can use this from a foreign thread and everything works out. Locally this brings the overhead, on macOS specifically, of calling into wasm from 80ns to ~20ns. * Fix compiles * Review comments
4 years ago
"psm",
Add a cranelift compile-time feature to wasmtime (#3206) * Remove unnecessary into_iter/map Forgotten from a previous refactoring, this variable was already of the right type! * Move `wasmtime_jit::Compiler` into `wasmtime` This `Compiler` struct is mostly a historical artifact at this point and wasn't necessarily pulling much weight any more. This organization also doesn't lend itself super well to compiling out `cranelift` when the `Compiler` here is used for both parallel iteration configuration settings as well as compilation. The movement into `wasmtime` is relatively small, with `Module::build_artifacts` being the main function added here which is a merging of the previous functions removed from the `wasmtime-jit` crate. * Add a `cranelift` compile-time feature to `wasmtime` This commit concludes the saga of refactoring Wasmtime and making Cranelift an optional dependency by adding a new Cargo feature to the `wasmtime` crate called `cranelift`, which is enabled by default. This feature is implemented by having a new cfg for `wasmtime` itself, `cfg(compiler)`, which is used wherever compilation is necessary. This bubbles up to disable APIs such as `Module::new`, `Func::new`, `Engine::precompile_module`, and a number of `Config` methods affecting compiler configuration. Checks are added to CI that when built in this mode Wasmtime continues to successfully build. It's hoped that although this is effectively "sprinkle `#[cfg]` until things compile" this won't be too too bad to maintain over time since it's also an use case we're interested in supporting. With `cranelift` disabled the only way to create a `Module` is with the `Module::deserialize` method, which requires some form of precompiled artifact. Two consequences of this change are: * `Module::serialize` is also disabled in this mode. The reason for this is that serialized modules contain ISA/shared flags encoded in them which were used to produce the compiled code. There's no storage for this if compilation is disabled. This could probably be re-enabled in the future if necessary, but it may not end up being all that necessary. * Deserialized modules are not checked to ensure that their ISA/shared flags are compatible with the host CPU. This is actually already the case, though, with normal modules. We'll likely want to fix this in the future using a shared implementation for both these locations. Documentation should be updated to indicate that `cranelift` can be disabled, although it's not really the most prominent documentation because this is expected to be a somewhat niche use case (albeit important, just not too common). * Always enable cranelift for the C API * Fix doc example builds * Fix check tests on GitHub Actions
3 years ago
"rayon",
Serialize and deserialize compilation artifacts. (#2020) * Serialize and deserialize Module * Use bincode to serialize * Add wasm_module_serialize; docs * Simple tests
4 years ago
"serde",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"target-lexicon",
Improve robustness of cache loading/storing (#974) * Improve robustness of cache loading/storing Today wasmtime incorrectly loads compiled compiled modules from the global cache when toggling settings such as optimizations. For example if you execute `wasmtime foo.wasm` that will cache globally an unoptimized version of the wasm module. If you then execute `wasmtime -O foo.wasm` it would then reload the unoptimized version from cache, not realizing the compilation settings were different, and use that instead. This can lead to very surprising behavior naturally! This commit updates how the cache is managed in an attempt to make it much more robust against these sorts of issues. This takes a leaf out of rustc's playbook and models the cache with a function that looks like: fn load<T: Hash>( &self, data: T, compute: fn(T) -> CacheEntry, ) -> CacheEntry; The goal here is that it guarantees that all the `data` necessary to `compute` the result of the cache entry is hashable and stored into the hash key entry. This was previously open-coded and manually managed where items were hashed explicitly, but this construction guarantees that everything reasonable `compute` could use to compile the module is stored in `data`, which is itself hashable. This refactoring then resulted in a few workarounds and a few fixes, including the original issue: * The `Module` type was split into `Module` and `ModuleLocal` where only the latter is hashed. The previous hash function for a `Module` left out items like the `start_func` and didn't hash items like the imports of the module. Omitting the `start_func` was fine since compilation didn't actually use it, but omitting imports seemed uncomfortable because while compilation didn't use the import values it did use the *number* of imports, which seems like it should then be put into the cache key. The `ModuleLocal` type now derives `Hash` to guarantee that all of its contents affect the hash key. * The `ModuleTranslationState` from `cranelift-wasm` doesn't implement `Hash` which means that we have a manual wrapper to work around that. This will be fixed with an upstream implementation, since this state affects the generated wasm code. Currently this is just a map of signatures, which is present in `Module` anyway, so we should be good for the time being. * Hashing `dyn TargetIsa` was also added, where previously it was not fully hashed. Previously only the target name was used as part of the cache key, but crucially the flags of compilation were omitted (for example the optimization flags). Unfortunately the trait object itself is not hashable so we still have to manually write a wrapper to hash it, but we likely want to add upstream some utilities to hash isa objects into cranelift itself. For now though we can continue to add hashed fields as necessary. Overall the goal here was to use the compiler to expose what we're not hashing, and then make sure we organize data and write the right code to ensure everything is hashed, and nothing more. * Update crates/environ/src/module.rs Co-Authored-By: Peter Huene <peterhuene@protonmail.com> * Fix lightbeam * Fix compilation of tests * Update the expected structure of the cache * Revert "Update the expected structure of the cache" This reverts commit 2b53fee426a4e411c313d8c1e424841ba304a9cd. * Separate the cache dir a bit * Add a test the cache is busted with opt levels * rustfmt Co-authored-by: Peter Huene <peterhuene@protonmail.com>
5 years ago
"tempfile",
fix wasmtime doctest
4 years ago
"wasi-cap-std-sync",
upgrade all wasmparser to 0.71 new simd instructions are left as ubsupported in cranelift-wasm
4 years ago
"wasmparser",
Making caching support optional in Wasmtime (#2119) This commit moves all of the caching support that currently lives in `wasmtime-environ` into a `wasmtime-cache` crate and makes it optional. The goal here is to slim down the `wasmtime-environ` crate and clearly separate boundaries where caching is a standalone and optional feature, not intertwined with other crates.
4 years ago
"wasmtime-cache",
add ComponentType/Lift/Lower derive macro for record types (#4337) This is the first stage of implementing https://github.com/bytecodealliance/wasmtime/issues/4308, i.e. derive macros for `ComponentType`, `Lift`, and `Lower` for composite types in the component model. This stage only covers records; I expect the other composite types will follow a similar pattern. It borrows heavily from the work Jamey Sharp did in https://github.com/bytecodealliance/wasmtime/pull/4217. Thanks for that, and thanks to both Jamey and Alex Crichton for their excellent review feedback. Thanks also to Brian for pairing up on the initial draft. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"wasmtime-component-macro",
support dynamic function calls in component model (#4442) * support dynamic function calls in component model This addresses #4310, introducing a new `component::values::Val` type for representing component values dynamically, as well as `component::types::Type` for representing the corresponding interface types. It also adds a `call` method to `component::func::Func`, which takes a slice of `Val`s as parameters and returns a `Result<Val>` representing the result. Note that I've moved `post_return` and `call_raw` from `TypedFunc` to `Func` since there was nothing specific to `TypedFunc` about them, and I wanted to reuse them. The code in both is unchanged beyond the trivial tweaks to make them fit in their new home. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * order variants and match cases more consistently Signed-off-by: Joel Dice <joel.dice@fermyon.com> * implement lift for String, Box<str>, etc. This also removes the redundant `store` parameter from `Type::load`. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * implement code review feedback This fixes a few issues: - Bad offset calculation when lowering - Missing variant padding - Style issues regarding `types::Handle` - Missed opportunities to reuse `Lift` and `Lower` impls It also adds forwarding `Lift` impls for `Box<[T]>`, `Vec<T>`, etc. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * move `new_*` methods to specific `types` structs Per review feedback, I've moved `Type::new_record` to `Record::new_val` and added a `Type::unwrap_record` method; likewise for the other kinds of types. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * make tuple, option, and expected type comparisons recursive These types should compare as equal across component boundaries as long as their type parameters are equal. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * improve error diagnostic in `Type::check` We now distinguish between more failure cases to provide an informative error message. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * address review feedback - Remove `WasmStr::to_str_from_memory` and `WasmList::get_from_memory` - add `try_new` methods to various `values` types - avoid using `ExactSizeIterator::len` where we can't trust it - fix over-constrained bounds on forwarded `ComponentType` impls Signed-off-by: Joel Dice <joel.dice@fermyon.com> * rearrange code per review feedback - Move functions from `types` to `values` module so we can make certain struct fields private - Rename `try_new` to just `new` Signed-off-by: Joel Dice <joel.dice@fermyon.com> * remove special-case equality test for tuples, options, and expecteds Instead, I've added a FIXME comment and will open an issue to do recursive structural equality testing. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"wasmtime-component-util",
Add a cranelift compile-time feature to wasmtime (#3206) * Remove unnecessary into_iter/map Forgotten from a previous refactoring, this variable was already of the right type! * Move `wasmtime_jit::Compiler` into `wasmtime` This `Compiler` struct is mostly a historical artifact at this point and wasn't necessarily pulling much weight any more. This organization also doesn't lend itself super well to compiling out `cranelift` when the `Compiler` here is used for both parallel iteration configuration settings as well as compilation. The movement into `wasmtime` is relatively small, with `Module::build_artifacts` being the main function added here which is a merging of the previous functions removed from the `wasmtime-jit` crate. * Add a `cranelift` compile-time feature to `wasmtime` This commit concludes the saga of refactoring Wasmtime and making Cranelift an optional dependency by adding a new Cargo feature to the `wasmtime` crate called `cranelift`, which is enabled by default. This feature is implemented by having a new cfg for `wasmtime` itself, `cfg(compiler)`, which is used wherever compilation is necessary. This bubbles up to disable APIs such as `Module::new`, `Func::new`, `Engine::precompile_module`, and a number of `Config` methods affecting compiler configuration. Checks are added to CI that when built in this mode Wasmtime continues to successfully build. It's hoped that although this is effectively "sprinkle `#[cfg]` until things compile" this won't be too too bad to maintain over time since it's also an use case we're interested in supporting. With `cranelift` disabled the only way to create a `Module` is with the `Module::deserialize` method, which requires some form of precompiled artifact. Two consequences of this change are: * `Module::serialize` is also disabled in this mode. The reason for this is that serialized modules contain ISA/shared flags encoded in them which were used to produce the compiled code. There's no storage for this if compilation is disabled. This could probably be re-enabled in the future if necessary, but it may not end up being all that necessary. * Deserialized modules are not checked to ensure that their ISA/shared flags are compatible with the host CPU. This is actually already the case, though, with normal modules. We'll likely want to fix this in the future using a shared implementation for both these locations. Documentation should be updated to indicate that `cranelift` can be disabled, although it's not really the most prominent documentation because this is expected to be a somewhat niche use case (albeit important, just not too common). * Always enable cranelift for the C API * Fix doc example builds * Fix check tests on GitHub Actions
3 years ago
"wasmtime-cranelift",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime-environ",
Implement support for `async` functions in Wasmtime (#2434) * Implement support for `async` functions in Wasmtime This is an implementation of [RFC 2] in Wasmtime which is to support `async`-defined host functions. At a high level support is added by executing WebAssembly code that might invoke an asynchronous host function on a separate native stack. When the host function's future is not ready we switch back to the main native stack to continue execution. There's a whole bunch of details in this commit, and it's a bit much to go over them all here in this commit message. The most important changes here are: * A new `wasmtime-fiber` crate has been written to manage the low-level details of stack-switching. Unixes use `mmap` to allocate a stack and Windows uses the native fibers implementation. We'll surely want to refactor this to move stack allocation elsewhere in the future. Fibers are intended to be relatively general with a lot of type paremters to fling values back and forth across suspension points. The whole crate is a giant wad of `unsafe` unfortunately and involves handwritten assembly with custom dwarf CFI directives to boot. Definitely deserves a close eye in review! * The `Store` type has two new methods -- `block_on` and `on_fiber` which bridge between the async and non-async worlds. Lots of unsafe fiddly bits here as we're trying to communicate context pointers between disparate portions of the code. Extra eyes and care in review is greatly appreciated. * The APIs for binding `async` functions are unfortunately pretty ugly in `Func`. This is mostly due to language limitations and compiler bugs (I believe) in Rust. Instead of `Func::wrap` we have a `Func::wrapN_async` family of methods, and we've also got a whole bunch of `Func::getN_async` methods now too. It may be worth rethinking the API of `Func` to try to make the documentation page actually grok'able. This isn't super heavily tested but the various test should suffice for engaging hopefully nearly all the infrastructure in one form or another. This is just the start though! [RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2 * Add wasmtime-fiber to publish script * Save vector/float registers on ARM too. * Fix a typo * Update lock file * Implement periodically yielding with fuel consumption This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures. * Fix compile without async * Save/restore the frame pointer in fiber switching Turns out this is another caller-saved register! * Simplify x86_64 fiber asm Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses. * Add x86 support to wasmtime-fiber * Add ARM32 support to fiber crate * Make fiber build file probing more flexible * Use CreateFiberEx on Windows * Remove a stray no-longer-used trait declaration * Don't reach into `Caller` internals * Tweak async fuel to eventually run out. With fuel it's probably best to not provide any way to inject infinite fuel. * Fix some typos * Cleanup asm a bit * Use a shared header file to deduplicate some directives * Guarantee hidden visibility for functions * Enable gc-sections on macOS x86_64 * Add `.type` annotations for ARM * Update lock file * Fix compile error * Review comments
4 years ago
"wasmtime-fiber",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime-jit",
"wasmtime-runtime",
Expand top-level `wasmtime` crate docs (#1955) This is something I meant to do a long time ago but forgot to get around to it! This commit updates the top-level documentation of the `wasmtime` crate to have examples, more words, and generall be a bit more up-to-date and complete.
4 years ago
"wasmtime-wasi",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wat",
Migrate from `winapi` to `windows-sys` (#4346) * Migrate from `winapi` to `windows-sys` I believe that Microsoft itself is supporting the development of `windows-sys` and it's also used by `cap-std` now so this switches Wasmtime's dependencies on Windows APIs from the `winapi` crate to the `windows-sys` crate. We still have `winapi` in our dependency graph but that may get phased out over time. * Make windows-sys a target-specific dependency
2 years ago
"windows-sys",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Split `global_asm!` helper macros out from `wasmtime-fibers` (#4454) This moves them into a new `wasmtime-asm-macros` crate that can be used not just from the `wasmtime-fibers` crate but also from other crates (e.g. we will need them in https://github.com/bytecodealliance/wasmtime/pull/4431).
2 years ago
[[package]]
name = "wasmtime-asm-macros"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Split `global_asm!` helper macros out from `wasmtime-fibers` (#4454) This moves them into a new `wasmtime-asm-macros` crate that can be used not just from the `wasmtime-fibers` crate but also from other crates (e.g. we will need them in https://github.com/bytecodealliance/wasmtime/pull/4431).
2 years ago
dependencies = [
"cfg-if",
]
Introduce benchmarking API The new crate introduced here, `wasmtime-bench-api`, creates a shared library, e.g. `wasmtime_bench_api.so`, for executing Wasm benchmarks using Wasmtime. It allows us to measure several phases separately by exposing `engine_compile_module`, `engine_instantiate_module`, and `engine_execute_module`, which pass around an opaque pointer to the internally initialized state. This state is initialized and freed by `engine_create` and `engine_free`, respectively. The API also introduces a way of passing in functions to satisfy the `"bench" "start"` and `"bench" "end"` symbols that we expect Wasm benchmarks to import. The API is exposed in a C-compatible way so that we can dynamically load it (carefully) in our benchmark runner.
4 years ago
[[package]]
name = "wasmtime-bench-api"
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
version = "2.0.0"
Introduce benchmarking API The new crate introduced here, `wasmtime-bench-api`, creates a shared library, e.g. `wasmtime_bench_api.so`, for executing Wasm benchmarks using Wasmtime. It allows us to measure several phases separately by exposing `engine_compile_module`, `engine_instantiate_module`, and `engine_execute_module`, which pass around an opaque pointer to the internally initialized state. This state is initialized and freed by `engine_create` and `engine_free`, respectively. The API also introduces a way of passing in functions to satisfy the `"bench" "start"` and `"bench" "end"` symbols that we expect Wasm benchmarks to import. The API is exposed in a C-compatible way so that we can dynamically load it (carefully) in our benchmark runner.
4 years ago
dependencies = [
"anyhow",
system-interface 0.6
4 years ago
"cap-std",
wasmtime-bench-api: Randomize the locations of heap objects This helps us avoid measurement bias due to accidental locality of unrelated heap objects. See *Stabilizer: Statistically Sound Performance Evaluation* by Curtsinger and Berger for details (although Stabilizer deals with much more than just the location of heap allocations): https://people.cs.umass.edu/~emery/pubs/stabilizer-asplos13.pdf
4 years ago
"shuffling-allocator",
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
"target-lexicon",
port bench-api
4 years ago
"wasi-cap-std-sync",
Introduce benchmarking API The new crate introduced here, `wasmtime-bench-api`, creates a shared library, e.g. `wasmtime_bench_api.so`, for executing Wasm benchmarks using Wasmtime. It allows us to measure several phases separately by exposing `engine_compile_module`, `engine_instantiate_module`, and `engine_execute_module`, which pass around an opaque pointer to the internally initialized state. This state is initialized and freed by `engine_create` and `engine_free`, respectively. The API also introduces a way of passing in functions to satisfy the `"bench" "start"` and `"bench" "end"` symbols that we expect Wasm benchmarks to import. The API is exposed in a C-compatible way so that we can dynamically load it (carefully) in our benchmark runner.
4 years ago
"wasmtime",
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
"wasmtime-cli-flags",
Introduce benchmarking API The new crate introduced here, `wasmtime-bench-api`, creates a shared library, e.g. `wasmtime_bench_api.so`, for executing Wasm benchmarks using Wasmtime. It allows us to measure several phases separately by exposing `engine_compile_module`, `engine_instantiate_module`, and `engine_execute_module`, which pass around an opaque pointer to the internally initialized state. This state is initialized and freed by `engine_create` and `engine_free`, respectively. The API also introduces a way of passing in functions to satisfy the `"bench" "start"` and `"bench" "end"` symbols that we expect Wasm benchmarks to import. The API is exposed in a C-compatible way so that we can dynamically load it (carefully) in our benchmark runner.
4 years ago
"wasmtime-wasi",
Optionally compile wasmtime-bench-api with wasi-nn and wasi-crypto (#2677) This adds the ability to add feature flags (e.g. `--features wasi-nn`) when compiling `wasmtime-bench-api` to allow benchmarking Wasmtime with WASI proposals included. Note that due to https://github.com/rust-lang/cargo/issues/5364, these features are only available: - in the `crates/bench-api` directory, e.g. `pushd crates/bench-api; cargo build --features wasi-crypto` - or from the top-level project directory using `-Zpackage-features`, e.g. `OPENVINO_INSTALL_DIR=/opt/intel/openvino cargo +nightly build -p wasmtime-bench-api -Zpackage-features --features wasi-nn`
4 years ago
"wasmtime-wasi-crypto",
"wasmtime-wasi-nn",
Introduce benchmarking API The new crate introduced here, `wasmtime-bench-api`, creates a shared library, e.g. `wasmtime_bench_api.so`, for executing Wasm benchmarks using Wasmtime. It allows us to measure several phases separately by exposing `engine_compile_module`, `engine_instantiate_module`, and `engine_execute_module`, which pass around an opaque pointer to the internally initialized state. This state is initialized and freed by `engine_create` and `engine_free`, respectively. The API also introduces a way of passing in functions to satisfy the `"bench" "start"` and `"bench" "end"` symbols that we expect Wasm benchmarks to import. The API is exposed in a C-compatible way so that we can dynamically load it (carefully) in our benchmark runner.
4 years ago
"wat",
]
Move the C API to a separate crate (#818) * Move the C API to a separate crate This commit moves the C API from `crates/api/src/wasm.rs` to `crates/capi/src/lib.rs` to be located in a separate crate. There's a number of reasons for this: * When a Rust program depends on the `wasmtime` crate, there's no need to compile in the C API. * This should improve compile times of the `wasmtime` crate since it's not producing artifacts which aren't always used. * The development of the C API can be guaranteed to only use the public API of the `wasmtime` crate itself. Some CI pieces are tweaked and this overall shouldn't have much impact on users, it's intended that it's a cleanup/speedup for developers! * Disable rustdoc/tests for capi * Review feedback * Add back in accidentally deleted comment * More renamings * Try to fix dotnet build
5 years ago
[[package]]
name = "wasmtime-c-api"
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
version = "2.0.0"
Move the C API to a separate crate (#818) * Move the C API to a separate crate This commit moves the C API from `crates/api/src/wasm.rs` to `crates/capi/src/lib.rs` to be located in a separate crate. There's a number of reasons for this: * When a Rust program depends on the `wasmtime` crate, there's no need to compile in the C API. * This should improve compile times of the `wasmtime` crate since it's not producing artifacts which aren't always used. * The development of the C API can be guaranteed to only use the public API of the `wasmtime` crate itself. Some CI pieces are tweaked and this overall shouldn't have much impact on users, it's intended that it's a cleanup/speedup for developers! * Disable rustdoc/tests for capi * Review feedback * Add back in accidentally deleted comment * More renamings * Try to fix dotnet build
5 years ago
dependencies = [
Add a `wasmtime::Linker` type (#1384) * Add a `wasmtime::Linker` type This commit adds a new type to the `wasmtime` crate, a `Linker`. This linker is intended to vastly simplify calling `Instance::new` by easily performing name resolution and incrementally defining state over time. The goal here is to start down a path of making linking wasm modules in `wasmtime` a first-class and ergonomic operation. This is highly likely to evolve over time and get tweaked through releases as we iterate towards a design well-suited for `wasmtime`, but this is intended to at least be the initial foundation for such functionality. This commit additionally also adds a C API for the linker and switches the existing linking examples to using this linker in both Rust and C. One piece of future work I'd like to tackle next is to integrate WASI into the `wasmtime` crate in a more first-class manner. This [`Linker`] type provides a great location to hook into the instantiation process to easily instantiate modules with WASI imports. That's a relatively large refactoring for now though and I figured it'd be best left for a different time. Closes #727
5 years ago
"anyhow",
system-interface 0.6
4 years ago
"cap-std",
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
"env_logger 0.9.0",
Refactor and fill out wasmtime's C API (#1415) * Refactor and improve safety of C API This commit is intended to be a relatively large refactoring of the C API which is targeted at improving the safety of our C API definitions. Not all of the APIs have been updated yet but this is intended to be the start. The goal here is to make as many functions safe as we can, expressing inputs/outputs as native Rust types rather than raw pointers wherever possible. For example instead of `*const wasm_foo_t` we'd take `&wasm_foo_t`. Instead of returning `*mut wasm_foo_t` we'd return `Box<wasm_foo_t>`. No ABI/API changes are intended from this commit, it's supposed to only change how we define all these functions internally. This commit also additionally implements a few more API bindings for exposed vector types by unifying everything into one macro. Finally, this commit moves many internal caches in the C API to the `OnceCell` type which provides a safe interface for one-time initialization. * Split apart monolithic C API `lib.rs` This commit splits the monolithic `src/lib.rs` in the C API crate into lots of smaller files. The goal here is to make this a bit more readable and digestable. Each module now contains only API bindings for a particular type, roughly organized around the grouping in the wasm.h header file already. A few more extensions were added, such as filling out `*_as_*` conversions with both const and non-const versions. Additionally many APIs were made safer in the same style as the previous commit, generally preferring Rust types rather than raw pointer types. Overall no functional change is intended here, it should be mostly just code movement and minor refactorings! * Make a few wasi C bindings safer Use safe Rust types where we can and touch up a few APIs here and there. * Implement `wasm_*type_as_externtype*` APIs This commit restructures `wasm_externtype_t` to be similar to `wasm_extern_t` so type conversion between the `*_extern_*` variants to the concrete variants are all simple casts. (checked in the case of general to concrete, of course). * Consistently imlpement host info functions in the API This commit adds a small macro crate which is then used to consistently define the various host-info-related functions in the C API. The goal here is to try to mirror what the `wasm.h` header provides to provide a full implementation of the header.
5 years ago
"once_cell",
integrate with c-api
4 years ago
"wasi-cap-std-sync",
Move the C API to a separate crate (#818) * Move the C API to a separate crate This commit moves the C API from `crates/api/src/wasm.rs` to `crates/capi/src/lib.rs` to be located in a separate crate. There's a number of reasons for this: * When a Rust program depends on the `wasmtime` crate, there's no need to compile in the C API. * This should improve compile times of the `wasmtime` crate since it's not producing artifacts which aren't always used. * The development of the C API can be guaranteed to only use the public API of the `wasmtime` crate itself. Some CI pieces are tweaked and this overall shouldn't have much impact on users, it's intended that it's a cleanup/speedup for developers! * Disable rustdoc/tests for capi * Review feedback * Add back in accidentally deleted comment * More renamings * Try to fix dotnet build
5 years ago
"wasmtime",
Refactor and fill out wasmtime's C API (#1415) * Refactor and improve safety of C API This commit is intended to be a relatively large refactoring of the C API which is targeted at improving the safety of our C API definitions. Not all of the APIs have been updated yet but this is intended to be the start. The goal here is to make as many functions safe as we can, expressing inputs/outputs as native Rust types rather than raw pointers wherever possible. For example instead of `*const wasm_foo_t` we'd take `&wasm_foo_t`. Instead of returning `*mut wasm_foo_t` we'd return `Box<wasm_foo_t>`. No ABI/API changes are intended from this commit, it's supposed to only change how we define all these functions internally. This commit also additionally implements a few more API bindings for exposed vector types by unifying everything into one macro. Finally, this commit moves many internal caches in the C API to the `OnceCell` type which provides a safe interface for one-time initialization. * Split apart monolithic C API `lib.rs` This commit splits the monolithic `src/lib.rs` in the C API crate into lots of smaller files. The goal here is to make this a bit more readable and digestable. Each module now contains only API bindings for a particular type, roughly organized around the grouping in the wasm.h header file already. A few more extensions were added, such as filling out `*_as_*` conversions with both const and non-const versions. Additionally many APIs were made safer in the same style as the previous commit, generally preferring Rust types rather than raw pointer types. Overall no functional change is intended here, it should be mostly just code movement and minor refactorings! * Make a few wasi C bindings safer Use safe Rust types where we can and touch up a few APIs here and there. * Implement `wasm_*type_as_externtype*` APIs This commit restructures `wasm_externtype_t` to be similar to `wasm_extern_t` so type conversion between the `*_extern_*` variants to the concrete variants are all simple casts. (checked in the case of general to concrete, of course). * Consistently imlpement host info functions in the API This commit adds a small macro crate which is then used to consistently define the various host-info-related functions in the C API. The goal here is to try to mirror what the `wasm.h` header provides to provide a full implementation of the header.
5 years ago
"wasmtime-c-api-macros",
Implement WASI C API. This commit implements an initial WASI C API that can be used to instantiate and configure a WASI instance from C. This also implements a `WasiBuilder` for the C# API enabling .NET hosts to bind to Wasmtime's WASI implementation.
5 years ago
"wasmtime-wasi",
Add a wasmtime-specific `wasmtime_wat2wasm` C API (#1206) * Add a wasmtime-specific `wasmtime_wat2wasm` C API This commit implements a wasmtime-specific C API for converting the text format to the binary format. An upstream spec issue exists for adding this to the C API, but in the meantime we can experiment with our own version of this API and use it in the C# extension, for example! Closes #1000 * Reorder arguments * Use wasm_byte_vec_t for input `*.wat` * Mark wat input as const * Return an error message and use `fixed` * Actually include the error message * Use `fixed` in `Module.cs` as well
5 years ago
"wat",
Move the C API to a separate crate (#818) * Move the C API to a separate crate This commit moves the C API from `crates/api/src/wasm.rs` to `crates/capi/src/lib.rs` to be located in a separate crate. There's a number of reasons for this: * When a Rust program depends on the `wasmtime` crate, there's no need to compile in the C API. * This should improve compile times of the `wasmtime` crate since it's not producing artifacts which aren't always used. * The development of the C API can be guaranteed to only use the public API of the `wasmtime` crate itself. Some CI pieces are tweaked and this overall shouldn't have much impact on users, it's intended that it's a cleanup/speedup for developers! * Disable rustdoc/tests for capi * Review feedback * Add back in accidentally deleted comment * More renamings * Try to fix dotnet build
5 years ago
]
Refactor and fill out wasmtime's C API (#1415) * Refactor and improve safety of C API This commit is intended to be a relatively large refactoring of the C API which is targeted at improving the safety of our C API definitions. Not all of the APIs have been updated yet but this is intended to be the start. The goal here is to make as many functions safe as we can, expressing inputs/outputs as native Rust types rather than raw pointers wherever possible. For example instead of `*const wasm_foo_t` we'd take `&wasm_foo_t`. Instead of returning `*mut wasm_foo_t` we'd return `Box<wasm_foo_t>`. No ABI/API changes are intended from this commit, it's supposed to only change how we define all these functions internally. This commit also additionally implements a few more API bindings for exposed vector types by unifying everything into one macro. Finally, this commit moves many internal caches in the C API to the `OnceCell` type which provides a safe interface for one-time initialization. * Split apart monolithic C API `lib.rs` This commit splits the monolithic `src/lib.rs` in the C API crate into lots of smaller files. The goal here is to make this a bit more readable and digestable. Each module now contains only API bindings for a particular type, roughly organized around the grouping in the wasm.h header file already. A few more extensions were added, such as filling out `*_as_*` conversions with both const and non-const versions. Additionally many APIs were made safer in the same style as the previous commit, generally preferring Rust types rather than raw pointer types. Overall no functional change is intended here, it should be mostly just code movement and minor refactorings! * Make a few wasi C bindings safer Use safe Rust types where we can and touch up a few APIs here and there. * Implement `wasm_*type_as_externtype*` APIs This commit restructures `wasm_externtype_t` to be similar to `wasm_extern_t` so type conversion between the `*_extern_*` variants to the concrete variants are all simple casts. (checked in the case of general to concrete, of course). * Consistently imlpement host info functions in the API This commit adds a small macro crate which is then used to consistently define the various host-info-related functions in the C API. The goal here is to try to mirror what the `wasm.h` header provides to provide a full implementation of the header.
5 years ago
[[package]]
name = "wasmtime-c-api-macros"
Wasmtime 0.19.0 and Cranelift 0.66.0 (#2027) This commit updates Wasmtime's version to 0.19.0, Cranelift's version to 0.66.0, and updates the release notes as well.
4 years ago
version = "0.19.0"
Refactor and fill out wasmtime's C API (#1415) * Refactor and improve safety of C API This commit is intended to be a relatively large refactoring of the C API which is targeted at improving the safety of our C API definitions. Not all of the APIs have been updated yet but this is intended to be the start. The goal here is to make as many functions safe as we can, expressing inputs/outputs as native Rust types rather than raw pointers wherever possible. For example instead of `*const wasm_foo_t` we'd take `&wasm_foo_t`. Instead of returning `*mut wasm_foo_t` we'd return `Box<wasm_foo_t>`. No ABI/API changes are intended from this commit, it's supposed to only change how we define all these functions internally. This commit also additionally implements a few more API bindings for exposed vector types by unifying everything into one macro. Finally, this commit moves many internal caches in the C API to the `OnceCell` type which provides a safe interface for one-time initialization. * Split apart monolithic C API `lib.rs` This commit splits the monolithic `src/lib.rs` in the C API crate into lots of smaller files. The goal here is to make this a bit more readable and digestable. Each module now contains only API bindings for a particular type, roughly organized around the grouping in the wasm.h header file already. A few more extensions were added, such as filling out `*_as_*` conversions with both const and non-const versions. Additionally many APIs were made safer in the same style as the previous commit, generally preferring Rust types rather than raw pointer types. Overall no functional change is intended here, it should be mostly just code movement and minor refactorings! * Make a few wasi C bindings safer Use safe Rust types where we can and touch up a few APIs here and there. * Implement `wasm_*type_as_externtype*` APIs This commit restructures `wasm_externtype_t` to be similar to `wasm_extern_t` so type conversion between the `*_extern_*` variants to the concrete variants are all simple casts. (checked in the case of general to concrete, of course). * Consistently imlpement host info functions in the API This commit adds a small macro crate which is then used to consistently define the various host-info-related functions in the C API. The goal here is to try to mirror what the `wasm.h` header provides to provide a full implementation of the header.
5 years ago
dependencies = [
"proc-macro2",
"quote",
]
Making caching support optional in Wasmtime (#2119) This commit moves all of the caching support that currently lives in `wasmtime-environ` into a `wasmtime-cache` crate and makes it optional. The goal here is to slim down the `wasmtime-environ` crate and clearly separate boundaries where caching is a standalone and optional feature, not intertwined with other crates.
4 years ago
[[package]]
name = "wasmtime-cache"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Making caching support optional in Wasmtime (#2119) This commit moves all of the caching support that currently lives in `wasmtime-environ` into a `wasmtime-cache` crate and makes it optional. The goal here is to slim down the `wasmtime-environ` crate and clearly separate boundaries where caching is a standalone and optional feature, not intertwined with other crates.
4 years ago
dependencies = [
"anyhow",
cargo update
4 years ago
"base64",
Making caching support optional in Wasmtime (#2119) This commit moves all of the caching support that currently lives in `wasmtime-environ` into a `wasmtime-cache` crate and makes it optional. The goal here is to slim down the `wasmtime-environ` crate and clearly separate boundaries where caching is a standalone and optional feature, not intertwined with other crates.
4 years ago
"bincode",
Replace unmaintained directories crate Fixes RUSTSEC-2020-0054 warning from cargo-audit/cargo-deny, follows the recommendation to switch to the new maintained `directories-next` crate fork Only affects the cache directory determination for the environment and was a simple search'n'replace to this fork so don't think behavior has changed. https://rustsec.org/advisories/RUSTSEC-2020-0054
4 years ago
"directories-next",
Making caching support optional in Wasmtime (#2119) This commit moves all of the caching support that currently lives in `wasmtime-environ` into a `wasmtime-cache` crate and makes it optional. The goal here is to slim down the `wasmtime-environ` crate and clearly separate boundaries where caching is a standalone and optional feature, not intertwined with other crates.
4 years ago
"file-per-thread-logger",
"filetime",
"log",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"once_cell",
Making caching support optional in Wasmtime (#2119) This commit moves all of the caching support that currently lives in `wasmtime-environ` into a `wasmtime-cache` crate and makes it optional. The goal here is to slim down the `wasmtime-environ` crate and clearly separate boundaries where caching is a standalone and optional feature, not intertwined with other crates.
4 years ago
"pretty_env_logger",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
Making caching support optional in Wasmtime (#2119) This commit moves all of the caching support that currently lives in `wasmtime-environ` into a `wasmtime-cache` crate and makes it optional. The goal here is to slim down the `wasmtime-environ` crate and clearly separate boundaries where caching is a standalone and optional feature, not intertwined with other crates.
4 years ago
"serde",
"sha2",
"tempfile",
"toml",
Migrate from `winapi` to `windows-sys` (#4346) * Migrate from `winapi` to `windows-sys` I believe that Microsoft itself is supporting the development of `windows-sys` and it's also used by `cap-std` now so this switches Wasmtime's dependencies on Windows APIs from the `winapi` crate to the `windows-sys` crate. We still have `winapi` in our dependency graph but that may get phased out over time. * Make windows-sys a target-specific dependency
2 years ago
"windows-sys",
Making caching support optional in Wasmtime (#2119) This commit moves all of the caching support that currently lives in `wasmtime-environ` into a `wasmtime-cache` crate and makes it optional. The goal here is to slim down the `wasmtime-environ` crate and clearly separate boundaries where caching is a standalone and optional feature, not intertwined with other crates.
4 years ago
"zstd",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "wasmtime-cli"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"anyhow",
give sychronous ResourceLimiter an async alternative
3 years ago
"async-trait",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"clap 3.2.8",
support enums with more than 256 variants in derive macro (#4370) * support enums with more than 256 variants in derive macro This addresses #4361. Technically, we now support up to 2^32 variants, which is the maximum for the canonical ABI. In practice, though, the derived code for enums with even just 2^16 variants takes a prohibitively long time to compile. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * simplify `LowerExpander::expand_variant` code Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"component-macro-test",
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"component-test-util",
Implement simple benchmarks for instantiation. This adds benchmarks around module instantiation using criterion. Both the default (i.e. on-demand) and pooling allocators are tested sequentially and in parallel using a thread pool. Instantiation is tested with an empty module, a module with a single page linear memory, a larger linear memory with a data initializer, and a "hello world" Rust WASI program.
4 years ago
"criterion",
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
"env_logger 0.9.0",
Test basic DWARF generation (#931) * Add obj generation with debug info * Add simple transform check
5 years ago
"filecheck",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"humantime 2.1.0",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"libc",
wasmtime: add CLI options for pre-opened TCP listen sockets (#3729) This patch implements CLI options to insert pre-opened sockets. `--listenfd` : Inherit environment variables and file descriptors following the systemd listen fd specification (UNIX only). `--tcplisten <SOCKET ADDRESS>`: Grant access to the given TCP listen socket. Signed-off-by: Harald Hoyer <harald@profian.com>
3 years ago
"listenfd",
Wasmtime: fix stack walking across frames from different stores (#4779) We were previously implicitly assuming that all Wasm frames in a stack used the same `VMRuntimeLimits` as the previous frame we walked, but this is not true when Wasm in store A calls into the host which then calls into Wasm in store B: | ... | | Host | | +-----------------+ | stack | Wasm in store A | | grows +-----------------+ | down | Host | | +-----------------+ | | Wasm in store B | V +-----------------+ Trying to walk this stack would previously result in a runtime panic. The solution is to push the maintenance of our list of saved Wasm FP/SP/PC registers that allow us to identify contiguous regions of Wasm frames on the stack deeper into `CallThreadState`. The saved registers list is now maintained whenever updating the `CallThreadState` linked list by making the `CallThreadState::prev` field private and only accessible via a getter and setter, where the setter always maintains our invariants.
2 years ago
"log",
Use an mmap-friendly serialization format (#3257) * Use an mmap-friendly serialization format This commit reimplements the main serialization format for Wasmtime's precompiled artifacts. Previously they were generally a binary blob of `bincode`-encoded metadata prefixed with some versioning information. The downside of this format, though, is that loading a precompiled artifact required pushing all information through `bincode`. This is inefficient when some data, such as trap/address tables, are rarely accessed. The new format added in this commit is one which is designed to be `mmap`-friendly. This means that the relevant parts of the precompiled artifact are already page-aligned for updating permissions of pieces here and there. Additionally the artifact is optimized so that if data is rarely read then we can delay reading it until necessary. The new artifact format for serialized modules is an ELF file. This is not a public API guarantee, so it cannot be relied upon. In the meantime though this is quite useful for exploring precompiled modules with standard tooling like `objdump`. The ELF file is already constructed as part of module compilation, and this is the main contents of the serialized artifact. THere is some extra information, though, not encoded in each module's individual ELF file such as type information. This information continues to be `bincode`-encoded, but it's intended to be much smaller and much faster to deserialize. This extra information is appended to the end of the ELF file. This means that the original ELF file is still a valid ELF file, we just get to have extra bits at the end. More information on the new format can be found in the module docs of the serialization module of Wasmtime. Another refatoring implemented as part of this commit is to deserialize and store object files directly in `mmap`-backed storage. This avoids the need to copy bytes after the artifact is loaded into memory for each compiled module, and in a future commit it opens up the door to avoiding copying the text section into a `CodeMemory`. For now, though, the main change is that copies are not necessary when loading from a precompiled compilation artifact once the artifact is itself in mmap-based memory. To assist with managing `mmap`-based memory a new `MmapVec` type was added to `wasmtime_jit` which acts as a form of `Vec<T>` backed by a `wasmtime_runtime::Mmap`. This type notably supports `drain(..N)` to slice the buffer into disjoint regions that are all separately owned, such as having a separately owned window into one artifact for all object files contained within. Finally this commit implements a small refactoring in `wasmtime-cache` to use the standard artifact format for cache entries rather than a bincode-encoded version. This required some more hooks for serializing/deserializing but otherwise the crate still performs as before. * Review comments
3 years ago
"memchr",
Implement simple benchmarks for instantiation. This adds benchmarks around module instantiation using criterion. Both the default (i.e. on-demand) and pooling allocators are tested sequentially and in parallel using a thread pool. Instantiation is tested with an empty module, a module with a single page linear memory, a larger linear memory with a data initializer, and a "hello world" Rust WASI program.
4 years ago
"num_cpus",
Minor instantiation benchmark updates (#3790) This commit has a few minor updates and some improvements to the instantiation benchmark harness: * A `once_cell::unsync::Lazy` type is now used to guard creation of modules/engines/etc. This enables running singular benchmarks to be much faster since the benchmark no longer compiles all other benchmarks that are filtered out. Unfortunately I couldn't find a way in criterion to test whether a `BenchmarkId` is filtered out or not so we rely on the runtime laziness to initialize on the first run for benchmarks that do so. * All files located in `benches/instantiation` are now loaded for benchmarking instead of a hardcoded list. This makes it a bit easier to throw files into the directory and have them benchmarked instead of having to recompile when working with new files. * Finally a module deserialization benchmark was added to measure the time it takes to deserialize a precompiled module from disk (inspired by discussion on #3787) While I was at it I also upped some limits to be able to instantiate cfallin's `spidermonkey.wasm`.
3 years ago
"once_cell",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"rayon",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"target-lexicon",
Fix 'not enough arguments' during wasmtime run (#858) * Fix 'not enough arguments' during wasmtime run * add simple cli smoke tests * autogenerate wasm
5 years ago
"tempfile",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"test-programs",
add tokio example Co-authored-by: Alex Crichton <alex@alexcrichton.com>
4 years ago
"tokio",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime",
Making caching support optional in Wasmtime (#2119) This commit moves all of the caching support that currently lives in `wasmtime-environ` into a `wasmtime-cache` crate and makes it optional. The goal here is to slim down the `wasmtime-environ` crate and clearly separate boundaries where caching is a standalone and optional feature, not intertwined with other crates.
4 years ago
"wasmtime-cache",
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
"wasmtime-cli-flags",
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"wasmtime-component-util",
Add a cranelift compile-time feature to wasmtime (#3206) * Remove unnecessary into_iter/map Forgotten from a previous refactoring, this variable was already of the right type! * Move `wasmtime_jit::Compiler` into `wasmtime` This `Compiler` struct is mostly a historical artifact at this point and wasn't necessarily pulling much weight any more. This organization also doesn't lend itself super well to compiling out `cranelift` when the `Compiler` here is used for both parallel iteration configuration settings as well as compilation. The movement into `wasmtime` is relatively small, with `Module::build_artifacts` being the main function added here which is a merging of the previous functions removed from the `wasmtime-jit` crate. * Add a `cranelift` compile-time feature to `wasmtime` This commit concludes the saga of refactoring Wasmtime and making Cranelift an optional dependency by adding a new Cargo feature to the `wasmtime` crate called `cranelift`, which is enabled by default. This feature is implemented by having a new cfg for `wasmtime` itself, `cfg(compiler)`, which is used wherever compilation is necessary. This bubbles up to disable APIs such as `Module::new`, `Func::new`, `Engine::precompile_module`, and a number of `Config` methods affecting compiler configuration. Checks are added to CI that when built in this mode Wasmtime continues to successfully build. It's hoped that although this is effectively "sprinkle `#[cfg]` until things compile" this won't be too too bad to maintain over time since it's also an use case we're interested in supporting. With `cranelift` disabled the only way to create a `Module` is with the `Module::deserialize` method, which requires some form of precompiled artifact. Two consequences of this change are: * `Module::serialize` is also disabled in this mode. The reason for this is that serialized modules contain ISA/shared flags encoded in them which were used to produce the compiled code. There's no storage for this if compilation is disabled. This could probably be re-enabled in the future if necessary, but it may not end up being all that necessary. * Deserialized modules are not checked to ensure that their ISA/shared flags are compatible with the host CPU. This is actually already the case, though, with normal modules. We'll likely want to fix this in the future using a shared implementation for both these locations. Documentation should be updated to indicate that `cranelift` can be disabled, although it's not really the most prominent documentation because this is expected to be a somewhat niche use case (albeit important, just not too common). * Always enable cranelift for the C API * Fix doc example builds * Fix check tests on GitHub Actions
3 years ago
"wasmtime-cranelift",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime-environ",
Add missing dev-dependency: wasmtime-runtime
5 years ago
"wasmtime-runtime",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime-wasi",
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
"wasmtime-wasi-crypto",
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
"wasmtime-wasi-nn",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime-wast",
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
"wast 47.0.1",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wat",
Migrate from `winapi` to `windows-sys` (#4346) * Migrate from `winapi` to `windows-sys` I believe that Microsoft itself is supporting the development of `windows-sys` and it's also used by `cap-std` now so this switches Wasmtime's dependencies on Windows APIs from the `winapi` crate to the `windows-sys` crate. We still have `winapi` in our dependency graph but that may get phased out over time. * Make windows-sys a target-specific dependency
2 years ago
"windows-sys",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
[[package]]
name = "wasmtime-cli-flags"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
dependencies = [
"anyhow",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"clap 3.2.8",
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
"file-per-thread-logger",
"pretty_env_logger",
"rayon",
"wasmtime",
]
add ComponentType/Lift/Lower derive macro for record types (#4337) This is the first stage of implementing https://github.com/bytecodealliance/wasmtime/issues/4308, i.e. derive macros for `ComponentType`, `Lift`, and `Lower` for composite types in the component model. This stage only covers records; I expect the other composite types will follow a similar pattern. It borrows heavily from the work Jamey Sharp did in https://github.com/bytecodealliance/wasmtime/pull/4217. Thanks for that, and thanks to both Jamey and Alex Crichton for their excellent review feedback. Thanks also to Brian for pairing up on the initial draft. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
[[package]]
name = "wasmtime-component-macro"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
add ComponentType/Lift/Lower derive macro for record types (#4337) This is the first stage of implementing https://github.com/bytecodealliance/wasmtime/issues/4308, i.e. derive macros for `ComponentType`, `Lift`, and `Lower` for composite types in the component model. This stage only covers records; I expect the other composite types will follow a similar pattern. It borrows heavily from the work Jamey Sharp did in https://github.com/bytecodealliance/wasmtime/pull/4217. Thanks for that, and thanks to both Jamey and Alex Crichton for their excellent review feedback. Thanks also to Brian for pairing up on the initial draft. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
dependencies = [
"proc-macro2",
"quote",
"syn",
support dynamic function calls in component model (#4442) * support dynamic function calls in component model This addresses #4310, introducing a new `component::values::Val` type for representing component values dynamically, as well as `component::types::Type` for representing the corresponding interface types. It also adds a `call` method to `component::func::Func`, which takes a slice of `Val`s as parameters and returns a `Result<Val>` representing the result. Note that I've moved `post_return` and `call_raw` from `TypedFunc` to `Func` since there was nothing specific to `TypedFunc` about them, and I wanted to reuse them. The code in both is unchanged beyond the trivial tweaks to make them fit in their new home. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * order variants and match cases more consistently Signed-off-by: Joel Dice <joel.dice@fermyon.com> * implement lift for String, Box<str>, etc. This also removes the redundant `store` parameter from `Type::load`. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * implement code review feedback This fixes a few issues: - Bad offset calculation when lowering - Missing variant padding - Style issues regarding `types::Handle` - Missed opportunities to reuse `Lift` and `Lower` impls It also adds forwarding `Lift` impls for `Box<[T]>`, `Vec<T>`, etc. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * move `new_*` methods to specific `types` structs Per review feedback, I've moved `Type::new_record` to `Record::new_val` and added a `Type::unwrap_record` method; likewise for the other kinds of types. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * make tuple, option, and expected type comparisons recursive These types should compare as equal across component boundaries as long as their type parameters are equal. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * improve error diagnostic in `Type::check` We now distinguish between more failure cases to provide an informative error message. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * address review feedback - Remove `WasmStr::to_str_from_memory` and `WasmList::get_from_memory` - add `try_new` methods to various `values` types - avoid using `ExactSizeIterator::len` where we can't trust it - fix over-constrained bounds on forwarded `ComponentType` impls Signed-off-by: Joel Dice <joel.dice@fermyon.com> * rearrange code per review feedback - Move functions from `types` to `values` module so we can make certain struct fields private - Rename `try_new` to just `new` Signed-off-by: Joel Dice <joel.dice@fermyon.com> * remove special-case equality test for tuples, options, and expecteds Instead, I've added a FIXME comment and will open an issue to do recursive structural equality testing. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"wasmtime-component-util",
add ComponentType/Lift/Lower derive macro for record types (#4337) This is the first stage of implementing https://github.com/bytecodealliance/wasmtime/issues/4308, i.e. derive macros for `ComponentType`, `Lift`, and `Lower` for composite types in the component model. This stage only covers records; I expect the other composite types will follow a similar pattern. It borrows heavily from the work Jamey Sharp did in https://github.com/bytecodealliance/wasmtime/pull/4217. Thanks for that, and thanks to both Jamey and Alex Crichton for their excellent review feedback. Thanks also to Brian for pairing up on the initial draft. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
]
support dynamic function calls in component model (#4442) * support dynamic function calls in component model This addresses #4310, introducing a new `component::values::Val` type for representing component values dynamically, as well as `component::types::Type` for representing the corresponding interface types. It also adds a `call` method to `component::func::Func`, which takes a slice of `Val`s as parameters and returns a `Result<Val>` representing the result. Note that I've moved `post_return` and `call_raw` from `TypedFunc` to `Func` since there was nothing specific to `TypedFunc` about them, and I wanted to reuse them. The code in both is unchanged beyond the trivial tweaks to make them fit in their new home. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * order variants and match cases more consistently Signed-off-by: Joel Dice <joel.dice@fermyon.com> * implement lift for String, Box<str>, etc. This also removes the redundant `store` parameter from `Type::load`. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * implement code review feedback This fixes a few issues: - Bad offset calculation when lowering - Missing variant padding - Style issues regarding `types::Handle` - Missed opportunities to reuse `Lift` and `Lower` impls It also adds forwarding `Lift` impls for `Box<[T]>`, `Vec<T>`, etc. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * move `new_*` methods to specific `types` structs Per review feedback, I've moved `Type::new_record` to `Record::new_val` and added a `Type::unwrap_record` method; likewise for the other kinds of types. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * make tuple, option, and expected type comparisons recursive These types should compare as equal across component boundaries as long as their type parameters are equal. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * improve error diagnostic in `Type::check` We now distinguish between more failure cases to provide an informative error message. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * address review feedback - Remove `WasmStr::to_str_from_memory` and `WasmList::get_from_memory` - add `try_new` methods to various `values` types - avoid using `ExactSizeIterator::len` where we can't trust it - fix over-constrained bounds on forwarded `ComponentType` impls Signed-off-by: Joel Dice <joel.dice@fermyon.com> * rearrange code per review feedback - Move functions from `types` to `values` module so we can make certain struct fields private - Rename `try_new` to just `new` Signed-off-by: Joel Dice <joel.dice@fermyon.com> * remove special-case equality test for tuples, options, and expecteds Instead, I've added a FIXME comment and will open an issue to do recursive structural equality testing. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
[[package]]
name = "wasmtime-component-util"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
support dynamic function calls in component model (#4442) * support dynamic function calls in component model This addresses #4310, introducing a new `component::values::Val` type for representing component values dynamically, as well as `component::types::Type` for representing the corresponding interface types. It also adds a `call` method to `component::func::Func`, which takes a slice of `Val`s as parameters and returns a `Result<Val>` representing the result. Note that I've moved `post_return` and `call_raw` from `TypedFunc` to `Func` since there was nothing specific to `TypedFunc` about them, and I wanted to reuse them. The code in both is unchanged beyond the trivial tweaks to make them fit in their new home. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * order variants and match cases more consistently Signed-off-by: Joel Dice <joel.dice@fermyon.com> * implement lift for String, Box<str>, etc. This also removes the redundant `store` parameter from `Type::load`. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * implement code review feedback This fixes a few issues: - Bad offset calculation when lowering - Missing variant padding - Style issues regarding `types::Handle` - Missed opportunities to reuse `Lift` and `Lower` impls It also adds forwarding `Lift` impls for `Box<[T]>`, `Vec<T>`, etc. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * move `new_*` methods to specific `types` structs Per review feedback, I've moved `Type::new_record` to `Record::new_val` and added a `Type::unwrap_record` method; likewise for the other kinds of types. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * make tuple, option, and expected type comparisons recursive These types should compare as equal across component boundaries as long as their type parameters are equal. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * improve error diagnostic in `Type::check` We now distinguish between more failure cases to provide an informative error message. Signed-off-by: Joel Dice <joel.dice@fermyon.com> * address review feedback - Remove `WasmStr::to_str_from_memory` and `WasmList::get_from_memory` - add `try_new` methods to various `values` types - avoid using `ExactSizeIterator::len` where we can't trust it - fix over-constrained bounds on forwarded `ComponentType` impls Signed-off-by: Joel Dice <joel.dice@fermyon.com> * rearrange code per review feedback - Move functions from `types` to `values` module so we can make certain struct fields private - Rename `try_new` to just `new` Signed-off-by: Joel Dice <joel.dice@fermyon.com> * remove special-case equality test for tuples, options, and expecteds Instead, I've added a FIXME comment and will open an issue to do recursive structural equality testing. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
wasmtime: Extract cranelift/lightbeam compilers to separate crates (#2117) This commit extracts the two implementations of `Compiler` into two separate crates, `wasmtime-cranelfit` and `wasmtime-lightbeam`. The `wasmtime-jit` crate then depends on these two and instantiates them appropriately. The goal here is to start reducing the weight of the `wasmtime-environ` crate, which currently serves as a common set of types between all `wasmtime-*` crates. Long-term I'd like to remove the dependency on Cranelift from `wasmtime-environ`, but that's going to take a lot more work. In the meantime I figure it's a good way to get started by separating out the lightbeam/cranelift function compilers from the `wasmtime-environ` crate. We can continue to iterate on moving things out in the future, too.
4 years ago
[[package]]
name = "wasmtime-cranelift"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
wasmtime: Extract cranelift/lightbeam compilers to separate crates (#2117) This commit extracts the two implementations of `Compiler` into two separate crates, `wasmtime-cranelfit` and `wasmtime-lightbeam`. The `wasmtime-jit` crate then depends on these two and instantiates them appropriately. The goal here is to start reducing the weight of the `wasmtime-environ` crate, which currently serves as a common set of types between all `wasmtime-*` crates. Long-term I'd like to remove the dependency on Cranelift from `wasmtime-environ`, but that's going to take a lot more work. In the meantime I figure it's a good way to get started by separating out the lightbeam/cranelift function compilers from the `wasmtime-environ` crate. We can continue to iterate on moving things out in the future, too.
4 years ago
dependencies = [
Remove dependency on `TargetIsa` from Wasmtime crates (#3178) This commit started off by deleting the `cranelift_codegen::settings` reexport in the `wasmtime-environ` crate and then basically played whack-a-mole until everything compiled again. The main result of this is that the `wasmtime-*` family of crates have generally less of a dependency on the `TargetIsa` trait and type from Cranelift. While the dependency isn't entirely severed yet this is at least a significant start. This commit is intended to be largely refactorings, no functional changes are intended here. The refactorings are: * A `CompilerBuilder` trait has been added to `wasmtime_environ` which server as an abstraction used to create compilers and configure them in a uniform fashion. The `wasmtime::Config` type now uses this instead of cranelift-specific settings. The `wasmtime-jit` crate exports the ability to create a compiler builder from a `CompilationStrategy`, which only works for Cranelift right now. In a cranelift-less build of Wasmtime this is expected to return a trait object that fails all requests to compile. * The `Compiler` trait in the `wasmtime_environ` crate has been souped up with a number of methods that Wasmtime and other crates needed. * The `wasmtime-debug` crate is now moved entirely behind the `wasmtime-cranelift` crate. * The `wasmtime-cranelift` crate is now only depended on by the `wasmtime-jit` crate. * Wasm types in `cranelift-wasm` no longer contain their IR type, instead they only contain the `WasmType`. This is required to get everything to align correctly but will also be required in a future refactoring where the types used by `cranelift-wasm` will be extracted to a separate crate. * I moved around a fair bit of code in `wasmtime-cranelift`. * Some gdb-specific jit-specific code has moved from `wasmtime-debug` to `wasmtime-jit`.
3 years ago
"anyhow",
wasmtime: Extract cranelift/lightbeam compilers to separate crates (#2117) This commit extracts the two implementations of `Compiler` into two separate crates, `wasmtime-cranelfit` and `wasmtime-lightbeam`. The `wasmtime-jit` crate then depends on these two and instantiates them appropriately. The goal here is to start reducing the weight of the `wasmtime-environ` crate, which currently serves as a common set of types between all `wasmtime-*` crates. Long-term I'd like to remove the dependency on Cranelift from `wasmtime-environ`, but that's going to take a lot more work. In the meantime I figure it's a good way to get started by separating out the lightbeam/cranelift function compilers from the `wasmtime-environ` crate. We can continue to iterate on moving things out in the future, too.
4 years ago
"cranelift-codegen",
"cranelift-entity",
"cranelift-frontend",
Remove dependency on `TargetIsa` from Wasmtime crates (#3178) This commit started off by deleting the `cranelift_codegen::settings` reexport in the `wasmtime-environ` crate and then basically played whack-a-mole until everything compiled again. The main result of this is that the `wasmtime-*` family of crates have generally less of a dependency on the `TargetIsa` trait and type from Cranelift. While the dependency isn't entirely severed yet this is at least a significant start. This commit is intended to be largely refactorings, no functional changes are intended here. The refactorings are: * A `CompilerBuilder` trait has been added to `wasmtime_environ` which server as an abstraction used to create compilers and configure them in a uniform fashion. The `wasmtime::Config` type now uses this instead of cranelift-specific settings. The `wasmtime-jit` crate exports the ability to create a compiler builder from a `CompilationStrategy`, which only works for Cranelift right now. In a cranelift-less build of Wasmtime this is expected to return a trait object that fails all requests to compile. * The `Compiler` trait in the `wasmtime_environ` crate has been souped up with a number of methods that Wasmtime and other crates needed. * The `wasmtime-debug` crate is now moved entirely behind the `wasmtime-cranelift` crate. * The `wasmtime-cranelift` crate is now only depended on by the `wasmtime-jit` crate. * Wasm types in `cranelift-wasm` no longer contain their IR type, instead they only contain the `WasmType`. This is required to get everything to align correctly but will also be required in a future refactoring where the types used by `cranelift-wasm` will be extracted to a separate crate. * I moved around a fair bit of code in `wasmtime-cranelift`. * Some gdb-specific jit-specific code has moved from `wasmtime-debug` to `wasmtime-jit`.
3 years ago
"cranelift-native",
wasmtime: Extract cranelift/lightbeam compilers to separate crates (#2117) This commit extracts the two implementations of `Compiler` into two separate crates, `wasmtime-cranelfit` and `wasmtime-lightbeam`. The `wasmtime-jit` crate then depends on these two and instantiates them appropriately. The goal here is to start reducing the weight of the `wasmtime-environ` crate, which currently serves as a common set of types between all `wasmtime-*` crates. Long-term I'd like to remove the dependency on Cranelift from `wasmtime-environ`, but that's going to take a lot more work. In the meantime I figure it's a good way to get started by separating out the lightbeam/cranelift function compilers from the `wasmtime-environ` crate. We can continue to iterate on moving things out in the future, too.
4 years ago
"cranelift-wasm",
Remove dependency on `TargetIsa` from Wasmtime crates (#3178) This commit started off by deleting the `cranelift_codegen::settings` reexport in the `wasmtime-environ` crate and then basically played whack-a-mole until everything compiled again. The main result of this is that the `wasmtime-*` family of crates have generally less of a dependency on the `TargetIsa` trait and type from Cranelift. While the dependency isn't entirely severed yet this is at least a significant start. This commit is intended to be largely refactorings, no functional changes are intended here. The refactorings are: * A `CompilerBuilder` trait has been added to `wasmtime_environ` which server as an abstraction used to create compilers and configure them in a uniform fashion. The `wasmtime::Config` type now uses this instead of cranelift-specific settings. The `wasmtime-jit` crate exports the ability to create a compiler builder from a `CompilationStrategy`, which only works for Cranelift right now. In a cranelift-less build of Wasmtime this is expected to return a trait object that fails all requests to compile. * The `Compiler` trait in the `wasmtime_environ` crate has been souped up with a number of methods that Wasmtime and other crates needed. * The `wasmtime-debug` crate is now moved entirely behind the `wasmtime-cranelift` crate. * The `wasmtime-cranelift` crate is now only depended on by the `wasmtime-jit` crate. * Wasm types in `cranelift-wasm` no longer contain their IR type, instead they only contain the `WasmType`. This is required to get everything to align correctly but will also be required in a future refactoring where the types used by `cranelift-wasm` will be extracted to a separate crate. * I moved around a fair bit of code in `wasmtime-cranelift`. * Some gdb-specific jit-specific code has moved from `wasmtime-debug` to `wasmtime-jit`.
3 years ago
"gimli",
Add some debug logging for timing in module compiles (#3417) * Add some debug logging for timing in module compiles This is sometimes helpful when debugging slow compiles from fuzz bugs or similar. * Fix total duration calculation to not double-count
3 years ago
"log",
Update `object` to 0.26.0
3 years ago
"object",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"target-lexicon",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"thiserror",
upgrade all wasmparser to 0.71 new simd instructions are left as ubsupported in cranelift-wasm
4 years ago
"wasmparser",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime-environ",
]
[[package]]
name = "wasmtime-environ"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Remove dependency on `TargetIsa` from Wasmtime crates (#3178) This commit started off by deleting the `cranelift_codegen::settings` reexport in the `wasmtime-environ` crate and then basically played whack-a-mole until everything compiled again. The main result of this is that the `wasmtime-*` family of crates have generally less of a dependency on the `TargetIsa` trait and type from Cranelift. While the dependency isn't entirely severed yet this is at least a significant start. This commit is intended to be largely refactorings, no functional changes are intended here. The refactorings are: * A `CompilerBuilder` trait has been added to `wasmtime_environ` which server as an abstraction used to create compilers and configure them in a uniform fashion. The `wasmtime::Config` type now uses this instead of cranelift-specific settings. The `wasmtime-jit` crate exports the ability to create a compiler builder from a `CompilationStrategy`, which only works for Cranelift right now. In a cranelift-less build of Wasmtime this is expected to return a trait object that fails all requests to compile. * The `Compiler` trait in the `wasmtime_environ` crate has been souped up with a number of methods that Wasmtime and other crates needed. * The `wasmtime-debug` crate is now moved entirely behind the `wasmtime-cranelift` crate. * The `wasmtime-cranelift` crate is now only depended on by the `wasmtime-jit` crate. * Wasm types in `cranelift-wasm` no longer contain their IR type, instead they only contain the `WasmType`. This is required to get everything to align correctly but will also be required in a future refactoring where the types used by `cranelift-wasm` will be extracted to a separate crate. * I moved around a fair bit of code in `wasmtime-cranelift`. * Some gdb-specific jit-specific code has moved from `wasmtime-debug` to `wasmtime-jit`.
3 years ago
"anyhow",
Implement fused adapters for `(list T)` types (#4558) * Implement fused adapters for `(list T)` types This commit implements one of the two remaining types for adapter fusion, lists. This implementation is particularly tricky for a number of reasons: * Lists have a number of validity checks which need to be carefully implemented. For example the byte length of the list passed to allocation in the destination module could overflow the 32-bit index space. Additionally lists in 32-bit memories need a check that their final address is in-bounds in the address space. * In the effort to go ahead and support memory64 at the lowest layers this is where much of the magic happens. Lists are naturally always stored in memory and shifting between 64/32-bit address spaces is done here. This notably required plumbing an `Options` around during flattening/size/alignment calculations due to the size/types of lists changing depending on the memory configuration. I've also added a small `factc` program in this commit which should hopefully assist in exploring and debugging adapter modules. This takes as input a component (text or binary format) and then generates an adapter module for all component function signatures found internally. This commit notably does not include tests for lists. I tried to figure out a good way to add these but I felt like there were too many cases to test and the tests would otherwise be extremely verbose. Instead I think the best testing strategy for this commit will be through #4537 which should be relatively extensible to testing adapters between modules in addition to host-based lifting/lowering. * Improve handling of lists of 0-size types * Skip overflow checks on byte sizes for 0-size types * Skip the copy loop entirely when src/dst are both 0 * Skip the increments of src/dst pointers if either is 0-size * Update semantics for zero-sized lists/strings When a list/string has a 0-byte-size the base pointer is no longer verified to be in-bounds to match the supposedly desired adapter semantics where no trap happens because no turn of the loop happens.
2 years ago
"atty",
"clap 3.2.8",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"cranelift-entity",
Implement fused adapters for `(list T)` types (#4558) * Implement fused adapters for `(list T)` types This commit implements one of the two remaining types for adapter fusion, lists. This implementation is particularly tricky for a number of reasons: * Lists have a number of validity checks which need to be carefully implemented. For example the byte length of the list passed to allocation in the destination module could overflow the 32-bit index space. Additionally lists in 32-bit memories need a check that their final address is in-bounds in the address space. * In the effort to go ahead and support memory64 at the lowest layers this is where much of the magic happens. Lists are naturally always stored in memory and shifting between 64/32-bit address spaces is done here. This notably required plumbing an `Options` around during flattening/size/alignment calculations due to the size/types of lists changing depending on the memory configuration. I've also added a small `factc` program in this commit which should hopefully assist in exploring and debugging adapter modules. This takes as input a component (text or binary format) and then generates an adapter module for all component function signatures found internally. This commit notably does not include tests for lists. I tried to figure out a good way to add these but I felt like there were too many cases to test and the tests would otherwise be extremely verbose. Instead I think the best testing strategy for this commit will be through #4537 which should be relatively extensible to testing adapters between modules in addition to host-based lifting/lowering. * Improve handling of lists of 0-size types * Skip overflow checks on byte sizes for 0-size types * Skip the copy loop entirely when src/dst are both 0 * Skip the increments of src/dst pointers if either is 0-size * Update semantics for zero-sized lists/strings When a list/string has a 0-byte-size the base pointer is no longer verified to be in-bounds to match the supposedly desired adapter semantics where no trap happens because no turn of the loop happens.
2 years ago
"env_logger 0.9.0",
Update `backtrace` to 0.3.61
3 years ago
"gimli",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"indexmap",
"log",
Move wasm data/debuginfo into the ELF compilation image (#3235) * Move wasm data/debuginfo into the ELF compilation image This commit moves existing allocations of `Box<[u8]>` stored separately from compilation's final ELF image into the ELF image itself. The goal of this commit is to reduce the amount of data which `bincode` will need to process in the future. DWARF debugging information and wasm data segments can be quite large, and they're relatively rarely read, so there's typically no need to copy them around. Instead by moving them into the ELF image this opens up the opportunity in the future to eliminate copies and use data directly as-found in the image itself. For information accessed possibly-multiple times, such as the wasm data ranges, the indexes of the data within the ELF image are computed when a `CompiledModule` is created. These indexes are then used to directly index into the image without having to root around in the ELF file each time they're accessed. One other change located here is that the symbolication context previously cloned the debug information into it to adhere to the `'static` lifetime safely, but this isn't actually ever used in `wasmtime` right now so the unsafety around this has been removed and instead borrowed data is returned (no more clones, yay!). * Fix lightbeam
3 years ago
"object",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"serde",
Remove dependency on `TargetIsa` from Wasmtime crates (#3178) This commit started off by deleting the `cranelift_codegen::settings` reexport in the `wasmtime-environ` crate and then basically played whack-a-mole until everything compiled again. The main result of this is that the `wasmtime-*` family of crates have generally less of a dependency on the `TargetIsa` trait and type from Cranelift. While the dependency isn't entirely severed yet this is at least a significant start. This commit is intended to be largely refactorings, no functional changes are intended here. The refactorings are: * A `CompilerBuilder` trait has been added to `wasmtime_environ` which server as an abstraction used to create compilers and configure them in a uniform fashion. The `wasmtime::Config` type now uses this instead of cranelift-specific settings. The `wasmtime-jit` crate exports the ability to create a compiler builder from a `CompilationStrategy`, which only works for Cranelift right now. In a cranelift-less build of Wasmtime this is expected to return a trait object that fails all requests to compile. * The `Compiler` trait in the `wasmtime_environ` crate has been souped up with a number of methods that Wasmtime and other crates needed. * The `wasmtime-debug` crate is now moved entirely behind the `wasmtime-cranelift` crate. * The `wasmtime-cranelift` crate is now only depended on by the `wasmtime-jit` crate. * Wasm types in `cranelift-wasm` no longer contain their IR type, instead they only contain the `WasmType`. This is required to get everything to align correctly but will also be required in a future refactoring where the types used by `cranelift-wasm` will be extracted to a separate crate. * I moved around a fair bit of code in `wasmtime-cranelift`. * Some gdb-specific jit-specific code has moved from `wasmtime-debug` to `wasmtime-jit`.
3 years ago
"target-lexicon",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"thiserror",
Add initial support for fused adapter trampolines (#4501) * Add initial support for fused adapter trampolines This commit lands a significant new piece of functionality to Wasmtime's implementation of the component model in the form of the implementation of fused adapter trampolines. Internally within a component core wasm modules can communicate with each other by having their exports `canon lift`'d to get `canon lower`'d into a different component. This signifies that two components are communicating through a statically known interface via the canonical ABI at this time. Previously Wasmtime was able to identify that this communication was happening but it simply panicked with `unimplemented!` upon seeing it. This commit is the beginning of filling out this panic location with an actual implementation. The implementation route chosen here for fused adapters is to use a WebAssembly module itself for the implementation. This means that, at compile time of a component, Wasmtime is generating core WebAssembly modules which then get recursively compiled within Wasmtime as well. The choice to use WebAssembly itself as the implementation of fused adapters stems from a few motivations: * This does not represent a significant increase in the "trusted compiler base" of Wasmtime. Getting the Wasm -> CLIF translation correct once is hard enough much less for an entirely different IR to CLIF. By generating WebAssembly no new interactions with Cranelift are added which drastically reduces the possibilities for mistakes. * Using WebAssembly means that component adapters are insulated from miscompilations and mistakes. If something goes wrong it's defined well within the WebAssembly specification how it goes wrong and what happens as a result. This means that the "blast zone" for a wrong adapter is the component instance but not the entire host itself. Accesses to linear memory are guaranteed to be in-bounds and otherwise handled via well-defined traps. * A fully-finished fused adapter compiler is expected to be a significant and quite complex component of Wasmtime. Functionality along these lines is expected to be needed for Web-based polyfills of the component model and by using core WebAssembly it provides the opportunity to share code between Wasmtime and these polyfills for the component model. * Finally the runtime implementation of managing WebAssembly modules is already implemented and quite easy to integrate with, so representing fused adapters with WebAssembly results in very little extra support necessary for the runtime implementation of instantiating and managing a component. The compiler added in this commit is dubbed Wasmtime's Fused Adapter Compiler of Trampolines (FACT) because who doesn't like deriving a name from an acronym. Currently the trampoline compiler is limited in its support for interface types and only supports a few primitives. I plan on filing future PRs to flesh out the support here for all the variants of `InterfaceType`. For now this PR is primarily focused on all of the other infrastructure for the addition of a trampoline compiler. With the choice to use core WebAssembly to implement fused adapters it means that adapters need to be inserted into a module. Unfortunately adapters cannot all go into a single WebAssembly module because adapters themselves have dependencies which may be provided transitively through instances that were instantiated with other adapters. This means that a significant chunk of this PR (`adapt.rs`) is dedicated to determining precisely which adapters go into precisely which adapter modules. This partitioning process attempts to make large modules wherever it can to cut down on core wasm instantiations but is likely not optimal as it's just a simple heuristic today. With all of this added together it's now possible to start writing `*.wast` tests that internally have adapted modules communicating with one another. A `fused.wast` test suite was added as part of this PR which is the beginning of tests for the support of the fused adapter compiler added in this PR. Currently this is primarily testing some various topologies of adapters along with direct/indirect modes. This will grow many more tests over time as more types are supported. Overall I'm not 100% satisfied with the testing story of this PR. When a test fails it's very difficult to debug since everything is written in the text format of WebAssembly meaning there's no "conveniences" to print out the state of the world when things go wrong and easily debug. I think this will become even more apparent as more tests are written for more types in subsequent PRs. At this time though I know of no better alternative other than leaning pretty heavily on fuzz-testing to ensure this is all exercised. * Fix an unused field warning * Fix tests in `wasmtime-runtime` * Add some more tests for compiled trampolines * Remap exports when injecting adapters The exports of a component were accidentally left unmapped which meant that they indexed the instance indexes pre-adapter module insertion. * Fix typo * Rebase conflicts
2 years ago
"wasm-encoder",
upgrade all wasmparser to 0.71 new simd instructions are left as ubsupported in cranelift-wasm
4 years ago
"wasmparser",
Add initial support for fused adapter trampolines (#4501) * Add initial support for fused adapter trampolines This commit lands a significant new piece of functionality to Wasmtime's implementation of the component model in the form of the implementation of fused adapter trampolines. Internally within a component core wasm modules can communicate with each other by having their exports `canon lift`'d to get `canon lower`'d into a different component. This signifies that two components are communicating through a statically known interface via the canonical ABI at this time. Previously Wasmtime was able to identify that this communication was happening but it simply panicked with `unimplemented!` upon seeing it. This commit is the beginning of filling out this panic location with an actual implementation. The implementation route chosen here for fused adapters is to use a WebAssembly module itself for the implementation. This means that, at compile time of a component, Wasmtime is generating core WebAssembly modules which then get recursively compiled within Wasmtime as well. The choice to use WebAssembly itself as the implementation of fused adapters stems from a few motivations: * This does not represent a significant increase in the "trusted compiler base" of Wasmtime. Getting the Wasm -> CLIF translation correct once is hard enough much less for an entirely different IR to CLIF. By generating WebAssembly no new interactions with Cranelift are added which drastically reduces the possibilities for mistakes. * Using WebAssembly means that component adapters are insulated from miscompilations and mistakes. If something goes wrong it's defined well within the WebAssembly specification how it goes wrong and what happens as a result. This means that the "blast zone" for a wrong adapter is the component instance but not the entire host itself. Accesses to linear memory are guaranteed to be in-bounds and otherwise handled via well-defined traps. * A fully-finished fused adapter compiler is expected to be a significant and quite complex component of Wasmtime. Functionality along these lines is expected to be needed for Web-based polyfills of the component model and by using core WebAssembly it provides the opportunity to share code between Wasmtime and these polyfills for the component model. * Finally the runtime implementation of managing WebAssembly modules is already implemented and quite easy to integrate with, so representing fused adapters with WebAssembly results in very little extra support necessary for the runtime implementation of instantiating and managing a component. The compiler added in this commit is dubbed Wasmtime's Fused Adapter Compiler of Trampolines (FACT) because who doesn't like deriving a name from an acronym. Currently the trampoline compiler is limited in its support for interface types and only supports a few primitives. I plan on filing future PRs to flesh out the support here for all the variants of `InterfaceType`. For now this PR is primarily focused on all of the other infrastructure for the addition of a trampoline compiler. With the choice to use core WebAssembly to implement fused adapters it means that adapters need to be inserted into a module. Unfortunately adapters cannot all go into a single WebAssembly module because adapters themselves have dependencies which may be provided transitively through instances that were instantiated with other adapters. This means that a significant chunk of this PR (`adapt.rs`) is dedicated to determining precisely which adapters go into precisely which adapter modules. This partitioning process attempts to make large modules wherever it can to cut down on core wasm instantiations but is likely not optimal as it's just a simple heuristic today. With all of this added together it's now possible to start writing `*.wast` tests that internally have adapted modules communicating with one another. A `fused.wast` test suite was added as part of this PR which is the beginning of tests for the support of the fused adapter compiler added in this PR. Currently this is primarily testing some various topologies of adapters along with direct/indirect modes. This will grow many more tests over time as more types are supported. Overall I'm not 100% satisfied with the testing story of this PR. When a test fails it's very difficult to debug since everything is written in the text format of WebAssembly meaning there's no "conveniences" to print out the state of the world when things go wrong and easily debug. I think this will become even more apparent as more tests are written for more types in subsequent PRs. At this time though I know of no better alternative other than leaning pretty heavily on fuzz-testing to ensure this is all exercised. * Fix an unused field warning * Fix tests in `wasmtime-runtime` * Add some more tests for compiled trampolines * Remap exports when injecting adapters The exports of a component were accidentally left unmapped which meant that they indexed the instance indexes pre-adapter module insertion. * Fix typo * Rebase conflicts
2 years ago
"wasmprinter",
Implement variant translation in fused adapters (#4534) * Implement variant translation in fused adapters This commit implements the most general case of variants for fused adapter trampolines. Additionally a number of other primitive types are filled out here to assist with testing variants. The implementation internally was relatively straightforward given the shape of variants, but there's room for future optimization as necessary especially around converting locals to various types. This commit also introduces a "one off" fuzzer for adapters to ensure that the generated adapter is valid. I hope to extend this fuzz generator as more types are implemented to assist in various corner cases that might arise. For now the fuzzer simply tests that the output wasm module is valid, not that it actually executes correctly. I hope to integrate with a fuzzer along the lines of #4307 one day to test the run-time-correctness of the generated adapters as well, at which point this fuzzer would become obsolete. Finally this commit also fixes an issue with `u8` translation where upper bits weren't zero'd out and were passed raw across modules. Instead smaller-than-32 types now all mask out their upper bits and do sign-extension as appropriate for unsigned/signed variants. * Fuzz memory64 in the new trampoline fuzzer Currently memory64 isn't supported elsewhere in the component model implementation of Wasmtime but the trampoline compiler seems as good a place as any to ensure that it at least works in isolation. This plumbs through fuzz input into a `memory64` boolean which gets fed into compilation. Some miscellaneous bugs were fixed as a result to ensure that memory64 trampolines all validate correctly. * Tweak manifest for doc build
2 years ago
"wasmtime-component-util",
Remove `wasmtime-environ`'s dependency on `cranelift-codegen` (#3199) * Move `CompiledFunction` into wasmtime-cranelift This commit moves the `wasmtime_environ::CompiledFunction` type into the `wasmtime-cranelift` crate. This type has lots of Cranelift-specific pieces of compilation and doesn't need to be generated by all Wasmtime compilers. This replaces the usage in the `Compiler` trait with a `Box<Any>` type that each compiler can select. Each compiler must still produce a `FunctionInfo`, however, which is shared information we'll deserialize for each module. The `wasmtime-debug` crate is also folded into the `wasmtime-cranelift` crate as a result of this commit. One possibility was to move the `CompiledFunction` commit into its own crate and have `wasmtime-debug` depend on that, but since `wasmtime-debug` is Cranelift-specific at this time it didn't seem like it was too too necessary to keep it separate. If `wasmtime-debug` supports other backends in the future we can recreate a new crate, perhaps with it refactored to not depend on Cranelift. * Move wasmtime_environ::reference_type This now belongs in wasmtime-cranelift and nowhere else * Remove `Type` reexport in wasmtime-environ One less dependency on `cranelift-codegen`! * Remove `types` reexport from `wasmtime-environ` Less cranelift! * Remove `SourceLoc` from wasmtime-environ Change the `srcloc`, `start_srcloc`, and `end_srcloc` fields to a custom `FilePos` type instead of `ir::SourceLoc`. These are only used in a few places so there's not much to lose from an extra abstraction for these leaf use cases outside of cranelift. * Remove wasmtime-environ's dep on cranelift's `StackMap` This commit "clones" the `StackMap` data structure in to `wasmtime-environ` to have an independent representation that that chosen by Cranelift. This allows Wasmtime to decouple this runtime dependency of stack map information and let the two evolve independently, if necessary. An alternative would be to refactor cranelift's implementation into a separate crate and have wasmtime depend on that but it seemed a bit like overkill to do so and easier to clone just a few lines for this. * Define code offsets in wasmtime-environ with `u32` Don't use Cranelift's `binemit::CodeOffset` alias to define this field type since the `wasmtime-environ` crate will be losing the `cranelift-codegen` dependency soon. * Commit to using `cranelift-entity` in Wasmtime This commit removes the reexport of `cranelift-entity` from the `wasmtime-environ` crate and instead directly depends on the `cranelift-entity` crate in all referencing crates. The original reason for the reexport was to make cranelift version bumps easier since it's less versions to change, but nowadays we have a script to do that. Otherwise this encourages crates to use whatever they want from `cranelift-entity` since we'll always depend on the whole crate. It's expected that the `cranelift-entity` crate will continue to be a lean crate in dependencies and suitable for use at both runtime and compile time. Consequently there's no need to avoid its usage in Wasmtime at runtime, since "remove Cranelift at compile time" is primarily about the `cranelift-codegen` crate. * Remove most uses of `cranelift-codegen` in `wasmtime-environ` There's only one final use remaining, which is the reexport of `TrapCode`, which will get handled later. * Limit the glob-reexport of `cranelift_wasm` This commit removes the glob reexport of `cranelift-wasm` from the `wasmtime-environ` crate. This is intended to explicitly define what we're reexporting and is a transitionary step to curtail the amount of dependencies taken on `cranelift-wasm` throughout the codebase. For example some functions used by debuginfo mapping are better imported directly from the crate since they're Cranelift-specific. Note that this is intended to be a temporary state affairs, soon this reexport will be gone entirely. Additionally this commit reduces imports from `cranelift_wasm` and also primarily imports from `crate::wasm` within `wasmtime-environ` to get a better sense of what's imported from where and what will need to be shared. * Extract types from cranelift-wasm to cranelift-wasm-types This commit creates a new crate called `cranelift-wasm-types` and extracts type definitions from the `cranelift-wasm` crate into this new crate. The purpose of this crate is to be a shared definition of wasm types that can be shared both by compilers (like Cranelift) as well as wasm runtimes (e.g. Wasmtime). This new `cranelift-wasm-types` crate doesn't depend on `cranelift-codegen` and is the final step in severing the unconditional dependency from Wasmtime to `cranelift-codegen`. The final refactoring in this commit is to then reexport this crate from `wasmtime-environ`, delete the `cranelift-codegen` dependency, and then update all `use` paths to point to these new types. The main change of substance here is that the `TrapCode` enum is mirrored from Cranelift into this `cranelift-wasm-types` crate. While this unfortunately results in three definitions (one more which is non-exhaustive in Wasmtime itself) it's hopefully not too onerous and ideally something we can patch up in the future. * Get lightbeam compiling * Remove unnecessary dependency * Fix compile with uffd * Update publish script * Fix more uffd tests * Rename cranelift-wasm-types to wasmtime-types This reflects the purpose a bit more where it's types specifically intended for Wasmtime and its support. * Fix publish script
3 years ago
"wasmtime-types",
Implement fused adapters for `(list T)` types (#4558) * Implement fused adapters for `(list T)` types This commit implements one of the two remaining types for adapter fusion, lists. This implementation is particularly tricky for a number of reasons: * Lists have a number of validity checks which need to be carefully implemented. For example the byte length of the list passed to allocation in the destination module could overflow the 32-bit index space. Additionally lists in 32-bit memories need a check that their final address is in-bounds in the address space. * In the effort to go ahead and support memory64 at the lowest layers this is where much of the magic happens. Lists are naturally always stored in memory and shifting between 64/32-bit address spaces is done here. This notably required plumbing an `Options` around during flattening/size/alignment calculations due to the size/types of lists changing depending on the memory configuration. I've also added a small `factc` program in this commit which should hopefully assist in exploring and debugging adapter modules. This takes as input a component (text or binary format) and then generates an adapter module for all component function signatures found internally. This commit notably does not include tests for lists. I tried to figure out a good way to add these but I felt like there were too many cases to test and the tests would otherwise be extremely verbose. Instead I think the best testing strategy for this commit will be through #4537 which should be relatively extensible to testing adapters between modules in addition to host-based lifting/lowering. * Improve handling of lists of 0-size types * Skip overflow checks on byte sizes for 0-size types * Skip the copy loop entirely when src/dst are both 0 * Skip the increments of src/dst pointers if either is 0-size * Update semantics for zero-sized lists/strings When a list/string has a 0-byte-size the base pointer is no longer verified to be in-bounds to match the supposedly desired adapter semantics where no trap happens because no turn of the loop happens.
2 years ago
"wat",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Implement variant translation in fused adapters (#4534) * Implement variant translation in fused adapters This commit implements the most general case of variants for fused adapter trampolines. Additionally a number of other primitive types are filled out here to assist with testing variants. The implementation internally was relatively straightforward given the shape of variants, but there's room for future optimization as necessary especially around converting locals to various types. This commit also introduces a "one off" fuzzer for adapters to ensure that the generated adapter is valid. I hope to extend this fuzz generator as more types are implemented to assist in various corner cases that might arise. For now the fuzzer simply tests that the output wasm module is valid, not that it actually executes correctly. I hope to integrate with a fuzzer along the lines of #4307 one day to test the run-time-correctness of the generated adapters as well, at which point this fuzzer would become obsolete. Finally this commit also fixes an issue with `u8` translation where upper bits weren't zero'd out and were passed raw across modules. Instead smaller-than-32 types now all mask out their upper bits and do sign-extension as appropriate for unsigned/signed variants. * Fuzz memory64 in the new trampoline fuzzer Currently memory64 isn't supported elsewhere in the component model implementation of Wasmtime but the trampoline compiler seems as good a place as any to ensure that it at least works in isolation. This plumbs through fuzz input into a `memory64` boolean which gets fed into compilation. Some miscellaneous bugs were fixed as a result to ensure that memory64 trampolines all validate correctly. * Tweak manifest for doc build
2 years ago
[[package]]
name = "wasmtime-environ-fuzz"
version = "0.0.0"
dependencies = [
"arbitrary",
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"component-fuzz-util",
Implement variant translation in fused adapters (#4534) * Implement variant translation in fused adapters This commit implements the most general case of variants for fused adapter trampolines. Additionally a number of other primitive types are filled out here to assist with testing variants. The implementation internally was relatively straightforward given the shape of variants, but there's room for future optimization as necessary especially around converting locals to various types. This commit also introduces a "one off" fuzzer for adapters to ensure that the generated adapter is valid. I hope to extend this fuzz generator as more types are implemented to assist in various corner cases that might arise. For now the fuzzer simply tests that the output wasm module is valid, not that it actually executes correctly. I hope to integrate with a fuzzer along the lines of #4307 one day to test the run-time-correctness of the generated adapters as well, at which point this fuzzer would become obsolete. Finally this commit also fixes an issue with `u8` translation where upper bits weren't zero'd out and were passed raw across modules. Instead smaller-than-32 types now all mask out their upper bits and do sign-extension as appropriate for unsigned/signed variants. * Fuzz memory64 in the new trampoline fuzzer Currently memory64 isn't supported elsewhere in the component model implementation of Wasmtime but the trampoline compiler seems as good a place as any to ensure that it at least works in isolation. This plumbs through fuzz input into a `memory64` boolean which gets fed into compilation. Some miscellaneous bugs were fixed as a result to ensure that memory64 trampolines all validate correctly. * Tweak manifest for doc build
2 years ago
"env_logger 0.9.0",
"libfuzzer-sys",
"wasmparser",
"wasmprinter",
"wasmtime-environ",
Deduplicate some size/align calculations (#4658) This commit is an effort to reduce the amount of complexity around managing the size/alignment calculations of types in the canonical ABI. Previously the logic for the size/alignment of a type was spread out across a number of locations. While each individual calculation is not really the most complicated thing in the world having the duplication in so many places was constantly worrying me. I've opted in this commit to centralize all of this within the runtime at least, and now there's only one "duplicate" of this information in the fuzzing infrastructure which is to some degree less important to deduplicate. This commit introduces a new `CanonicalAbiInfo` type to house all abi size/align information for both memory32 and memory64. This new type is then used pervasively throughout fused adapter compilation, dynamic `Val` management, and typed functions. This type was also able to reduce the complexity of the macro-generated code meaning that even `wasmtime-component-macro` is performing less math than it was before. One other major feature of this commit is that this ABI information is now saved within a `ComponentTypes` structure. This avoids recursive querying of size/align information frequently and instead effectively caching it. This was a worry I had for the fused adapter compiler which frequently sought out size/align information and would recursively descend each type tree each time. The `fact-valid-module` fuzzer is now nearly 10x faster in terms of iterations/s which I suspect is due to this caching.
2 years ago
"wat",
Implement variant translation in fused adapters (#4534) * Implement variant translation in fused adapters This commit implements the most general case of variants for fused adapter trampolines. Additionally a number of other primitive types are filled out here to assist with testing variants. The implementation internally was relatively straightforward given the shape of variants, but there's room for future optimization as necessary especially around converting locals to various types. This commit also introduces a "one off" fuzzer for adapters to ensure that the generated adapter is valid. I hope to extend this fuzz generator as more types are implemented to assist in various corner cases that might arise. For now the fuzzer simply tests that the output wasm module is valid, not that it actually executes correctly. I hope to integrate with a fuzzer along the lines of #4307 one day to test the run-time-correctness of the generated adapters as well, at which point this fuzzer would become obsolete. Finally this commit also fixes an issue with `u8` translation where upper bits weren't zero'd out and were passed raw across modules. Instead smaller-than-32 types now all mask out their upper bits and do sign-extension as appropriate for unsigned/signed variants. * Fuzz memory64 in the new trampoline fuzzer Currently memory64 isn't supported elsewhere in the component model implementation of Wasmtime but the trampoline compiler seems as good a place as any to ensure that it at least works in isolation. This plumbs through fuzz input into a `memory64` boolean which gets fed into compilation. Some miscellaneous bugs were fixed as a result to ensure that memory64 trampolines all validate correctly. * Tweak manifest for doc build
2 years ago
]
Implement support for `async` functions in Wasmtime (#2434) * Implement support for `async` functions in Wasmtime This is an implementation of [RFC 2] in Wasmtime which is to support `async`-defined host functions. At a high level support is added by executing WebAssembly code that might invoke an asynchronous host function on a separate native stack. When the host function's future is not ready we switch back to the main native stack to continue execution. There's a whole bunch of details in this commit, and it's a bit much to go over them all here in this commit message. The most important changes here are: * A new `wasmtime-fiber` crate has been written to manage the low-level details of stack-switching. Unixes use `mmap` to allocate a stack and Windows uses the native fibers implementation. We'll surely want to refactor this to move stack allocation elsewhere in the future. Fibers are intended to be relatively general with a lot of type paremters to fling values back and forth across suspension points. The whole crate is a giant wad of `unsafe` unfortunately and involves handwritten assembly with custom dwarf CFI directives to boot. Definitely deserves a close eye in review! * The `Store` type has two new methods -- `block_on` and `on_fiber` which bridge between the async and non-async worlds. Lots of unsafe fiddly bits here as we're trying to communicate context pointers between disparate portions of the code. Extra eyes and care in review is greatly appreciated. * The APIs for binding `async` functions are unfortunately pretty ugly in `Func`. This is mostly due to language limitations and compiler bugs (I believe) in Rust. Instead of `Func::wrap` we have a `Func::wrapN_async` family of methods, and we've also got a whole bunch of `Func::getN_async` methods now too. It may be worth rethinking the API of `Func` to try to make the documentation page actually grok'able. This isn't super heavily tested but the various test should suffice for engaging hopefully nearly all the infrastructure in one form or another. This is just the start though! [RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2 * Add wasmtime-fiber to publish script * Save vector/float registers on ARM too. * Fix a typo * Update lock file * Implement periodically yielding with fuel consumption This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures. * Fix compile without async * Save/restore the frame pointer in fiber switching Turns out this is another caller-saved register! * Simplify x86_64 fiber asm Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses. * Add x86 support to wasmtime-fiber * Add ARM32 support to fiber crate * Make fiber build file probing more flexible * Use CreateFiberEx on Windows * Remove a stray no-longer-used trait declaration * Don't reach into `Caller` internals * Tweak async fuel to eventually run out. With fuel it's probably best to not provide any way to inject infinite fuel. * Fix some typos * Cleanup asm a bit * Use a shared header file to deduplicate some directives * Guarantee hidden visibility for functions * Enable gc-sections on macOS x86_64 * Add `.type` annotations for ARM * Update lock file * Fix compile error * Review comments
4 years ago
[[package]]
name = "wasmtime-fiber"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Implement support for `async` functions in Wasmtime (#2434) * Implement support for `async` functions in Wasmtime This is an implementation of [RFC 2] in Wasmtime which is to support `async`-defined host functions. At a high level support is added by executing WebAssembly code that might invoke an asynchronous host function on a separate native stack. When the host function's future is not ready we switch back to the main native stack to continue execution. There's a whole bunch of details in this commit, and it's a bit much to go over them all here in this commit message. The most important changes here are: * A new `wasmtime-fiber` crate has been written to manage the low-level details of stack-switching. Unixes use `mmap` to allocate a stack and Windows uses the native fibers implementation. We'll surely want to refactor this to move stack allocation elsewhere in the future. Fibers are intended to be relatively general with a lot of type paremters to fling values back and forth across suspension points. The whole crate is a giant wad of `unsafe` unfortunately and involves handwritten assembly with custom dwarf CFI directives to boot. Definitely deserves a close eye in review! * The `Store` type has two new methods -- `block_on` and `on_fiber` which bridge between the async and non-async worlds. Lots of unsafe fiddly bits here as we're trying to communicate context pointers between disparate portions of the code. Extra eyes and care in review is greatly appreciated. * The APIs for binding `async` functions are unfortunately pretty ugly in `Func`. This is mostly due to language limitations and compiler bugs (I believe) in Rust. Instead of `Func::wrap` we have a `Func::wrapN_async` family of methods, and we've also got a whole bunch of `Func::getN_async` methods now too. It may be worth rethinking the API of `Func` to try to make the documentation page actually grok'able. This isn't super heavily tested but the various test should suffice for engaging hopefully nearly all the infrastructure in one form or another. This is just the start though! [RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2 * Add wasmtime-fiber to publish script * Save vector/float registers on ARM too. * Fix a typo * Update lock file * Implement periodically yielding with fuel consumption This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures. * Fix compile without async * Save/restore the frame pointer in fiber switching Turns out this is another caller-saved register! * Simplify x86_64 fiber asm Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses. * Add x86 support to wasmtime-fiber * Add ARM32 support to fiber crate * Make fiber build file probing more flexible * Use CreateFiberEx on Windows * Remove a stray no-longer-used trait declaration * Don't reach into `Caller` internals * Tweak async fuel to eventually run out. With fuel it's probably best to not provide any way to inject infinite fuel. * Fix some typos * Cleanup asm a bit * Use a shared header file to deduplicate some directives * Guarantee hidden visibility for functions * Enable gc-sections on macOS x86_64 * Add `.type` annotations for ARM * Update lock file * Fix compile error * Review comments
4 years ago
dependencies = [
"backtrace",
"cc",
Use `global_asm!` instead of external assembly files (#4306) * Use `global_asm!` instead of external assembly files This commit moves the external assembly files of the `wasmtime-fiber` crate into `global_asm!` blocks defined in Rust. The motivation for doing this is not very strong at this time, but the points in favor of this are: * One less tool needed to cross-compile Wasmtime. A linker is still needed but perhaps one day that will improve as well. * A "modern" assembler, built-in to LLVM, is used instead of whatever appears on the system. The first point hasn't really cropped up that much and typically getting an assembler is just as hard as getting a linker nowadays. The second point though has us using `hint #xx` in aarch64 assembly instead of the actual instructions for assembler compatibility, and I believe that's no longer necessary because the LLVM assembler supports the modern instruction names. The translation of the x86/x86_64 assembly has been done to Intel syntax as well as opposed to the old AT&T syntax since that's Rust's default. Additionally s390x still remains in an external assembler file because `global_asm!` is still unstable in Rust on that platform. * Simplify alignment specification * Temporarily disable fail-fast * Add `.cfi_def_cfa_offset 0` to fix CI * Turn off fail-fast * Review comments
2 years ago
"cfg-if",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
Split `global_asm!` helper macros out from `wasmtime-fibers` (#4454) This moves them into a new `wasmtime-asm-macros` crate that can be used not just from the `wasmtime-fibers` crate but also from other crates (e.g. we will need them in https://github.com/bytecodealliance/wasmtime/pull/4431).
2 years ago
"wasmtime-asm-macros",
Migrate from `winapi` to `windows-sys` (#4346) * Migrate from `winapi` to `windows-sys` I believe that Microsoft itself is supporting the development of `windows-sys` and it's also used by `cap-std` now so this switches Wasmtime's dependencies on Windows APIs from the `winapi` crate to the `windows-sys` crate. We still have `winapi` in our dependency graph but that may get phased out over time. * Make windows-sys a target-specific dependency
2 years ago
"windows-sys",
Implement support for `async` functions in Wasmtime (#2434) * Implement support for `async` functions in Wasmtime This is an implementation of [RFC 2] in Wasmtime which is to support `async`-defined host functions. At a high level support is added by executing WebAssembly code that might invoke an asynchronous host function on a separate native stack. When the host function's future is not ready we switch back to the main native stack to continue execution. There's a whole bunch of details in this commit, and it's a bit much to go over them all here in this commit message. The most important changes here are: * A new `wasmtime-fiber` crate has been written to manage the low-level details of stack-switching. Unixes use `mmap` to allocate a stack and Windows uses the native fibers implementation. We'll surely want to refactor this to move stack allocation elsewhere in the future. Fibers are intended to be relatively general with a lot of type paremters to fling values back and forth across suspension points. The whole crate is a giant wad of `unsafe` unfortunately and involves handwritten assembly with custom dwarf CFI directives to boot. Definitely deserves a close eye in review! * The `Store` type has two new methods -- `block_on` and `on_fiber` which bridge between the async and non-async worlds. Lots of unsafe fiddly bits here as we're trying to communicate context pointers between disparate portions of the code. Extra eyes and care in review is greatly appreciated. * The APIs for binding `async` functions are unfortunately pretty ugly in `Func`. This is mostly due to language limitations and compiler bugs (I believe) in Rust. Instead of `Func::wrap` we have a `Func::wrapN_async` family of methods, and we've also got a whole bunch of `Func::getN_async` methods now too. It may be worth rethinking the API of `Func` to try to make the documentation page actually grok'able. This isn't super heavily tested but the various test should suffice for engaging hopefully nearly all the infrastructure in one form or another. This is just the start though! [RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2 * Add wasmtime-fiber to publish script * Save vector/float registers on ARM too. * Fix a typo * Update lock file * Implement periodically yielding with fuel consumption This commit implements APIs on `Store` to periodically yield execution of futures through the consumption of fuel. When fuel runs out a future's execution is yielded back to the caller, and then upon resumption fuel is re-injected. The goal of this is to allow cooperative multi-tasking with futures. * Fix compile without async * Save/restore the frame pointer in fiber switching Turns out this is another caller-saved register! * Simplify x86_64 fiber asm Take a leaf out of aarch64's playbook and don't have extra memory to load/store these arguments, instead leverage how `wasmtime_fiber_switch` already loads a bunch of data into registers which we can then immediately start using on a fiber's start without any extra memory accesses. * Add x86 support to wasmtime-fiber * Add ARM32 support to fiber crate * Make fiber build file probing more flexible * Use CreateFiberEx on Windows * Remove a stray no-longer-used trait declaration * Don't reach into `Caller` internals * Tweak async fuel to eventually run out. With fuel it's probably best to not provide any way to inject infinite fuel. * Fix some typos * Cleanup asm a bit * Use a shared header file to deduplicate some directives * Guarantee hidden visibility for functions * Enable gc-sections on macOS x86_64 * Add `.type` annotations for ARM * Update lock file * Fix compile error * Review comments
4 years ago
]
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
[[package]]
name = "wasmtime-fuzz"
Wasmtime 0.13.0 and Cranelift 0.61.0. (#1398) This also updates the publishing scripts to work with newly added and reorganized crates.
5 years ago
version = "0.0.0"
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
dependencies = [
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"anyhow",
"arbitrary",
"component-fuzz-util",
"component-test-util",
Merge cranelift/wasmtime fuzzing
5 years ago
"cranelift-codegen",
Cranelift CLIF-level differential fuzzer (#3038) * cranelift: Initial fuzzer implementation * cranelift: Generate multiple test cases in fuzzer * cranelift: Separate function generator in fuzzer * cranelift: Insert random instructions in fuzzer * cranelift: Rename gen_testcase * cranelift: Implement div for unsigned values in interpreter * cranelift: Run all test cases in fuzzer * cranelift: Comment options in function_runner * cranelift: Improve fuzzgen README.md * cranelift: Fuzzgen remove unused variable * cranelift: Fuzzer code style fixes Thanks! @bjorn3 * cranelift: Fix nits in CLIF fuzzer Thanks @cfallin! * cranelift: Implement Arbitrary for TestCase * cranelift: Remove gen_testcase * cranelift: Move fuzzers to wasmtime fuzz directory * cranelift: CLIF-Fuzzer ignore tests that produce traps * cranelift: CLIF-Fuzzer create new fuzz target to validate generated testcases * cranelift: Store clif-fuzzer config in a separate struct * cranelift: Generate variables upfront per function * cranelift: Prevent publishing of fuzzgen crate
3 years ago
"cranelift-filetests",
"cranelift-fuzzgen",
"cranelift-interpreter",
Merge cranelift/wasmtime fuzzing
5 years ago
"cranelift-reader",
"cranelift-wasm",
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
"libfuzzer-sys",
fuzzgen: Statistics framework (#4868) * cranelift: Add non user trap codes function * cranelift: Add Fuzzgen stats * cranelift: Use `once_cell` and cleanup some stuff * fuzzgen: Remove total_inputs metric * fuzzgen: Filter empty trap codes
2 years ago
"once_cell",
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"proc-macro2",
"quote",
"rand 0.8.5",
cranelift: Add LibCalls to the interpreter (#4782) * cranelift: Add libcall handlers to interpreter * cranelift: Fuzz IshlI64 libcall * cranelift: Revert back to fuzzing udivi64 * cranelift: Use sdiv as a fuzz libcall * cranelift: Register Sdiv in fuzzgen * cranelift: Add multiple libcalls to fuzzer * cranelift: Register a single libcall handler * cranelift: Simplify args checking in interpreter * cranelift: Remove unused LibCalls * cranelift: Cleanup interpreter libcall types * cranelift: Fix Interpreter Docs
2 years ago
"smallvec",
Merge cranelift/wasmtime fuzzing
5 years ago
"target-lexicon",
Remove usage of `CompilationStrategy` from `Config` (#764) * Remove usage of `CompilationStrategy` from `Config` This commit removes the public API usage of the internal `CompilationStrategy` enumeration from the `Config` type in the `wasmtime` crate. To do this the `enum` was copied locally into the crate and renamed `Strategy`. The high-level description of this change is: * The `Config::strategy` method now takes a locally-defined `Strategy` enumeration instead of an internal type. * The contents of `Strategy` are always the same, not relying on Cargo features to indicate which variants are present. This avoids unnecessary downstream `#[cfg]`. * A `lightbeam` feature was added to the `wasmtime` crate itself to lightbeam compilation support. * The `Config::strategy` method is now fallible. It returns a runtime error if support for the selected strategy wasn't compiled in. * The `Strategy` enum is listed as `#[non_exhaustive]` so we can safely add variants over time to it. This reduces the public crate dependencies of the `wasmtime` crate itself, removing the need to reach into internal crates even more! cc #708 * Fix fuzz targets * Update nightly used to build releases * Run rustfmt
5 years ago
"wasmtime",
Move the `fuzz` directory into main workspace This'll help us track dependencies and head off issues like #721
5 years ago
"wasmtime-fuzzing",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "wasmtime-fuzzing"
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
version = "0.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"anyhow",
Update to arbitrary@0.4.0 and libfuzzer-sys@0.3.1
5 years ago
"arbitrary",
implement fuzzing for component types (#4537) This addresses #4307. For the static API we generate 100 arbitrary test cases at build time, each of which includes 0-5 parameter types, a result type, and a WAT fragment containing an imported function and an exported function. The exported function calls the imported function, which is implemented by the host. At runtime, the fuzz test selects a test case at random and feeds it zero or more sets of arbitrary parameters and results, checking that values which flow host-to-guest and guest-to-host make the transition unchanged. The fuzz test for the dynamic API follows a similar pattern, the only difference being that test cases are generated at runtime. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
2 years ago
"component-fuzz-util",
"component-test-util",
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
"env_logger 0.9.0",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"log",
fuzzing: Refactor `TableOps` fuzz generator to allow GC with refs on the stack (#4016) This makes the generator more similar to `wasm-smith` where it is keeping track of what is on the stack and making choices about what instructions are valid to generate given the current stack state. This should in theory allow the generator to emit GC calls while there are live refs on the stack. Fixes #3917
3 years ago
"rand 0.8.5",
Limit rayon to one thread during fuzzing This should enable more deterministic execution.
5 years ago
"rayon",
Fuzz cranelift cpu flag settings with Wasmtime (#3800) * Fuzz cranelift cpu flag settings with Wasmtime This commit updates the `Config` fuzz-generator to consume some of the input as configuration settings for codegen flags we pass to cranelift. This should allow for ideally some more coverage where settings are disabled or enabled, ideally finding possible bugs in feature-specific implementations or generic implementations that are rarely used if the feature-specific ones almost always take precedent. The technique used in this commit is to weight selection of codegen settings less frequently than using the native settings. Afterwards each listed feature is individually enabled or disabled depending on the input fuzz data, and if a feature is enabled but the host doesn't actually support it then the fuzz input is rejected with a log message. The goal here is to still have many fuzz inputs accepted but also ensure determinism across hosts. If there's a bug specifically related to enabling a flag then running it on a host without the flag should indicate that the flag isn't supported rather than silently leaving it disabled and reporting the fuzz case a success. * Use built-in `Unstructured::ratio` method * Tweak macro * Bump arbitrary dep version
3 years ago
"target-lexicon",
Fuzz using precompiled modules on CI (#3788) In working on #3787 I see now that our coverage of loading precompiled files specifically is somewhat lacking, so this adds a config option to the fuzzers where, if enabled, will round-trip all compiled modules through the filesystem to test out the mmapped-file case.
3 years ago
"tempfile",
Update v8 used during fuzzing (#3493) This commit updates the crate name from `rusty_v8` to `v8` as well since the upstream bindings have sinced moved. I originally wanted to do this to see if a fix for one of our fuzz bugs was pulled in but I don't think the fix has been pulled in yet. Despite that it seems reasonable to go ahead and update.
3 years ago
"v8",
2499: First pass on TableOps fuzzer generator wasm_encoder migration (#2501) * 2499: First pass on TableOps fuzzer generator wasm_encoder migration - wasm binary generated via sections and smushed together into a module - test: compare generated wat against expected wat - note: doesn't work - Grouped instructions not implemented - Vec<u8> to wat String not implemented * 2499: Add typesection, abstract instruction puts, and update test - TableOp.insert now will interact with a function object directly - add types for generated function - expected test string now reflects expected generated code * 2499: Mark unused index as _i * 2499: Function insertion is in proper stack order, and fix off by 1 index - imported functions must be typed - instructions operate on a stack ie. define values as instructions before using * 2499: Apply suggestions from code review - typo fixing - oracle ingests binary bytes itself Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com> * 2499: Code cleanup + renaming vars - busywork, nothing to see here Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
4 years ago
"wasm-encoder",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"wasm-mutate",
Replace binaryen -ttf based fuzzing with wasm-smith (#2336) This commit removes the binaryen support for fuzzing from wasmtime, instead switching over to `wasm-smith`. In general it's great to have what fuzzing we can, but our binaryen support suffers from a few issues: * The Rust crate, binaryen-sys, seems largely unmaintained at this point. While we could likely take ownership and/or send PRs to update the crate it seems like the maintenance is largely on us at this point. * Currently the binaryen-sys crate doesn't support fuzzing anything beyond MVP wasm, but we're interested at least in features like bulk memory and reference types. Additionally we'll also be interested in features like module-linking. New features would require either implementation work in binaryen or the binaryen-sys crate to support. * We have 4-5 fuzz-bugs right now related to timeouts simply in generating a module for wasmtime to fuzz. One investigation along these lines in the past revealed a bug in binaryen itself, and in any case these bugs would otherwise need to get investigated, reported, and possibly fixed ourselves in upstream binaryen. Overall I'm not sure at this point if maintaining binaryen fuzzing is worth it with the advent of `wasm-smith` which has similar goals for wasm module generation, but is much more readily maintainable on our end. Additonally in this commit I've added a fuzzer for wasm-smith's `SwarmConfig`-based fuzzer which should expand the coverage of tested modules. Closes #2163
4 years ago
"wasm-smith",
Add a crate to interface with the WebAssembly spec interpreter The WebAssembly spec interpreter is written in OCaml and the new crate uses `ocaml-interop` along with a small OCaml wrapper to interpret Wasm modules in-process. The build process for this crate is currently Linux-specific: it requires several OCaml packages (e.g. `apt install -y ocaml-nox ocamlbuild`) as well as `make`, `cp`, and `ar`.
3 years ago
"wasm-spec-interpreter",
Add differential fuzzing against wasmi (a Wasm interpreter). This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
4 years ago
"wasmi",
upgrade all wasmparser to 0.71 new simd instructions are left as ubsupported in cranelift-wasm
4 years ago
"wasmparser",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmprinter",
"wasmtime",
Add a spec test fuzzer for Config (#1509) * Add a spec test fuzzer for Config This commit adds a new fuzzer which is intended to run on oss-fuzz. This fuzzer creates and arbitrary `Config` which *should* pass spec tests and then asserts that it does so. The goal here is to weed out any accidental bugs in global configuration which could cause non-spec-compliant behavior. * Move implementation to `fuzzing` crate
5 years ago
"wasmtime-wast",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wat",
]
[[package]]
name = "wasmtime-jit"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update `backtrace` to 0.3.61
3 years ago
"addr2line",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"anyhow",
Convert compilation artifacts to just bytes (#3239) * Convert compilation artifacts to just bytes This commit strips the `CompilationArtifacts` type down to simply a list of bytes. This moves all extra metadata elsewhere to live within the list of bytes itself as `bincode`-encoded information. Small affordance is made to avoid an in-process serialize-then-deserialize round-trip for use cases like `Module::new`, but otherwise this is mostly just moving some data around. * Rename data section to `.rodata.wasm`
3 years ago
"bincode",
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Try demangling names before forwarding them to the profiler Before this PR, each profiler (perf/vtune, at the moment) had to have a demangler for each of the programming languages that could have been compiled to wasm and fed into wasmtime. With this, wasmtime now demangles names before even forwarding them to the underlying profiler, which makes for a unified representation in profilers, and avoids incorrect demangling in profilers.
3 years ago
"cpp_demangle",
Update `backtrace` to 0.3.61
3 years ago
"gimli",
Upgrade to the high-level `ittapi` v0.3.0 crate (#4003) * Upgrade to the high-level ittapi v0.3.0 crate * Add exclusion for windows mingw
2 years ago
"ittapi",
Support vtune profiling of trampolines too (#3687) * Provide helpers for demangling function names * Profile trampolines in vtune too * get rid of mapping * avoid code duplication with jitdump_linux * maintain previous default display name for wasm functions * no dash, grrr * Remove unused profiling error type
3 years ago
"log",
Update `object` to 0.26.0
3 years ago
"object",
Try demangling names before forwarding them to the profiler Before this PR, each profiler (perf/vtune, at the moment) had to have a demangler for each of the programming languages that could have been compiled to wasm and fed into wasmtime. With this, wasmtime now demangles names before even forwarding them to the underlying profiler, which makes for a unified representation in profilers, and avoids incorrect demangling in profilers.
3 years ago
"rustc-demangle",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
Serialize and deserialize compilation artifacts. (#2020) * Serialize and deserialize Module * Use bincode to serialize * Add wasm_module_serialize; docs * Simple tests
4 years ago
"serde",
Update dependencies to current versions, reducing duplicate versions (#963) * Cargo.lock: Update, to no longer use multiple versions of autocfg * Update wasmtime-debug and wasmtime-profiling to current gimli 0.20.0 This also eliminates duplicate versions of gimli and arrayvec, and eliminates the nodrop dependency entirely. * Update wasmtime-profiling to goblin 0.1.3 and object 0.17.0 This also eliminates two duplicate versions of goblin, and duplicate versions of proc-macro2, quote, syn, scroll_derive, and unicode-xid. * Update wasmtime-profiling to current scroll 0.10.1 This eliminates duplicate versions of scroll. * Update wasmtime-profiling to current target-lexicon 0.10.0 This eliminates duplicate versions of target-lexicon. * Update wasmtime-interface-types to current walrus and wasm-webidl-bindings This also eliminates the oldest of the three duplicate versions of wasmparser. * Update wasmtime-wast to current wast 8.0.0 This eliminates one of the duplicate versions of wast.
5 years ago
"target-lexicon",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"thiserror",
"wasmtime-environ",
Extract jit_int.rs and most of jitdump_linux.rs for use outside of wasmtime (#2744) * Extract gdb jit_int into wasmtime-jit-debug * Move a big chunk of the jitdump code to wasmtime-jit-debug * Fix doc markdown in perf_jitdump.rs
3 years ago
"wasmtime-jit-debug",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime-runtime",
Migrate from `winapi` to `windows-sys` (#4346) * Migrate from `winapi` to `windows-sys` I believe that Microsoft itself is supporting the development of `windows-sys` and it's also used by `cap-std` now so this switches Wasmtime's dependencies on Windows APIs from the `winapi` crate to the `windows-sys` crate. We still have `winapi` in our dependency graph but that may get phased out over time. * Make windows-sys a target-specific dependency
2 years ago
"windows-sys",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Extract jit_int.rs and most of jitdump_linux.rs for use outside of wasmtime (#2744) * Extract gdb jit_int into wasmtime-jit-debug * Move a big chunk of the jitdump code to wasmtime-jit-debug * Fix doc markdown in perf_jitdump.rs
3 years ago
[[package]]
name = "wasmtime-jit-debug"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Extract jit_int.rs and most of jitdump_linux.rs for use outside of wasmtime (#2744) * Extract gdb jit_int into wasmtime-jit-debug * Move a big chunk of the jitdump code to wasmtime-jit-debug * Fix doc markdown in perf_jitdump.rs
3 years ago
dependencies = [
"object",
Migrate most of wasmtime from lazy_static to once_cell (#4368) * Update tracing-core to a version which doesn't depend on lazy-static. * Update crossbeam-utils to a version that doesn't depend on lazy-static. * Update crossbeam-epoch to a version that doesn't depend on lazy-static. * Update clap to a version that doesn't depend on lazy-static. * Convert Wasmtime's own use of lazy_static to once_cell. * Make `GDB_REGISTRATION`'s comment a doc comment. * Fix compilation on Windows.
2 years ago
"once_cell",
Extract jit_int.rs and most of jitdump_linux.rs for use outside of wasmtime (#2744) * Extract gdb jit_int into wasmtime-jit-debug * Move a big chunk of the jitdump code to wasmtime-jit-debug * Fix doc markdown in perf_jitdump.rs
3 years ago
"rustix",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "wasmtime-runtime"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Code review feedback changes. * Add `anyhow` dependency to `wasmtime-runtime`. * Revert `get_data` back to `fn`. * Remove `DataInitializer` and box the data in `Module` translation instead. * Improve comments on `MemoryInitialization`. * Remove `MemoryInitialization::OutOfBounds` in favor of proper bulk memory semantics. * Use segmented memory initialization except for when the uffd feature is enabled on Linux. * Validate modules with the allocator after translation. * Updated various functions in the runtime to return `anyhow::Result`. * Use a slice when copying pages instead of `ptr::copy_nonoverlapping`. * Remove unnecessary casts in `OnDemandAllocator::deallocate`. * Better document the `uffd` feature. * Use WebAssembly page-sized pages in the paged initialization. * Remove the stack pool from the uffd handler and simply protect just the guard pages.
4 years ago
"anyhow",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"cc",
Remove support for userfaultfd (#4040) This commit removes support for the `userfaultfd` or "uffd" syscall on Linux. This support was originally added for users migrating from Lucet to Wasmtime, but the recent developments of kernel-supported copy-on-write support for memory initialization wound up being more appropriate for these use cases than usefaultfd. The main reason for moving to copy-on-write initialization are: * The `userfaultfd` feature was never necessarily intended for this style of use case with wasm and was susceptible to subtle and rare bugs that were extremely difficult to track down. We were never 100% certain that there were kernel bugs related to userfaultfd but the suspicion never went away. * Handling faults with userfaultfd was always slow and single-threaded. Only one thread could handle faults and traveling to user-space to handle faults is inherently slower than handling them all in the kernel. The single-threaded aspect in particular presented a significant scaling bottleneck for embeddings that want to run many wasm instances in parallel. * One of the major benefits of userfaultfd was lazy initialization of wasm linear memory which is also achieved with the copy-on-write initialization support we have right now. * One of the suspected benefits of userfaultfd was less frobbing of the kernel vma structures when wasm modules are instantiated. Currently the copy-on-write support has a mitigation where we attempt to reuse the memory images where possible to avoid changing vma structures. When comparing this to userfaultfd's performance it was found that kernel modifications of vmas aren't a worrisome bottleneck so copy-on-write is suitable for this as well. Overall there are no remaining benefits that userfaultfd gives that copy-on-write doesn't, and copy-on-write solves a major downsides of userfaultfd, the scaling issue with a single faulting thread. Additionally copy-on-write support seems much more robust in terms of kernel implementation since it's only using standard memory-management syscalls which are heavily exercised. Finally copy-on-write support provides a new bonus where read-only memory in WebAssembly can be mapped directly to the same kernel cache page, even amongst many wasm instances of the same module, which was never possible with userfaultfd. In light of all this it's expected that all users of userfaultfd should migrate to the copy-on-write initialization of Wasmtime (which is enabled by default).
3 years ago
"cfg-if",
Implement strings in adapter modules (#4623) * Implement strings in adapter modules This commit is a hefty addition to Wasmtime's support for the component model. This implements the final remaining type (in the current type hierarchy) unimplemented in adapter module trampolines: strings. Strings are the most complicated type to implement in adapter trampolines because they are highly structured chunks of data in memory (according to specific encodings). Additionally each lift/lower operation can choose its own encoding for strings meaning that Wasmtime, the host, may have to convert between any pairwise ordering of string encodings. The `CanonicalABI.md` in the component-model repo in general specifies all the fiddly bits of string encoding so there's not a ton of wiggle room for Wasmtime to get creative. This PR largely "just" implements that. The high-level architecture of this implementation is: * Fused adapters are first identified to determine src/dst string encodings. This statically fixes what transcoding operation is being performed. * The generated adapter will be responsible for managing calls to `realloc` and performing bounds checks. The adapter itself does not perform memory copies or validation of string contents, however. Instead each transcoding operation is modeled as an imported function into the adapter module. This means that the adapter module dynamically, during compile time, determines what string transcoders are needed. Note that an imported transcoder is not only parameterized over the transcoding operation but additionally which memory is the source and which is the destination. * The imported core wasm functions are modeled as a new `CoreDef::Transcoder` structure. These transcoders end up being small Cranelift-compiled trampolines. The Cranelift-compiled trampoline will load the actual base pointer of memory and add it to the relative pointers passed as function arguments. This trampoline then calls a transcoder "libcall" which enters Rust-defined functions for actual transcoding operations. * Each possible transcoding operation is implemented in Rust with a unique name and a unique signature depending on the needs of the transcoder. I've tried to document inline what each transcoder does. This means that the `Module::translate_string` in adapter modules is by far the largest translation method. The main reason for this is due to the management around calling the imported transcoder functions in the face of validating string pointer/lengths and performing the dance of `realloc`-vs-transcode at the right time. I've tried to ensure that each individual case in transcoding is documented well enough to understand what's going on as well. Additionally in this PR is a full implementation in the host for the `latin1+utf16` encoding which means that both lifting and lowering host strings now works with this encoding. Currently the implementation of each transcoder function is likely far from optimal. Where possible I've leaned on the standard library itself and for latin1-related things I'm leaning on the `encoding_rs` crate. I initially tried to implement everything with `encoding_rs` but was unable to uniformly do so easily. For now I settled on trying to get a known-correct (even in the face of endianness) implementation for all of these transcoders. If an when performance becomes an issue it should be possible to implement more optimized versions of each of these transcoding operations. Testing this commit has been somewhat difficult and my general plan, like with the `(list T)` type, is to rely heavily on fuzzing to cover the various cases here. In this PR though I've added a simple test that pushes some statically known strings through all the pairs of encodings between source and destination. I've attempted to pick "interesting" strings that one way or another stress the various paths in each transcoding operation to ideally get full branch coverage there. Additionally a suite of "negative" tests have also been added to ensure that validity of encoding is actually checked. * Fix a temporarily commented out case * Fix wasmtime-runtime tests * Update deny.toml configuration * Add `BSD-3-Clause` for the `encoding_rs` crate * Remove some unused licenses * Add an exemption for `encoding_rs` for now * Split up the `translate_string` method Move out all the closures and package up captured state into smaller lists of arguments. * Test out-of-bounds for zero-length strings
2 years ago
"encoding_rs",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"indexmap",
"libc",
externref: implement stack map-based garbage collection For host VM code, we use plain reference counting, where cloning increments the reference count, and dropping decrements it. We can avoid many of the on-stack increment/decrement operations that typically plague the performance of reference counting via Rust's ownership and borrowing system. Moving a `VMExternRef` avoids mutating its reference count, and borrowing it either avoids the reference count increment or delays it until if/when the `VMExternRef` is cloned. When passing a `VMExternRef` into compiled Wasm code, we don't want to do reference count mutations for every compiled `local.{get,set}`, nor for every function call. Therefore, we use a variation of **deferred reference counting**, where we only mutate reference counts when storing `VMExternRef`s somewhere that outlives the activation: into a global or table. Simultaneously, we over-approximate the set of `VMExternRef`s that are inside Wasm function activations. Periodically, we walk the stack at GC safe points, and use stack map information to precisely identify the set of `VMExternRef`s inside Wasm activations. Then we take the difference between this precise set and our over-approximation, and decrement the reference count for each of the `VMExternRef`s that are in our over-approximation but not in the precise set. Finally, the over-approximation is replaced with the precise set. The `VMExternRefActivationsTable` implements the over-approximized set of `VMExternRef`s referenced by Wasm activations. Calling a Wasm function and passing it a `VMExternRef` moves the `VMExternRef` into the table, and the compiled Wasm function logically "borrows" the `VMExternRef` from the table. Similarly, `global.get` and `table.get` operations clone the gotten `VMExternRef` into the `VMExternRefActivationsTable` and then "borrow" the reference out of the table. When a `VMExternRef` is returned to host code from a Wasm function, the host increments the reference count (because the reference is logically "borrowed" from the `VMExternRefActivationsTable` and the reference count from the table will be dropped at the next GC). For more general information on deferred reference counting, see *An Examination of Deferred Reference Counting and Cycle Detection* by Quinane: https://openresearch-repository.anu.edu.au/bitstream/1885/42030/2/hon-thesis.pdf cc #929 Fixes #1804
4 years ago
"log",
Mach ports continued + support aarch64-apple unwinding (#2723) * Switch macOS to using mach ports for trap handling This commit moves macOS to using mach ports instead of signals for handling traps. The motivation for this is listed in #2456, namely that once mach ports are used in a process that means traditional UNIX signal handlers won't get used. This means that if Wasmtime is integrated with Breakpad, for example, then Wasmtime's trap handler never fires and traps don't work. The `traphandlers` module is refactored as part of this commit to split the platform-specific bits into their own files (it was growing quite a lot for one inline `cfg_if!`). The `unix.rs` and `windows.rs` files remain the same as they were before with a few minor tweaks for some refactored interfaces. The `macos.rs` file is brand new and lifts almost its entire implementation from SpiderMonkey, adapted for Wasmtime though. The main gotcha with mach ports is that a separate thread is what services the exception. Some unsafe magic allows this separate thread to read non-`Send` and temporary state from other threads, but is hoped to be safe in this context. The unfortunate downside is that calling wasm on macOS now involves taking a global lock and modifying a global hash map twice-per-call. I'm not entirely sure how to get out of this cost for now, but hopefully for any embeddings on macOS it's not the end of the world. Closes #2456 * Add a sketch of arm64 apple support * store: maintain CallThreadState mapping when switching fibers * cranelift/aarch64: generate unwind directives to disable pointer auth Aarch64 post ARMv8.3 has a feature called pointer authentication, designed to fight ROP/JOP attacks: some pointers may be signed using new instructions, adding payloads to the high (previously unused) bits of the pointers. More on this here: https://lwn.net/Articles/718888/ Unwinders on aarch64 need to know if some pointers contained on the call frame contain an authentication code or not, to be able to properly authenticate them or use them directly. Since native code may have enabled it by default (as is the case on the Mac M1), and the default is that this configuration value is inherited, we need to explicitly disable it, for the only kind of supported pointers (return addresses). To do so, we set the value of a non-existing dwarf pseudo register (34) to 0, as documented in https://github.com/ARM-software/abi-aa/blob/master/aadwarf64/aadwarf64.rst#note-8. This is done at the function granularity, in the spirit of Cranelift compilation model. Alternatively, a single directive could be generated in the CIE, generating less information per module. * Make exception handling work on Mac aarch64 too * fibers: use a breakpoint instruction after the final call in wasmtime_fiber_start Co-authored-by: Alex Crichton <alex@alexcrichton.com>
4 years ago
"mach",
Add a pooling allocator mode based on copy-on-write mappings of memfds. As first suggested by Jan on the Zulip here [1], a cheap and effective way to obtain copy-on-write semantics of a "backing image" for a Wasm memory is to mmap a file with `MAP_PRIVATE`. The `memfd` mechanism provided by the Linux kernel allows us to create anonymous, in-memory-only files that we can use for this mapping, so we can construct the image contents on-the-fly then effectively create a CoW overlay. Furthermore, and importantly, `madvise(MADV_DONTNEED, ...)` will discard the CoW overlay, returning the mapping to its original state. By itself this is almost enough for a very fast instantiation-termination loop of the same image over and over, without changing the address space mapping at all (which is expensive). The only missing bit is how to implement heap *growth*. But here memfds can help us again: if we create another anonymous file and map it where the extended parts of the heap would go, we can take advantage of the fact that a `mmap()` mapping can be *larger than the file itself*, with accesses beyond the end generating a `SIGBUS`, and the fact that we can cheaply resize the file with `ftruncate`, even after a mapping exists. So we can map the "heap extension" file once with the maximum memory-slot size and grow the memfd itself as `memory.grow` operations occur. The above CoW technique and heap-growth technique together allow us a fastpath of `madvise()` and `ftruncate()` only when we re-instantiate the same module over and over, as long as we can reuse the same slot. This fastpath avoids all whole-process address-space locks in the Linux kernel, which should mean it is highly scalable. It also avoids the cost of copying data on read, as the `uffd` heap backend does when servicing pagefaults; the kernel's own optimized CoW logic (same as used by all file mmaps) is used instead. [1] https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/Copy.20on.20write.20based.20instance.20reuse/near/266657772
3 years ago
"memfd",
cargo update
4 years ago
"memoffset",
`wasmtime`: Implement fast Wasm stack walking (#4431) * Always preserve frame pointers in Wasmtime This allows us to efficiently and simply capture Wasm stacks without maintaining and synchronizing any safety-critical side tables between the compiler and the runtime. * wasmtime: Implement fast Wasm stack walking Why do we want Wasm stack walking to be fast? Because we capture stacks whenever there is a trap and traps actually happen fairly frequently with short-lived programs and WASI's `exit`. Previously, we would rely on generating the system unwind info (e.g. `.eh_frame`) and using the system unwinder (via the `backtrace`crate) to walk the full stack and filter out any non-Wasm stack frames. This can, unfortunately, be slow for two primary reasons: 1. The system unwinder is doing `O(all-kinds-of-frames)` work rather than `O(wasm-frames)` work. 2. System unwind info and the system unwinder need to be much more general than a purpose-built stack walker for Wasm needs to be. It has to handle any kind of stack frame that any compiler might emit where as our Wasm frames are emitted by Cranelift and always have frame pointers. This translates into implementation complexity and general overhead. There can also be unnecessary-for-our-use-cases global synchronization and locks involved, further slowing down stack walking in the presence of multiple threads trying to capture stacks in parallel. This commit introduces a purpose-built stack walker for traversing just our Wasm frames. To find all the sequences of Wasm-to-Wasm stack frames, and ignore non-Wasm stack frames, we keep a linked list of `(entry stack pointer, exit frame pointer)` pairs. This linked list is maintained via Wasm-to-host and host-to-Wasm trampolines. Within a sequence of Wasm-to-Wasm calls, we can use frame pointers (which Cranelift preserves) to find the next older Wasm frame on the stack, and we keep doing this until we reach the entry stack pointer, meaning that the next older frame will be a host frame. The trampolines need to avoid a couple stumbling blocks. First, they need to be compiled ahead of time, since we may not have access to a compiler at runtime (e.g. if the `cranelift` feature is disabled) but still want to be able to call functions that have already been compiled and get stack traces for those functions. Usually this means we would compile the appropriate trampolines inside `Module::new` and the compiled module object would hold the trampolines. However, we *also* need to support calling host functions that are wrapped into `wasmtime::Func`s and there doesn't exist *any* ahead-of-time compiled module object to hold the appropriate trampolines: ```rust // Define a host function. let func_type = wasmtime::FuncType::new( vec![wasmtime::ValType::I32], vec![wasmtime::ValType::I32], ); let func = Func::new(&mut store, func_type, |_, params, results| { // ... Ok(()) }); // Call that host function. let mut results = vec![wasmtime::Val::I32(0)]; func.call(&[wasmtime::Val::I32(0)], &mut results)?; ``` Therefore, we define one host-to-Wasm trampoline and one Wasm-to-host trampoline in assembly that work for all Wasm and host function signatures. These trampolines are careful to only use volatile registers, avoid touching any register that is an argument in the calling convention ABI, and tail call to the target callee function. This allows forwarding any set of arguments and any returns to and from the callee, while also allowing us to maintain our linked list of Wasm stack and frame pointers before transferring control to the callee. These trampolines are not used in Wasm-to-Wasm calls, only when crossing the host-Wasm boundary, so they do not impose overhead on regular calls. (And if using one trampoline for all host-Wasm boundary crossing ever breaks branch prediction enough in the CPU to become any kind of bottleneck, we can do fun things like have multiple copies of the same trampoline and choose a random copy for each function, sharding the functions across branch predictor entries.) Finally, this commit also ends the use of a synthetic `Module` and allocating a stubbed out `VMContext` for host functions. Instead, we define a `VMHostFuncContext` with its own magic value, similar to `VMComponentContext`, specifically for host functions. <h2>Benchmarks</h2> <h3>Traps and Stack Traces</h3> Large improvements to taking stack traces on traps, ranging from shaving off 64% to 99.95% of the time it used to take. <details> ``` multi-threaded-traps/0 time: [2.5686 us 2.5808 us 2.5934 us] thrpt: [0.0000 elem/s 0.0000 elem/s 0.0000 elem/s] change: time: [-85.419% -85.153% -84.869%] (p = 0.00 < 0.05) thrpt: [+560.90% +573.56% +585.84%] Performance has improved. Found 8 outliers among 100 measurements (8.00%) 4 (4.00%) high mild 4 (4.00%) high severe multi-threaded-traps/1 time: [2.9021 us 2.9167 us 2.9322 us] thrpt: [341.04 Kelem/s 342.86 Kelem/s 344.58 Kelem/s] change: time: [-91.455% -91.294% -91.096%] (p = 0.00 < 0.05) thrpt: [+1023.1% +1048.6% +1070.3%] Performance has improved. Found 6 outliers among 100 measurements (6.00%) 1 (1.00%) high mild 5 (5.00%) high severe multi-threaded-traps/2 time: [2.9996 us 3.0145 us 3.0295 us] thrpt: [660.18 Kelem/s 663.47 Kelem/s 666.76 Kelem/s] change: time: [-94.040% -93.910% -93.762%] (p = 0.00 < 0.05) thrpt: [+1503.1% +1542.0% +1578.0%] Performance has improved. Found 5 outliers among 100 measurements (5.00%) 5 (5.00%) high severe multi-threaded-traps/4 time: [5.5768 us 5.6052 us 5.6364 us] thrpt: [709.68 Kelem/s 713.63 Kelem/s 717.25 Kelem/s] change: time: [-93.193% -93.121% -93.052%] (p = 0.00 < 0.05) thrpt: [+1339.2% +1353.6% +1369.1%] Performance has improved. multi-threaded-traps/8 time: [8.6408 us 9.1212 us 9.5438 us] thrpt: [838.24 Kelem/s 877.08 Kelem/s 925.84 Kelem/s] change: time: [-94.754% -94.473% -94.202%] (p = 0.00 < 0.05) thrpt: [+1624.7% +1709.2% +1806.1%] Performance has improved. multi-threaded-traps/16 time: [10.152 us 10.840 us 11.545 us] thrpt: [1.3858 Melem/s 1.4760 Melem/s 1.5761 Melem/s] change: time: [-97.042% -96.823% -96.577%] (p = 0.00 < 0.05) thrpt: [+2821.5% +3048.1% +3281.1%] Performance has improved. Found 1 outliers among 100 measurements (1.00%) 1 (1.00%) high mild many-modules-registered-traps/1 time: [2.6278 us 2.6361 us 2.6447 us] thrpt: [378.11 Kelem/s 379.35 Kelem/s 380.55 Kelem/s] change: time: [-85.311% -85.108% -84.909%] (p = 0.00 < 0.05) thrpt: [+562.65% +571.51% +580.76%] Performance has improved. Found 9 outliers among 100 measurements (9.00%) 3 (3.00%) high mild 6 (6.00%) high severe many-modules-registered-traps/8 time: [2.6294 us 2.6460 us 2.6623 us] thrpt: [3.0049 Melem/s 3.0235 Melem/s 3.0425 Melem/s] change: time: [-85.895% -85.485% -85.022%] (p = 0.00 < 0.05) thrpt: [+567.63% +588.95% +608.95%] Performance has improved. Found 8 outliers among 100 measurements (8.00%) 3 (3.00%) high mild 5 (5.00%) high severe many-modules-registered-traps/64 time: [2.6218 us 2.6329 us 2.6452 us] thrpt: [24.195 Melem/s 24.308 Melem/s 24.411 Melem/s] change: time: [-93.629% -93.551% -93.470%] (p = 0.00 < 0.05) thrpt: [+1431.4% +1450.6% +1469.5%] Performance has improved. Found 3 outliers among 100 measurements (3.00%) 3 (3.00%) high mild many-modules-registered-traps/512 time: [2.6569 us 2.6737 us 2.6923 us] thrpt: [190.17 Melem/s 191.50 Melem/s 192.71 Melem/s] change: time: [-99.277% -99.268% -99.260%] (p = 0.00 < 0.05) thrpt: [+13417% +13566% +13731%] Performance has improved. Found 4 outliers among 100 measurements (4.00%) 4 (4.00%) high mild many-modules-registered-traps/4096 time: [2.7258 us 2.7390 us 2.7535 us] thrpt: [1.4876 Gelem/s 1.4955 Gelem/s 1.5027 Gelem/s] change: time: [-99.956% -99.955% -99.955%] (p = 0.00 < 0.05) thrpt: [+221417% +223380% +224881%] Performance has improved. Found 2 outliers among 100 measurements (2.00%) 1 (1.00%) high mild 1 (1.00%) high severe many-stack-frames-traps/1 time: [1.4658 us 1.4719 us 1.4784 us] thrpt: [676.39 Kelem/s 679.38 Kelem/s 682.21 Kelem/s] change: time: [-90.368% -89.947% -89.586%] (p = 0.00 < 0.05) thrpt: [+860.23% +894.72% +938.21%] Performance has improved. Found 8 outliers among 100 measurements (8.00%) 5 (5.00%) high mild 3 (3.00%) high severe many-stack-frames-traps/8 time: [2.4772 us 2.4870 us 2.4973 us] thrpt: [3.2034 Melem/s 3.2167 Melem/s 3.2294 Melem/s] change: time: [-85.550% -85.370% -85.199%] (p = 0.00 < 0.05) thrpt: [+575.65% +583.51% +592.03%] Performance has improved. Found 8 outliers among 100 measurements (8.00%) 4 (4.00%) high mild 4 (4.00%) high severe many-stack-frames-traps/64 time: [10.109 us 10.171 us 10.236 us] thrpt: [6.2525 Melem/s 6.2925 Melem/s 6.3309 Melem/s] change: time: [-78.144% -77.797% -77.336%] (p = 0.00 < 0.05) thrpt: [+341.22% +350.38% +357.55%] Performance has improved. Found 7 outliers among 100 measurements (7.00%) 5 (5.00%) high mild 2 (2.00%) high severe many-stack-frames-traps/512 time: [126.16 us 126.54 us 126.96 us] thrpt: [4.0329 Melem/s 4.0461 Melem/s 4.0583 Melem/s] change: time: [-65.364% -64.933% -64.453%] (p = 0.00 < 0.05) thrpt: [+181.32% +185.17% +188.71%] Performance has improved. Found 4 outliers among 100 measurements (4.00%) 4 (4.00%) high severe ``` </details> <h3>Calls</h3> There is, however, a small regression in raw Wasm-to-host and host-to-Wasm call performance due the new trampolines. It seems to be on the order of about 2-10 nanoseconds per call, depending on the benchmark. I believe this regression is ultimately acceptable because 1. this overhead will be vastly dominated by whatever work a non-nop callee actually does, 2. we will need these trampolines, or something like them, when implementing the Wasm exceptions proposal to do things like translate Wasm's exceptions into Rust's `Result`s, 3. and because the performance improvements to trapping and capturing stack traces are of such a larger magnitude than this call regressions. <details> ``` sync/no-hook/host-to-wasm - typed - nop time: [28.683 ns 28.757 ns 28.844 ns] change: [+16.472% +17.183% +17.904%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 1 (1.00%) low mild 4 (4.00%) high mild 5 (5.00%) high severe sync/no-hook/host-to-wasm - untyped - nop time: [42.515 ns 42.652 ns 42.841 ns] change: [+12.371% +14.614% +17.462%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 1 (1.00%) high mild 10 (10.00%) high severe sync/no-hook/host-to-wasm - unchecked - nop time: [33.936 ns 34.052 ns 34.179 ns] change: [+25.478% +26.938% +28.369%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 7 (7.00%) high mild 2 (2.00%) high severe sync/no-hook/host-to-wasm - typed - nop-params-and-results time: [34.290 ns 34.388 ns 34.502 ns] change: [+40.802% +42.706% +44.526%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 5 (5.00%) high mild 8 (8.00%) high severe sync/no-hook/host-to-wasm - untyped - nop-params-and-results time: [62.546 ns 62.721 ns 62.919 ns] change: [+2.5014% +3.6319% +4.8078%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 2 (2.00%) high mild 10 (10.00%) high severe sync/no-hook/host-to-wasm - unchecked - nop-params-and-results time: [42.609 ns 42.710 ns 42.831 ns] change: [+20.966% +22.282% +23.475%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 4 (4.00%) high mild 7 (7.00%) high severe sync/hook-sync/host-to-wasm - typed - nop time: [29.546 ns 29.675 ns 29.818 ns] change: [+20.693% +21.794% +22.836%] (p = 0.00 < 0.05) Performance has regressed. Found 5 outliers among 100 measurements (5.00%) 3 (3.00%) high mild 2 (2.00%) high severe sync/hook-sync/host-to-wasm - untyped - nop time: [45.448 ns 45.699 ns 45.961 ns] change: [+17.204% +18.514% +19.590%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 4 (4.00%) high mild 10 (10.00%) high severe sync/hook-sync/host-to-wasm - unchecked - nop time: [34.334 ns 34.437 ns 34.558 ns] change: [+23.225% +24.477% +25.886%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 5 (5.00%) high mild 7 (7.00%) high severe sync/hook-sync/host-to-wasm - typed - nop-params-and-results time: [36.594 ns 36.763 ns 36.974 ns] change: [+41.967% +47.261% +52.086%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 3 (3.00%) high mild 9 (9.00%) high severe sync/hook-sync/host-to-wasm - untyped - nop-params-and-results time: [63.541 ns 63.831 ns 64.194 ns] change: [-4.4337% -0.6855% +2.7134%] (p = 0.73 > 0.05) No change in performance detected. Found 8 outliers among 100 measurements (8.00%) 6 (6.00%) high mild 2 (2.00%) high severe sync/hook-sync/host-to-wasm - unchecked - nop-params-and-results time: [43.968 ns 44.169 ns 44.437 ns] change: [+18.772% +21.802% +24.623%] (p = 0.00 < 0.05) Performance has regressed. Found 15 outliers among 100 measurements (15.00%) 3 (3.00%) high mild 12 (12.00%) high severe async/no-hook/host-to-wasm - typed - nop time: [4.9612 us 4.9743 us 4.9889 us] change: [+9.9493% +11.911% +13.502%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 6 (6.00%) high mild 4 (4.00%) high severe async/no-hook/host-to-wasm - untyped - nop time: [5.0030 us 5.0211 us 5.0439 us] change: [+10.841% +11.873% +12.977%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 3 (3.00%) high mild 7 (7.00%) high severe async/no-hook/host-to-wasm - typed - nop-params-and-results time: [4.9273 us 4.9468 us 4.9700 us] change: [+4.7381% +6.8445% +8.8238%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 5 (5.00%) high mild 9 (9.00%) high severe async/no-hook/host-to-wasm - untyped - nop-params-and-results time: [5.1151 us 5.1338 us 5.1555 us] change: [+9.5335% +11.290% +13.044%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 3 (3.00%) high mild 13 (13.00%) high severe async/hook-sync/host-to-wasm - typed - nop time: [4.9330 us 4.9394 us 4.9467 us] change: [+10.046% +11.038% +12.035%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 5 (5.00%) high mild 7 (7.00%) high severe async/hook-sync/host-to-wasm - untyped - nop time: [5.0073 us 5.0183 us 5.0310 us] change: [+9.3828% +10.565% +11.752%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 3 (3.00%) high mild 5 (5.00%) high severe async/hook-sync/host-to-wasm - typed - nop-params-and-results time: [4.9610 us 4.9839 us 5.0097 us] change: [+9.0857% +11.513% +14.359%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 7 (7.00%) high mild 6 (6.00%) high severe async/hook-sync/host-to-wasm - untyped - nop-params-and-results time: [5.0995 us 5.1272 us 5.1617 us] change: [+9.3600% +11.506% +13.809%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 6 (6.00%) high mild 4 (4.00%) high severe async-pool/no-hook/host-to-wasm - typed - nop time: [2.4242 us 2.4316 us 2.4396 us] change: [+7.8756% +8.8803% +9.8346%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 5 (5.00%) high mild 3 (3.00%) high severe async-pool/no-hook/host-to-wasm - untyped - nop time: [2.5102 us 2.5155 us 2.5210 us] change: [+12.130% +13.194% +14.270%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 4 (4.00%) high mild 8 (8.00%) high severe async-pool/no-hook/host-to-wasm - typed - nop-params-and-results time: [2.4203 us 2.4310 us 2.4440 us] change: [+4.0380% +6.3623% +8.7534%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 5 (5.00%) high mild 9 (9.00%) high severe async-pool/no-hook/host-to-wasm - untyped - nop-params-and-results time: [2.5501 us 2.5593 us 2.5700 us] change: [+8.8802% +10.976% +12.937%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 5 (5.00%) high mild 11 (11.00%) high severe async-pool/hook-sync/host-to-wasm - typed - nop time: [2.4135 us 2.4190 us 2.4254 us] change: [+8.3640% +9.3774% +10.435%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 6 (6.00%) high mild 5 (5.00%) high severe async-pool/hook-sync/host-to-wasm - untyped - nop time: [2.5172 us 2.5248 us 2.5357 us] change: [+11.543% +12.750% +13.982%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 1 (1.00%) high mild 7 (7.00%) high severe async-pool/hook-sync/host-to-wasm - typed - nop-params-and-results time: [2.4214 us 2.4353 us 2.4532 us] change: [+1.5158% +5.0872% +8.6765%] (p = 0.00 < 0.05) Performance has regressed. Found 15 outliers among 100 measurements (15.00%) 2 (2.00%) high mild 13 (13.00%) high severe async-pool/hook-sync/host-to-wasm - untyped - nop-params-and-results time: [2.5499 us 2.5607 us 2.5748 us] change: [+10.146% +12.459% +14.919%] (p = 0.00 < 0.05) Performance has regressed. Found 18 outliers among 100 measurements (18.00%) 3 (3.00%) high mild 15 (15.00%) high severe sync/no-hook/wasm-to-host - nop - typed time: [6.6135 ns 6.6288 ns 6.6452 ns] change: [+37.927% +38.837% +39.869%] (p = 0.00 < 0.05) Performance has regressed. Found 7 outliers among 100 measurements (7.00%) 2 (2.00%) high mild 5 (5.00%) high severe sync/no-hook/wasm-to-host - nop-params-and-results - typed time: [15.930 ns 15.993 ns 16.067 ns] change: [+3.9583% +5.6286% +7.2430%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 11 (11.00%) high mild 1 (1.00%) high severe sync/no-hook/wasm-to-host - nop - untyped time: [20.596 ns 20.640 ns 20.690 ns] change: [+4.3293% +5.2047% +6.0935%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 5 (5.00%) high mild 5 (5.00%) high severe sync/no-hook/wasm-to-host - nop-params-and-results - untyped time: [42.659 ns 42.882 ns 43.159 ns] change: [-2.1466% -0.5079% +1.2554%] (p = 0.58 > 0.05) No change in performance detected. Found 15 outliers among 100 measurements (15.00%) 1 (1.00%) high mild 14 (14.00%) high severe sync/no-hook/wasm-to-host - nop - unchecked time: [10.671 ns 10.691 ns 10.713 ns] change: [+83.911% +87.620% +92.062%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 2 (2.00%) high mild 7 (7.00%) high severe sync/no-hook/wasm-to-host - nop-params-and-results - unchecked time: [11.136 ns 11.190 ns 11.263 ns] change: [-29.719% -28.446% -27.029%] (p = 0.00 < 0.05) Performance has improved. Found 14 outliers among 100 measurements (14.00%) 4 (4.00%) high mild 10 (10.00%) high severe sync/hook-sync/wasm-to-host - nop - typed time: [6.7964 ns 6.8087 ns 6.8226 ns] change: [+21.531% +24.206% +27.331%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 4 (4.00%) high mild 10 (10.00%) high severe sync/hook-sync/wasm-to-host - nop-params-and-results - typed time: [15.865 ns 15.921 ns 15.985 ns] change: [+4.8466% +6.3330% +7.8317%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 3 (3.00%) high mild 13 (13.00%) high severe sync/hook-sync/wasm-to-host - nop - untyped time: [21.505 ns 21.587 ns 21.677 ns] change: [+8.0908% +9.1943% +10.254%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 4 (4.00%) high mild 4 (4.00%) high severe sync/hook-sync/wasm-to-host - nop-params-and-results - untyped time: [44.018 ns 44.128 ns 44.261 ns] change: [-1.4671% -0.0458% +1.2443%] (p = 0.94 > 0.05) No change in performance detected. Found 14 outliers among 100 measurements (14.00%) 5 (5.00%) high mild 9 (9.00%) high severe sync/hook-sync/wasm-to-host - nop - unchecked time: [11.264 ns 11.326 ns 11.387 ns] change: [+80.225% +81.659% +83.068%] (p = 0.00 < 0.05) Performance has regressed. Found 6 outliers among 100 measurements (6.00%) 3 (3.00%) high mild 3 (3.00%) high severe sync/hook-sync/wasm-to-host - nop-params-and-results - unchecked time: [11.816 ns 11.865 ns 11.920 ns] change: [-29.152% -28.040% -26.957%] (p = 0.00 < 0.05) Performance has improved. Found 14 outliers among 100 measurements (14.00%) 8 (8.00%) high mild 6 (6.00%) high severe async/no-hook/wasm-to-host - nop - typed time: [6.6221 ns 6.6385 ns 6.6569 ns] change: [+43.618% +44.755% +45.965%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 6 (6.00%) high mild 7 (7.00%) high severe async/no-hook/wasm-to-host - nop-params-and-results - typed time: [15.884 ns 15.929 ns 15.983 ns] change: [+3.5987% +5.2053% +6.7846%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 3 (3.00%) high mild 13 (13.00%) high severe async/no-hook/wasm-to-host - nop - untyped time: [20.615 ns 20.702 ns 20.821 ns] change: [+6.9799% +8.1212% +9.2819%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 2 (2.00%) high mild 8 (8.00%) high severe async/no-hook/wasm-to-host - nop-params-and-results - untyped time: [41.956 ns 42.207 ns 42.521 ns] change: [-4.3057% -2.7730% -1.2428%] (p = 0.00 < 0.05) Performance has improved. Found 14 outliers among 100 measurements (14.00%) 3 (3.00%) high mild 11 (11.00%) high severe async/no-hook/wasm-to-host - nop - unchecked time: [10.440 ns 10.474 ns 10.513 ns] change: [+83.959% +85.826% +87.541%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 5 (5.00%) high mild 6 (6.00%) high severe async/no-hook/wasm-to-host - nop-params-and-results - unchecked time: [11.476 ns 11.512 ns 11.554 ns] change: [-29.857% -28.383% -26.978%] (p = 0.00 < 0.05) Performance has improved. Found 12 outliers among 100 measurements (12.00%) 1 (1.00%) low mild 6 (6.00%) high mild 5 (5.00%) high severe async/no-hook/wasm-to-host - nop - async-typed time: [26.427 ns 26.478 ns 26.532 ns] change: [+6.5730% +7.4676% +8.3983%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 2 (2.00%) high mild 7 (7.00%) high severe async/no-hook/wasm-to-host - nop-params-and-results - async-typed time: [28.557 ns 28.693 ns 28.880 ns] change: [+1.9099% +3.7332% +5.9731%] (p = 0.00 < 0.05) Performance has regressed. Found 15 outliers among 100 measurements (15.00%) 1 (1.00%) high mild 14 (14.00%) high severe async/hook-sync/wasm-to-host - nop - typed time: [6.7488 ns 6.7630 ns 6.7784 ns] change: [+19.935% +22.080% +23.683%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 4 (4.00%) high mild 5 (5.00%) high severe async/hook-sync/wasm-to-host - nop-params-and-results - typed time: [15.928 ns 16.031 ns 16.149 ns] change: [+5.5188% +6.9567% +8.3839%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 9 (9.00%) high mild 2 (2.00%) high severe async/hook-sync/wasm-to-host - nop - untyped time: [21.930 ns 22.114 ns 22.296 ns] change: [+4.6674% +7.7588% +10.375%] (p = 0.00 < 0.05) Performance has regressed. Found 4 outliers among 100 measurements (4.00%) 3 (3.00%) high mild 1 (1.00%) high severe async/hook-sync/wasm-to-host - nop-params-and-results - untyped time: [42.684 ns 42.858 ns 43.081 ns] change: [-5.2957% -3.4693% -1.6217%] (p = 0.00 < 0.05) Performance has improved. Found 14 outliers among 100 measurements (14.00%) 2 (2.00%) high mild 12 (12.00%) high severe async/hook-sync/wasm-to-host - nop - unchecked time: [11.026 ns 11.053 ns 11.086 ns] change: [+70.751% +72.378% +73.961%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 5 (5.00%) high mild 5 (5.00%) high severe async/hook-sync/wasm-to-host - nop-params-and-results - unchecked time: [11.840 ns 11.900 ns 11.982 ns] change: [-27.977% -26.584% -24.887%] (p = 0.00 < 0.05) Performance has improved. Found 18 outliers among 100 measurements (18.00%) 3 (3.00%) high mild 15 (15.00%) high severe async/hook-sync/wasm-to-host - nop - async-typed time: [27.601 ns 27.709 ns 27.882 ns] change: [+8.1781% +9.1102% +10.030%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 2 (2.00%) low mild 3 (3.00%) high mild 6 (6.00%) high severe async/hook-sync/wasm-to-host - nop-params-and-results - async-typed time: [28.955 ns 29.174 ns 29.413 ns] change: [+1.1226% +3.0366% +5.1126%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 7 (7.00%) high mild 6 (6.00%) high severe async-pool/no-hook/wasm-to-host - nop - typed time: [6.5626 ns 6.5733 ns 6.5851 ns] change: [+40.561% +42.307% +44.514%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 5 (5.00%) high mild 4 (4.00%) high severe async-pool/no-hook/wasm-to-host - nop-params-and-results - typed time: [15.820 ns 15.886 ns 15.969 ns] change: [+4.1044% +5.7928% +7.7122%] (p = 0.00 < 0.05) Performance has regressed. Found 17 outliers among 100 measurements (17.00%) 4 (4.00%) high mild 13 (13.00%) high severe async-pool/no-hook/wasm-to-host - nop - untyped time: [20.481 ns 20.521 ns 20.566 ns] change: [+6.7962% +7.6950% +8.7612%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 6 (6.00%) high mild 5 (5.00%) high severe async-pool/no-hook/wasm-to-host - nop-params-and-results - untyped time: [41.834 ns 41.998 ns 42.189 ns] change: [-3.8185% -2.2687% -0.7541%] (p = 0.01 < 0.05) Change within noise threshold. Found 13 outliers among 100 measurements (13.00%) 3 (3.00%) high mild 10 (10.00%) high severe async-pool/no-hook/wasm-to-host - nop - unchecked time: [10.353 ns 10.380 ns 10.414 ns] change: [+82.042% +84.591% +87.205%] (p = 0.00 < 0.05) Performance has regressed. Found 7 outliers among 100 measurements (7.00%) 4 (4.00%) high mild 3 (3.00%) high severe async-pool/no-hook/wasm-to-host - nop-params-and-results - unchecked time: [11.123 ns 11.168 ns 11.228 ns] change: [-30.813% -29.285% -27.874%] (p = 0.00 < 0.05) Performance has improved. Found 12 outliers among 100 measurements (12.00%) 11 (11.00%) high mild 1 (1.00%) high severe async-pool/no-hook/wasm-to-host - nop - async-typed time: [27.442 ns 27.528 ns 27.638 ns] change: [+7.5215% +9.9795% +12.266%] (p = 0.00 < 0.05) Performance has regressed. Found 18 outliers among 100 measurements (18.00%) 3 (3.00%) high mild 15 (15.00%) high severe async-pool/no-hook/wasm-to-host - nop-params-and-results - async-typed time: [29.014 ns 29.148 ns 29.312 ns] change: [+2.0227% +3.4722% +4.9047%] (p = 0.00 < 0.05) Performance has regressed. Found 7 outliers among 100 measurements (7.00%) 6 (6.00%) high mild 1 (1.00%) high severe async-pool/hook-sync/wasm-to-host - nop - typed time: [6.7916 ns 6.8116 ns 6.8325 ns] change: [+20.937% +22.050% +23.281%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 5 (5.00%) high mild 6 (6.00%) high severe async-pool/hook-sync/wasm-to-host - nop-params-and-results - typed time: [15.917 ns 15.975 ns 16.051 ns] change: [+4.6404% +6.4217% +8.3075%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 5 (5.00%) high mild 11 (11.00%) high severe async-pool/hook-sync/wasm-to-host - nop - untyped time: [21.558 ns 21.612 ns 21.679 ns] change: [+8.1158% +9.1409% +10.217%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 2 (2.00%) high mild 7 (7.00%) high severe async-pool/hook-sync/wasm-to-host - nop-params-and-results - untyped time: [42.475 ns 42.614 ns 42.775 ns] change: [-6.3613% -4.4709% -2.7647%] (p = 0.00 < 0.05) Performance has improved. Found 18 outliers among 100 measurements (18.00%) 3 (3.00%) high mild 15 (15.00%) high severe async-pool/hook-sync/wasm-to-host - nop - unchecked time: [11.150 ns 11.195 ns 11.247 ns] change: [+74.424% +77.056% +79.811%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 3 (3.00%) high mild 11 (11.00%) high severe async-pool/hook-sync/wasm-to-host - nop-params-and-results - unchecked time: [11.639 ns 11.695 ns 11.760 ns] change: [-30.212% -29.023% -27.954%] (p = 0.00 < 0.05) Performance has improved. Found 15 outliers among 100 measurements (15.00%) 7 (7.00%) high mild 8 (8.00%) high severe async-pool/hook-sync/wasm-to-host - nop - async-typed time: [27.480 ns 27.712 ns 27.984 ns] change: [+2.9764% +6.5061% +9.8914%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 6 (6.00%) high mild 2 (2.00%) high severe async-pool/hook-sync/wasm-to-host - nop-params-and-results - async-typed time: [29.218 ns 29.380 ns 29.600 ns] change: [+5.2283% +7.7247% +10.822%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 2 (2.00%) high mild 14 (14.00%) high severe ``` </details> * Add s390x support for frame pointer-based stack walking * wasmtime: Allow `Caller::get_export` to get all exports * fuzzing: Add a fuzz target to check that our stack traces are correct We generate Wasm modules that keep track of their own stack as they call and return between functions, and then we periodically check that if the host captures a backtrace, it matches what the Wasm module has recorded. * Remove VM offsets for `VMHostFuncContext` since it isn't used by JIT code * Add doc comment with stack walking implementation notes * Document the extra state that can be passed to `wasmtime_runtime::Backtrace` methods * Add extensive comments for stack walking function * Factor architecture-specific bits of stack walking out into modules * Initialize store-related fields in a vmctx to null when there is no store yet Rather than leaving them as uninitialized data. * Use `set_callee` instead of manually setting the vmctx field * Use a more informative compile error message for unsupported architectures * Document unsafety of `prepare_host_to_wasm_trampoline` * Use `bti c` instead of `hint #34` in inline aarch64 assembly * Remove outdated TODO comment * Remove setting of `last_wasm_exit_fp` in `set_jit_trap` This is no longer needed as the value is plumbed through to the backtrace code directly now. * Only set the stack limit once, in the face of re-entrancy into Wasm * Add comments for s390x-specific stack walking bits * Use the helper macro for all libcalls If we forget to use it, and then trigger a GC from the libcall, that means we could miss stack frames when walking the stack, fail to find live GC refs, and then get use after free bugs. Much less risky to always use the helper macro that takes care of all of that for us. * Use the `asm_sym!` macro in Wasm-to-libcall trampolines This macro handles the macOS-specific underscore prefix stuff for us. * wasmtime: add size and align to `externref` assertion error message * Extend the `stacks` fuzzer to have host frames in between Wasm frames This way we get one or more contiguous sequences of Wasm frames on the stack, instead of exactly one. * Add documentation for aarch64-specific backtrace helpers * Clarify that we only support little-endian aarch64 in trampoline comment * Use `.machine z13` in s390x assembly file Since apparently our CI machines have pretty old assemblers that don't have `.machine z14`. This should be fine though since these trampolines don't make use of anything that is introduced in z14. * Fix aarch64 build * Fix macOS build * Document the `asm_sym!` macro * Add windows support to the `wasmtime-asm-macros` crate * Add windows support to host<--->Wasm trampolines * Fix trap handler build on windows * Run `rustfmt` on s390x trampoline source file * Temporarily disable some assertions about a trap's backtrace in the component model tests Follow up to re-enable this and fix the associated issue: https://github.com/bytecodealliance/wasmtime/issues/4535 * Refactor libcall definitions with less macros This refactors the `libcall!` macro to use the `foreach_builtin_function!` macro to define all of the trampolines. Additionally the macro surrounding each libcall itself is no longer necessary and helps avoid too many macros. * Use `VMOpaqueContext::from_vm_host_func_context` in `VMHostFuncContext::new` * Move `backtrace` module to be submodule of `traphandlers` This avoids making some things `pub(crate)` in `traphandlers` that really shouldn't be. * Fix macOS aarch64 build * Use "i64" instead of "word" in aarch64-specific file * Save/restore entry SP and exit FP/return pointer in the face of panicking imported host functions Also clean up assertions surrounding our saved entry/exit registers. * Put "typed" vs "untyped" in the same position of call benchmark names Regardless if we are doing wasm-to-host or host-to-wasm * Fix stacks test case generator build for new `wasm-encoder` * Fix build for s390x * Expand libcalls in s390x asm * Disable more parts of component tests now that backtrace assertions are a bit tighter * Remove assertion that can maybe fail on s390x Co-authored-by: Ulrich Weigand <ulrich.weigand@de.ibm.com> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
2 years ago
"paste",
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
"rand 0.8.5",
Update to rustix 0.26.2. (#3521) This pulls in a fix for Android, where Android's seccomp policy on older versions is to make `openat2` irrecoverably crash the process, so we have to do a version check up front rather than relying on `ENOSYS` to determine if `openat2` is supported. And it pulls in the fix for the link errors when multiple versions of rsix/rustix are linked in. And it has updates for two crate renamings: rsix has been renamed to rustix, and unsafe-io has been renamed to io-extras.
3 years ago
"rustix",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"thiserror",
`wasmtime`: Implement fast Wasm stack walking (#4431) * Always preserve frame pointers in Wasmtime This allows us to efficiently and simply capture Wasm stacks without maintaining and synchronizing any safety-critical side tables between the compiler and the runtime. * wasmtime: Implement fast Wasm stack walking Why do we want Wasm stack walking to be fast? Because we capture stacks whenever there is a trap and traps actually happen fairly frequently with short-lived programs and WASI's `exit`. Previously, we would rely on generating the system unwind info (e.g. `.eh_frame`) and using the system unwinder (via the `backtrace`crate) to walk the full stack and filter out any non-Wasm stack frames. This can, unfortunately, be slow for two primary reasons: 1. The system unwinder is doing `O(all-kinds-of-frames)` work rather than `O(wasm-frames)` work. 2. System unwind info and the system unwinder need to be much more general than a purpose-built stack walker for Wasm needs to be. It has to handle any kind of stack frame that any compiler might emit where as our Wasm frames are emitted by Cranelift and always have frame pointers. This translates into implementation complexity and general overhead. There can also be unnecessary-for-our-use-cases global synchronization and locks involved, further slowing down stack walking in the presence of multiple threads trying to capture stacks in parallel. This commit introduces a purpose-built stack walker for traversing just our Wasm frames. To find all the sequences of Wasm-to-Wasm stack frames, and ignore non-Wasm stack frames, we keep a linked list of `(entry stack pointer, exit frame pointer)` pairs. This linked list is maintained via Wasm-to-host and host-to-Wasm trampolines. Within a sequence of Wasm-to-Wasm calls, we can use frame pointers (which Cranelift preserves) to find the next older Wasm frame on the stack, and we keep doing this until we reach the entry stack pointer, meaning that the next older frame will be a host frame. The trampolines need to avoid a couple stumbling blocks. First, they need to be compiled ahead of time, since we may not have access to a compiler at runtime (e.g. if the `cranelift` feature is disabled) but still want to be able to call functions that have already been compiled and get stack traces for those functions. Usually this means we would compile the appropriate trampolines inside `Module::new` and the compiled module object would hold the trampolines. However, we *also* need to support calling host functions that are wrapped into `wasmtime::Func`s and there doesn't exist *any* ahead-of-time compiled module object to hold the appropriate trampolines: ```rust // Define a host function. let func_type = wasmtime::FuncType::new( vec![wasmtime::ValType::I32], vec![wasmtime::ValType::I32], ); let func = Func::new(&mut store, func_type, |_, params, results| { // ... Ok(()) }); // Call that host function. let mut results = vec![wasmtime::Val::I32(0)]; func.call(&[wasmtime::Val::I32(0)], &mut results)?; ``` Therefore, we define one host-to-Wasm trampoline and one Wasm-to-host trampoline in assembly that work for all Wasm and host function signatures. These trampolines are careful to only use volatile registers, avoid touching any register that is an argument in the calling convention ABI, and tail call to the target callee function. This allows forwarding any set of arguments and any returns to and from the callee, while also allowing us to maintain our linked list of Wasm stack and frame pointers before transferring control to the callee. These trampolines are not used in Wasm-to-Wasm calls, only when crossing the host-Wasm boundary, so they do not impose overhead on regular calls. (And if using one trampoline for all host-Wasm boundary crossing ever breaks branch prediction enough in the CPU to become any kind of bottleneck, we can do fun things like have multiple copies of the same trampoline and choose a random copy for each function, sharding the functions across branch predictor entries.) Finally, this commit also ends the use of a synthetic `Module` and allocating a stubbed out `VMContext` for host functions. Instead, we define a `VMHostFuncContext` with its own magic value, similar to `VMComponentContext`, specifically for host functions. <h2>Benchmarks</h2> <h3>Traps and Stack Traces</h3> Large improvements to taking stack traces on traps, ranging from shaving off 64% to 99.95% of the time it used to take. <details> ``` multi-threaded-traps/0 time: [2.5686 us 2.5808 us 2.5934 us] thrpt: [0.0000 elem/s 0.0000 elem/s 0.0000 elem/s] change: time: [-85.419% -85.153% -84.869%] (p = 0.00 < 0.05) thrpt: [+560.90% +573.56% +585.84%] Performance has improved. Found 8 outliers among 100 measurements (8.00%) 4 (4.00%) high mild 4 (4.00%) high severe multi-threaded-traps/1 time: [2.9021 us 2.9167 us 2.9322 us] thrpt: [341.04 Kelem/s 342.86 Kelem/s 344.58 Kelem/s] change: time: [-91.455% -91.294% -91.096%] (p = 0.00 < 0.05) thrpt: [+1023.1% +1048.6% +1070.3%] Performance has improved. Found 6 outliers among 100 measurements (6.00%) 1 (1.00%) high mild 5 (5.00%) high severe multi-threaded-traps/2 time: [2.9996 us 3.0145 us 3.0295 us] thrpt: [660.18 Kelem/s 663.47 Kelem/s 666.76 Kelem/s] change: time: [-94.040% -93.910% -93.762%] (p = 0.00 < 0.05) thrpt: [+1503.1% +1542.0% +1578.0%] Performance has improved. Found 5 outliers among 100 measurements (5.00%) 5 (5.00%) high severe multi-threaded-traps/4 time: [5.5768 us 5.6052 us 5.6364 us] thrpt: [709.68 Kelem/s 713.63 Kelem/s 717.25 Kelem/s] change: time: [-93.193% -93.121% -93.052%] (p = 0.00 < 0.05) thrpt: [+1339.2% +1353.6% +1369.1%] Performance has improved. multi-threaded-traps/8 time: [8.6408 us 9.1212 us 9.5438 us] thrpt: [838.24 Kelem/s 877.08 Kelem/s 925.84 Kelem/s] change: time: [-94.754% -94.473% -94.202%] (p = 0.00 < 0.05) thrpt: [+1624.7% +1709.2% +1806.1%] Performance has improved. multi-threaded-traps/16 time: [10.152 us 10.840 us 11.545 us] thrpt: [1.3858 Melem/s 1.4760 Melem/s 1.5761 Melem/s] change: time: [-97.042% -96.823% -96.577%] (p = 0.00 < 0.05) thrpt: [+2821.5% +3048.1% +3281.1%] Performance has improved. Found 1 outliers among 100 measurements (1.00%) 1 (1.00%) high mild many-modules-registered-traps/1 time: [2.6278 us 2.6361 us 2.6447 us] thrpt: [378.11 Kelem/s 379.35 Kelem/s 380.55 Kelem/s] change: time: [-85.311% -85.108% -84.909%] (p = 0.00 < 0.05) thrpt: [+562.65% +571.51% +580.76%] Performance has improved. Found 9 outliers among 100 measurements (9.00%) 3 (3.00%) high mild 6 (6.00%) high severe many-modules-registered-traps/8 time: [2.6294 us 2.6460 us 2.6623 us] thrpt: [3.0049 Melem/s 3.0235 Melem/s 3.0425 Melem/s] change: time: [-85.895% -85.485% -85.022%] (p = 0.00 < 0.05) thrpt: [+567.63% +588.95% +608.95%] Performance has improved. Found 8 outliers among 100 measurements (8.00%) 3 (3.00%) high mild 5 (5.00%) high severe many-modules-registered-traps/64 time: [2.6218 us 2.6329 us 2.6452 us] thrpt: [24.195 Melem/s 24.308 Melem/s 24.411 Melem/s] change: time: [-93.629% -93.551% -93.470%] (p = 0.00 < 0.05) thrpt: [+1431.4% +1450.6% +1469.5%] Performance has improved. Found 3 outliers among 100 measurements (3.00%) 3 (3.00%) high mild many-modules-registered-traps/512 time: [2.6569 us 2.6737 us 2.6923 us] thrpt: [190.17 Melem/s 191.50 Melem/s 192.71 Melem/s] change: time: [-99.277% -99.268% -99.260%] (p = 0.00 < 0.05) thrpt: [+13417% +13566% +13731%] Performance has improved. Found 4 outliers among 100 measurements (4.00%) 4 (4.00%) high mild many-modules-registered-traps/4096 time: [2.7258 us 2.7390 us 2.7535 us] thrpt: [1.4876 Gelem/s 1.4955 Gelem/s 1.5027 Gelem/s] change: time: [-99.956% -99.955% -99.955%] (p = 0.00 < 0.05) thrpt: [+221417% +223380% +224881%] Performance has improved. Found 2 outliers among 100 measurements (2.00%) 1 (1.00%) high mild 1 (1.00%) high severe many-stack-frames-traps/1 time: [1.4658 us 1.4719 us 1.4784 us] thrpt: [676.39 Kelem/s 679.38 Kelem/s 682.21 Kelem/s] change: time: [-90.368% -89.947% -89.586%] (p = 0.00 < 0.05) thrpt: [+860.23% +894.72% +938.21%] Performance has improved. Found 8 outliers among 100 measurements (8.00%) 5 (5.00%) high mild 3 (3.00%) high severe many-stack-frames-traps/8 time: [2.4772 us 2.4870 us 2.4973 us] thrpt: [3.2034 Melem/s 3.2167 Melem/s 3.2294 Melem/s] change: time: [-85.550% -85.370% -85.199%] (p = 0.00 < 0.05) thrpt: [+575.65% +583.51% +592.03%] Performance has improved. Found 8 outliers among 100 measurements (8.00%) 4 (4.00%) high mild 4 (4.00%) high severe many-stack-frames-traps/64 time: [10.109 us 10.171 us 10.236 us] thrpt: [6.2525 Melem/s 6.2925 Melem/s 6.3309 Melem/s] change: time: [-78.144% -77.797% -77.336%] (p = 0.00 < 0.05) thrpt: [+341.22% +350.38% +357.55%] Performance has improved. Found 7 outliers among 100 measurements (7.00%) 5 (5.00%) high mild 2 (2.00%) high severe many-stack-frames-traps/512 time: [126.16 us 126.54 us 126.96 us] thrpt: [4.0329 Melem/s 4.0461 Melem/s 4.0583 Melem/s] change: time: [-65.364% -64.933% -64.453%] (p = 0.00 < 0.05) thrpt: [+181.32% +185.17% +188.71%] Performance has improved. Found 4 outliers among 100 measurements (4.00%) 4 (4.00%) high severe ``` </details> <h3>Calls</h3> There is, however, a small regression in raw Wasm-to-host and host-to-Wasm call performance due the new trampolines. It seems to be on the order of about 2-10 nanoseconds per call, depending on the benchmark. I believe this regression is ultimately acceptable because 1. this overhead will be vastly dominated by whatever work a non-nop callee actually does, 2. we will need these trampolines, or something like them, when implementing the Wasm exceptions proposal to do things like translate Wasm's exceptions into Rust's `Result`s, 3. and because the performance improvements to trapping and capturing stack traces are of such a larger magnitude than this call regressions. <details> ``` sync/no-hook/host-to-wasm - typed - nop time: [28.683 ns 28.757 ns 28.844 ns] change: [+16.472% +17.183% +17.904%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 1 (1.00%) low mild 4 (4.00%) high mild 5 (5.00%) high severe sync/no-hook/host-to-wasm - untyped - nop time: [42.515 ns 42.652 ns 42.841 ns] change: [+12.371% +14.614% +17.462%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 1 (1.00%) high mild 10 (10.00%) high severe sync/no-hook/host-to-wasm - unchecked - nop time: [33.936 ns 34.052 ns 34.179 ns] change: [+25.478% +26.938% +28.369%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 7 (7.00%) high mild 2 (2.00%) high severe sync/no-hook/host-to-wasm - typed - nop-params-and-results time: [34.290 ns 34.388 ns 34.502 ns] change: [+40.802% +42.706% +44.526%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 5 (5.00%) high mild 8 (8.00%) high severe sync/no-hook/host-to-wasm - untyped - nop-params-and-results time: [62.546 ns 62.721 ns 62.919 ns] change: [+2.5014% +3.6319% +4.8078%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 2 (2.00%) high mild 10 (10.00%) high severe sync/no-hook/host-to-wasm - unchecked - nop-params-and-results time: [42.609 ns 42.710 ns 42.831 ns] change: [+20.966% +22.282% +23.475%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 4 (4.00%) high mild 7 (7.00%) high severe sync/hook-sync/host-to-wasm - typed - nop time: [29.546 ns 29.675 ns 29.818 ns] change: [+20.693% +21.794% +22.836%] (p = 0.00 < 0.05) Performance has regressed. Found 5 outliers among 100 measurements (5.00%) 3 (3.00%) high mild 2 (2.00%) high severe sync/hook-sync/host-to-wasm - untyped - nop time: [45.448 ns 45.699 ns 45.961 ns] change: [+17.204% +18.514% +19.590%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 4 (4.00%) high mild 10 (10.00%) high severe sync/hook-sync/host-to-wasm - unchecked - nop time: [34.334 ns 34.437 ns 34.558 ns] change: [+23.225% +24.477% +25.886%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 5 (5.00%) high mild 7 (7.00%) high severe sync/hook-sync/host-to-wasm - typed - nop-params-and-results time: [36.594 ns 36.763 ns 36.974 ns] change: [+41.967% +47.261% +52.086%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 3 (3.00%) high mild 9 (9.00%) high severe sync/hook-sync/host-to-wasm - untyped - nop-params-and-results time: [63.541 ns 63.831 ns 64.194 ns] change: [-4.4337% -0.6855% +2.7134%] (p = 0.73 > 0.05) No change in performance detected. Found 8 outliers among 100 measurements (8.00%) 6 (6.00%) high mild 2 (2.00%) high severe sync/hook-sync/host-to-wasm - unchecked - nop-params-and-results time: [43.968 ns 44.169 ns 44.437 ns] change: [+18.772% +21.802% +24.623%] (p = 0.00 < 0.05) Performance has regressed. Found 15 outliers among 100 measurements (15.00%) 3 (3.00%) high mild 12 (12.00%) high severe async/no-hook/host-to-wasm - typed - nop time: [4.9612 us 4.9743 us 4.9889 us] change: [+9.9493% +11.911% +13.502%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 6 (6.00%) high mild 4 (4.00%) high severe async/no-hook/host-to-wasm - untyped - nop time: [5.0030 us 5.0211 us 5.0439 us] change: [+10.841% +11.873% +12.977%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 3 (3.00%) high mild 7 (7.00%) high severe async/no-hook/host-to-wasm - typed - nop-params-and-results time: [4.9273 us 4.9468 us 4.9700 us] change: [+4.7381% +6.8445% +8.8238%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 5 (5.00%) high mild 9 (9.00%) high severe async/no-hook/host-to-wasm - untyped - nop-params-and-results time: [5.1151 us 5.1338 us 5.1555 us] change: [+9.5335% +11.290% +13.044%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 3 (3.00%) high mild 13 (13.00%) high severe async/hook-sync/host-to-wasm - typed - nop time: [4.9330 us 4.9394 us 4.9467 us] change: [+10.046% +11.038% +12.035%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 5 (5.00%) high mild 7 (7.00%) high severe async/hook-sync/host-to-wasm - untyped - nop time: [5.0073 us 5.0183 us 5.0310 us] change: [+9.3828% +10.565% +11.752%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 3 (3.00%) high mild 5 (5.00%) high severe async/hook-sync/host-to-wasm - typed - nop-params-and-results time: [4.9610 us 4.9839 us 5.0097 us] change: [+9.0857% +11.513% +14.359%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 7 (7.00%) high mild 6 (6.00%) high severe async/hook-sync/host-to-wasm - untyped - nop-params-and-results time: [5.0995 us 5.1272 us 5.1617 us] change: [+9.3600% +11.506% +13.809%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 6 (6.00%) high mild 4 (4.00%) high severe async-pool/no-hook/host-to-wasm - typed - nop time: [2.4242 us 2.4316 us 2.4396 us] change: [+7.8756% +8.8803% +9.8346%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 5 (5.00%) high mild 3 (3.00%) high severe async-pool/no-hook/host-to-wasm - untyped - nop time: [2.5102 us 2.5155 us 2.5210 us] change: [+12.130% +13.194% +14.270%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 4 (4.00%) high mild 8 (8.00%) high severe async-pool/no-hook/host-to-wasm - typed - nop-params-and-results time: [2.4203 us 2.4310 us 2.4440 us] change: [+4.0380% +6.3623% +8.7534%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 5 (5.00%) high mild 9 (9.00%) high severe async-pool/no-hook/host-to-wasm - untyped - nop-params-and-results time: [2.5501 us 2.5593 us 2.5700 us] change: [+8.8802% +10.976% +12.937%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 5 (5.00%) high mild 11 (11.00%) high severe async-pool/hook-sync/host-to-wasm - typed - nop time: [2.4135 us 2.4190 us 2.4254 us] change: [+8.3640% +9.3774% +10.435%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 6 (6.00%) high mild 5 (5.00%) high severe async-pool/hook-sync/host-to-wasm - untyped - nop time: [2.5172 us 2.5248 us 2.5357 us] change: [+11.543% +12.750% +13.982%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 1 (1.00%) high mild 7 (7.00%) high severe async-pool/hook-sync/host-to-wasm - typed - nop-params-and-results time: [2.4214 us 2.4353 us 2.4532 us] change: [+1.5158% +5.0872% +8.6765%] (p = 0.00 < 0.05) Performance has regressed. Found 15 outliers among 100 measurements (15.00%) 2 (2.00%) high mild 13 (13.00%) high severe async-pool/hook-sync/host-to-wasm - untyped - nop-params-and-results time: [2.5499 us 2.5607 us 2.5748 us] change: [+10.146% +12.459% +14.919%] (p = 0.00 < 0.05) Performance has regressed. Found 18 outliers among 100 measurements (18.00%) 3 (3.00%) high mild 15 (15.00%) high severe sync/no-hook/wasm-to-host - nop - typed time: [6.6135 ns 6.6288 ns 6.6452 ns] change: [+37.927% +38.837% +39.869%] (p = 0.00 < 0.05) Performance has regressed. Found 7 outliers among 100 measurements (7.00%) 2 (2.00%) high mild 5 (5.00%) high severe sync/no-hook/wasm-to-host - nop-params-and-results - typed time: [15.930 ns 15.993 ns 16.067 ns] change: [+3.9583% +5.6286% +7.2430%] (p = 0.00 < 0.05) Performance has regressed. Found 12 outliers among 100 measurements (12.00%) 11 (11.00%) high mild 1 (1.00%) high severe sync/no-hook/wasm-to-host - nop - untyped time: [20.596 ns 20.640 ns 20.690 ns] change: [+4.3293% +5.2047% +6.0935%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 5 (5.00%) high mild 5 (5.00%) high severe sync/no-hook/wasm-to-host - nop-params-and-results - untyped time: [42.659 ns 42.882 ns 43.159 ns] change: [-2.1466% -0.5079% +1.2554%] (p = 0.58 > 0.05) No change in performance detected. Found 15 outliers among 100 measurements (15.00%) 1 (1.00%) high mild 14 (14.00%) high severe sync/no-hook/wasm-to-host - nop - unchecked time: [10.671 ns 10.691 ns 10.713 ns] change: [+83.911% +87.620% +92.062%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 2 (2.00%) high mild 7 (7.00%) high severe sync/no-hook/wasm-to-host - nop-params-and-results - unchecked time: [11.136 ns 11.190 ns 11.263 ns] change: [-29.719% -28.446% -27.029%] (p = 0.00 < 0.05) Performance has improved. Found 14 outliers among 100 measurements (14.00%) 4 (4.00%) high mild 10 (10.00%) high severe sync/hook-sync/wasm-to-host - nop - typed time: [6.7964 ns 6.8087 ns 6.8226 ns] change: [+21.531% +24.206% +27.331%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 4 (4.00%) high mild 10 (10.00%) high severe sync/hook-sync/wasm-to-host - nop-params-and-results - typed time: [15.865 ns 15.921 ns 15.985 ns] change: [+4.8466% +6.3330% +7.8317%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 3 (3.00%) high mild 13 (13.00%) high severe sync/hook-sync/wasm-to-host - nop - untyped time: [21.505 ns 21.587 ns 21.677 ns] change: [+8.0908% +9.1943% +10.254%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 4 (4.00%) high mild 4 (4.00%) high severe sync/hook-sync/wasm-to-host - nop-params-and-results - untyped time: [44.018 ns 44.128 ns 44.261 ns] change: [-1.4671% -0.0458% +1.2443%] (p = 0.94 > 0.05) No change in performance detected. Found 14 outliers among 100 measurements (14.00%) 5 (5.00%) high mild 9 (9.00%) high severe sync/hook-sync/wasm-to-host - nop - unchecked time: [11.264 ns 11.326 ns 11.387 ns] change: [+80.225% +81.659% +83.068%] (p = 0.00 < 0.05) Performance has regressed. Found 6 outliers among 100 measurements (6.00%) 3 (3.00%) high mild 3 (3.00%) high severe sync/hook-sync/wasm-to-host - nop-params-and-results - unchecked time: [11.816 ns 11.865 ns 11.920 ns] change: [-29.152% -28.040% -26.957%] (p = 0.00 < 0.05) Performance has improved. Found 14 outliers among 100 measurements (14.00%) 8 (8.00%) high mild 6 (6.00%) high severe async/no-hook/wasm-to-host - nop - typed time: [6.6221 ns 6.6385 ns 6.6569 ns] change: [+43.618% +44.755% +45.965%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 6 (6.00%) high mild 7 (7.00%) high severe async/no-hook/wasm-to-host - nop-params-and-results - typed time: [15.884 ns 15.929 ns 15.983 ns] change: [+3.5987% +5.2053% +6.7846%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 3 (3.00%) high mild 13 (13.00%) high severe async/no-hook/wasm-to-host - nop - untyped time: [20.615 ns 20.702 ns 20.821 ns] change: [+6.9799% +8.1212% +9.2819%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 2 (2.00%) high mild 8 (8.00%) high severe async/no-hook/wasm-to-host - nop-params-and-results - untyped time: [41.956 ns 42.207 ns 42.521 ns] change: [-4.3057% -2.7730% -1.2428%] (p = 0.00 < 0.05) Performance has improved. Found 14 outliers among 100 measurements (14.00%) 3 (3.00%) high mild 11 (11.00%) high severe async/no-hook/wasm-to-host - nop - unchecked time: [10.440 ns 10.474 ns 10.513 ns] change: [+83.959% +85.826% +87.541%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 5 (5.00%) high mild 6 (6.00%) high severe async/no-hook/wasm-to-host - nop-params-and-results - unchecked time: [11.476 ns 11.512 ns 11.554 ns] change: [-29.857% -28.383% -26.978%] (p = 0.00 < 0.05) Performance has improved. Found 12 outliers among 100 measurements (12.00%) 1 (1.00%) low mild 6 (6.00%) high mild 5 (5.00%) high severe async/no-hook/wasm-to-host - nop - async-typed time: [26.427 ns 26.478 ns 26.532 ns] change: [+6.5730% +7.4676% +8.3983%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 2 (2.00%) high mild 7 (7.00%) high severe async/no-hook/wasm-to-host - nop-params-and-results - async-typed time: [28.557 ns 28.693 ns 28.880 ns] change: [+1.9099% +3.7332% +5.9731%] (p = 0.00 < 0.05) Performance has regressed. Found 15 outliers among 100 measurements (15.00%) 1 (1.00%) high mild 14 (14.00%) high severe async/hook-sync/wasm-to-host - nop - typed time: [6.7488 ns 6.7630 ns 6.7784 ns] change: [+19.935% +22.080% +23.683%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 4 (4.00%) high mild 5 (5.00%) high severe async/hook-sync/wasm-to-host - nop-params-and-results - typed time: [15.928 ns 16.031 ns 16.149 ns] change: [+5.5188% +6.9567% +8.3839%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 9 (9.00%) high mild 2 (2.00%) high severe async/hook-sync/wasm-to-host - nop - untyped time: [21.930 ns 22.114 ns 22.296 ns] change: [+4.6674% +7.7588% +10.375%] (p = 0.00 < 0.05) Performance has regressed. Found 4 outliers among 100 measurements (4.00%) 3 (3.00%) high mild 1 (1.00%) high severe async/hook-sync/wasm-to-host - nop-params-and-results - untyped time: [42.684 ns 42.858 ns 43.081 ns] change: [-5.2957% -3.4693% -1.6217%] (p = 0.00 < 0.05) Performance has improved. Found 14 outliers among 100 measurements (14.00%) 2 (2.00%) high mild 12 (12.00%) high severe async/hook-sync/wasm-to-host - nop - unchecked time: [11.026 ns 11.053 ns 11.086 ns] change: [+70.751% +72.378% +73.961%] (p = 0.00 < 0.05) Performance has regressed. Found 10 outliers among 100 measurements (10.00%) 5 (5.00%) high mild 5 (5.00%) high severe async/hook-sync/wasm-to-host - nop-params-and-results - unchecked time: [11.840 ns 11.900 ns 11.982 ns] change: [-27.977% -26.584% -24.887%] (p = 0.00 < 0.05) Performance has improved. Found 18 outliers among 100 measurements (18.00%) 3 (3.00%) high mild 15 (15.00%) high severe async/hook-sync/wasm-to-host - nop - async-typed time: [27.601 ns 27.709 ns 27.882 ns] change: [+8.1781% +9.1102% +10.030%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 2 (2.00%) low mild 3 (3.00%) high mild 6 (6.00%) high severe async/hook-sync/wasm-to-host - nop-params-and-results - async-typed time: [28.955 ns 29.174 ns 29.413 ns] change: [+1.1226% +3.0366% +5.1126%] (p = 0.00 < 0.05) Performance has regressed. Found 13 outliers among 100 measurements (13.00%) 7 (7.00%) high mild 6 (6.00%) high severe async-pool/no-hook/wasm-to-host - nop - typed time: [6.5626 ns 6.5733 ns 6.5851 ns] change: [+40.561% +42.307% +44.514%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 5 (5.00%) high mild 4 (4.00%) high severe async-pool/no-hook/wasm-to-host - nop-params-and-results - typed time: [15.820 ns 15.886 ns 15.969 ns] change: [+4.1044% +5.7928% +7.7122%] (p = 0.00 < 0.05) Performance has regressed. Found 17 outliers among 100 measurements (17.00%) 4 (4.00%) high mild 13 (13.00%) high severe async-pool/no-hook/wasm-to-host - nop - untyped time: [20.481 ns 20.521 ns 20.566 ns] change: [+6.7962% +7.6950% +8.7612%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 6 (6.00%) high mild 5 (5.00%) high severe async-pool/no-hook/wasm-to-host - nop-params-and-results - untyped time: [41.834 ns 41.998 ns 42.189 ns] change: [-3.8185% -2.2687% -0.7541%] (p = 0.01 < 0.05) Change within noise threshold. Found 13 outliers among 100 measurements (13.00%) 3 (3.00%) high mild 10 (10.00%) high severe async-pool/no-hook/wasm-to-host - nop - unchecked time: [10.353 ns 10.380 ns 10.414 ns] change: [+82.042% +84.591% +87.205%] (p = 0.00 < 0.05) Performance has regressed. Found 7 outliers among 100 measurements (7.00%) 4 (4.00%) high mild 3 (3.00%) high severe async-pool/no-hook/wasm-to-host - nop-params-and-results - unchecked time: [11.123 ns 11.168 ns 11.228 ns] change: [-30.813% -29.285% -27.874%] (p = 0.00 < 0.05) Performance has improved. Found 12 outliers among 100 measurements (12.00%) 11 (11.00%) high mild 1 (1.00%) high severe async-pool/no-hook/wasm-to-host - nop - async-typed time: [27.442 ns 27.528 ns 27.638 ns] change: [+7.5215% +9.9795% +12.266%] (p = 0.00 < 0.05) Performance has regressed. Found 18 outliers among 100 measurements (18.00%) 3 (3.00%) high mild 15 (15.00%) high severe async-pool/no-hook/wasm-to-host - nop-params-and-results - async-typed time: [29.014 ns 29.148 ns 29.312 ns] change: [+2.0227% +3.4722% +4.9047%] (p = 0.00 < 0.05) Performance has regressed. Found 7 outliers among 100 measurements (7.00%) 6 (6.00%) high mild 1 (1.00%) high severe async-pool/hook-sync/wasm-to-host - nop - typed time: [6.7916 ns 6.8116 ns 6.8325 ns] change: [+20.937% +22.050% +23.281%] (p = 0.00 < 0.05) Performance has regressed. Found 11 outliers among 100 measurements (11.00%) 5 (5.00%) high mild 6 (6.00%) high severe async-pool/hook-sync/wasm-to-host - nop-params-and-results - typed time: [15.917 ns 15.975 ns 16.051 ns] change: [+4.6404% +6.4217% +8.3075%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 5 (5.00%) high mild 11 (11.00%) high severe async-pool/hook-sync/wasm-to-host - nop - untyped time: [21.558 ns 21.612 ns 21.679 ns] change: [+8.1158% +9.1409% +10.217%] (p = 0.00 < 0.05) Performance has regressed. Found 9 outliers among 100 measurements (9.00%) 2 (2.00%) high mild 7 (7.00%) high severe async-pool/hook-sync/wasm-to-host - nop-params-and-results - untyped time: [42.475 ns 42.614 ns 42.775 ns] change: [-6.3613% -4.4709% -2.7647%] (p = 0.00 < 0.05) Performance has improved. Found 18 outliers among 100 measurements (18.00%) 3 (3.00%) high mild 15 (15.00%) high severe async-pool/hook-sync/wasm-to-host - nop - unchecked time: [11.150 ns 11.195 ns 11.247 ns] change: [+74.424% +77.056% +79.811%] (p = 0.00 < 0.05) Performance has regressed. Found 14 outliers among 100 measurements (14.00%) 3 (3.00%) high mild 11 (11.00%) high severe async-pool/hook-sync/wasm-to-host - nop-params-and-results - unchecked time: [11.639 ns 11.695 ns 11.760 ns] change: [-30.212% -29.023% -27.954%] (p = 0.00 < 0.05) Performance has improved. Found 15 outliers among 100 measurements (15.00%) 7 (7.00%) high mild 8 (8.00%) high severe async-pool/hook-sync/wasm-to-host - nop - async-typed time: [27.480 ns 27.712 ns 27.984 ns] change: [+2.9764% +6.5061% +9.8914%] (p = 0.00 < 0.05) Performance has regressed. Found 8 outliers among 100 measurements (8.00%) 6 (6.00%) high mild 2 (2.00%) high severe async-pool/hook-sync/wasm-to-host - nop-params-and-results - async-typed time: [29.218 ns 29.380 ns 29.600 ns] change: [+5.2283% +7.7247% +10.822%] (p = 0.00 < 0.05) Performance has regressed. Found 16 outliers among 100 measurements (16.00%) 2 (2.00%) high mild 14 (14.00%) high severe ``` </details> * Add s390x support for frame pointer-based stack walking * wasmtime: Allow `Caller::get_export` to get all exports * fuzzing: Add a fuzz target to check that our stack traces are correct We generate Wasm modules that keep track of their own stack as they call and return between functions, and then we periodically check that if the host captures a backtrace, it matches what the Wasm module has recorded. * Remove VM offsets for `VMHostFuncContext` since it isn't used by JIT code * Add doc comment with stack walking implementation notes * Document the extra state that can be passed to `wasmtime_runtime::Backtrace` methods * Add extensive comments for stack walking function * Factor architecture-specific bits of stack walking out into modules * Initialize store-related fields in a vmctx to null when there is no store yet Rather than leaving them as uninitialized data. * Use `set_callee` instead of manually setting the vmctx field * Use a more informative compile error message for unsupported architectures * Document unsafety of `prepare_host_to_wasm_trampoline` * Use `bti c` instead of `hint #34` in inline aarch64 assembly * Remove outdated TODO comment * Remove setting of `last_wasm_exit_fp` in `set_jit_trap` This is no longer needed as the value is plumbed through to the backtrace code directly now. * Only set the stack limit once, in the face of re-entrancy into Wasm * Add comments for s390x-specific stack walking bits * Use the helper macro for all libcalls If we forget to use it, and then trigger a GC from the libcall, that means we could miss stack frames when walking the stack, fail to find live GC refs, and then get use after free bugs. Much less risky to always use the helper macro that takes care of all of that for us. * Use the `asm_sym!` macro in Wasm-to-libcall trampolines This macro handles the macOS-specific underscore prefix stuff for us. * wasmtime: add size and align to `externref` assertion error message * Extend the `stacks` fuzzer to have host frames in between Wasm frames This way we get one or more contiguous sequences of Wasm frames on the stack, instead of exactly one. * Add documentation for aarch64-specific backtrace helpers * Clarify that we only support little-endian aarch64 in trampoline comment * Use `.machine z13` in s390x assembly file Since apparently our CI machines have pretty old assemblers that don't have `.machine z14`. This should be fine though since these trampolines don't make use of anything that is introduced in z14. * Fix aarch64 build * Fix macOS build * Document the `asm_sym!` macro * Add windows support to the `wasmtime-asm-macros` crate * Add windows support to host<--->Wasm trampolines * Fix trap handler build on windows * Run `rustfmt` on s390x trampoline source file * Temporarily disable some assertions about a trap's backtrace in the component model tests Follow up to re-enable this and fix the associated issue: https://github.com/bytecodealliance/wasmtime/issues/4535 * Refactor libcall definitions with less macros This refactors the `libcall!` macro to use the `foreach_builtin_function!` macro to define all of the trampolines. Additionally the macro surrounding each libcall itself is no longer necessary and helps avoid too many macros. * Use `VMOpaqueContext::from_vm_host_func_context` in `VMHostFuncContext::new` * Move `backtrace` module to be submodule of `traphandlers` This avoids making some things `pub(crate)` in `traphandlers` that really shouldn't be. * Fix macOS aarch64 build * Use "i64" instead of "word" in aarch64-specific file * Save/restore entry SP and exit FP/return pointer in the face of panicking imported host functions Also clean up assertions surrounding our saved entry/exit registers. * Put "typed" vs "untyped" in the same position of call benchmark names Regardless if we are doing wasm-to-host or host-to-wasm * Fix stacks test case generator build for new `wasm-encoder` * Fix build for s390x * Expand libcalls in s390x asm * Disable more parts of component tests now that backtrace assertions are a bit tighter * Remove assertion that can maybe fail on s390x Co-authored-by: Ulrich Weigand <ulrich.weigand@de.ibm.com> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
2 years ago
"wasmtime-asm-macros",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime-environ",
Split out fiber stacks from fibers. This commit splits out a `FiberStack` from `Fiber`, allowing the instance allocator trait to return `FiberStack` rather than raw stack pointers. This keeps the stack creation mostly in `wasmtime_fiber`, but now the on-demand instance allocator can make use of it. The instance allocators no longer have to return a "not supported" error to indicate that the store should allocate its own fiber stack. This includes a bunch of cleanup in the instance allocator to scope stacks to the new "async" feature in the runtime. Closes #2708.
4 years ago
"wasmtime-fiber",
Extract jit_int.rs and most of jitdump_linux.rs for use outside of wasmtime (#2744) * Extract gdb jit_int into wasmtime-jit-debug * Move a big chunk of the jitdump code to wasmtime-jit-debug * Fix doc markdown in perf_jitdump.rs
3 years ago
"wasmtime-jit-debug",
Migrate from `winapi` to `windows-sys` (#4346) * Migrate from `winapi` to `windows-sys` I believe that Microsoft itself is supporting the development of `windows-sys` and it's also used by `cap-std` now so this switches Wasmtime's dependencies on Windows APIs from the `winapi` crate to the `windows-sys` crate. We still have `winapi` in our dependency graph but that may get phased out over time. * Make windows-sys a target-specific dependency
2 years ago
"windows-sys",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Remove `wasmtime-environ`'s dependency on `cranelift-codegen` (#3199) * Move `CompiledFunction` into wasmtime-cranelift This commit moves the `wasmtime_environ::CompiledFunction` type into the `wasmtime-cranelift` crate. This type has lots of Cranelift-specific pieces of compilation and doesn't need to be generated by all Wasmtime compilers. This replaces the usage in the `Compiler` trait with a `Box<Any>` type that each compiler can select. Each compiler must still produce a `FunctionInfo`, however, which is shared information we'll deserialize for each module. The `wasmtime-debug` crate is also folded into the `wasmtime-cranelift` crate as a result of this commit. One possibility was to move the `CompiledFunction` commit into its own crate and have `wasmtime-debug` depend on that, but since `wasmtime-debug` is Cranelift-specific at this time it didn't seem like it was too too necessary to keep it separate. If `wasmtime-debug` supports other backends in the future we can recreate a new crate, perhaps with it refactored to not depend on Cranelift. * Move wasmtime_environ::reference_type This now belongs in wasmtime-cranelift and nowhere else * Remove `Type` reexport in wasmtime-environ One less dependency on `cranelift-codegen`! * Remove `types` reexport from `wasmtime-environ` Less cranelift! * Remove `SourceLoc` from wasmtime-environ Change the `srcloc`, `start_srcloc`, and `end_srcloc` fields to a custom `FilePos` type instead of `ir::SourceLoc`. These are only used in a few places so there's not much to lose from an extra abstraction for these leaf use cases outside of cranelift. * Remove wasmtime-environ's dep on cranelift's `StackMap` This commit "clones" the `StackMap` data structure in to `wasmtime-environ` to have an independent representation that that chosen by Cranelift. This allows Wasmtime to decouple this runtime dependency of stack map information and let the two evolve independently, if necessary. An alternative would be to refactor cranelift's implementation into a separate crate and have wasmtime depend on that but it seemed a bit like overkill to do so and easier to clone just a few lines for this. * Define code offsets in wasmtime-environ with `u32` Don't use Cranelift's `binemit::CodeOffset` alias to define this field type since the `wasmtime-environ` crate will be losing the `cranelift-codegen` dependency soon. * Commit to using `cranelift-entity` in Wasmtime This commit removes the reexport of `cranelift-entity` from the `wasmtime-environ` crate and instead directly depends on the `cranelift-entity` crate in all referencing crates. The original reason for the reexport was to make cranelift version bumps easier since it's less versions to change, but nowadays we have a script to do that. Otherwise this encourages crates to use whatever they want from `cranelift-entity` since we'll always depend on the whole crate. It's expected that the `cranelift-entity` crate will continue to be a lean crate in dependencies and suitable for use at both runtime and compile time. Consequently there's no need to avoid its usage in Wasmtime at runtime, since "remove Cranelift at compile time" is primarily about the `cranelift-codegen` crate. * Remove most uses of `cranelift-codegen` in `wasmtime-environ` There's only one final use remaining, which is the reexport of `TrapCode`, which will get handled later. * Limit the glob-reexport of `cranelift_wasm` This commit removes the glob reexport of `cranelift-wasm` from the `wasmtime-environ` crate. This is intended to explicitly define what we're reexporting and is a transitionary step to curtail the amount of dependencies taken on `cranelift-wasm` throughout the codebase. For example some functions used by debuginfo mapping are better imported directly from the crate since they're Cranelift-specific. Note that this is intended to be a temporary state affairs, soon this reexport will be gone entirely. Additionally this commit reduces imports from `cranelift_wasm` and also primarily imports from `crate::wasm` within `wasmtime-environ` to get a better sense of what's imported from where and what will need to be shared. * Extract types from cranelift-wasm to cranelift-wasm-types This commit creates a new crate called `cranelift-wasm-types` and extracts type definitions from the `cranelift-wasm` crate into this new crate. The purpose of this crate is to be a shared definition of wasm types that can be shared both by compilers (like Cranelift) as well as wasm runtimes (e.g. Wasmtime). This new `cranelift-wasm-types` crate doesn't depend on `cranelift-codegen` and is the final step in severing the unconditional dependency from Wasmtime to `cranelift-codegen`. The final refactoring in this commit is to then reexport this crate from `wasmtime-environ`, delete the `cranelift-codegen` dependency, and then update all `use` paths to point to these new types. The main change of substance here is that the `TrapCode` enum is mirrored from Cranelift into this `cranelift-wasm-types` crate. While this unfortunately results in three definitions (one more which is non-exhaustive in Wasmtime itself) it's hopefully not too onerous and ideally something we can patch up in the future. * Get lightbeam compiling * Remove unnecessary dependency * Fix compile with uffd * Update publish script * Fix more uffd tests * Rename cranelift-wasm-types to wasmtime-types This reflects the purpose a bit more where it's types specifically intended for Wasmtime and its support. * Fix publish script
3 years ago
[[package]]
name = "wasmtime-types"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Remove `wasmtime-environ`'s dependency on `cranelift-codegen` (#3199) * Move `CompiledFunction` into wasmtime-cranelift This commit moves the `wasmtime_environ::CompiledFunction` type into the `wasmtime-cranelift` crate. This type has lots of Cranelift-specific pieces of compilation and doesn't need to be generated by all Wasmtime compilers. This replaces the usage in the `Compiler` trait with a `Box<Any>` type that each compiler can select. Each compiler must still produce a `FunctionInfo`, however, which is shared information we'll deserialize for each module. The `wasmtime-debug` crate is also folded into the `wasmtime-cranelift` crate as a result of this commit. One possibility was to move the `CompiledFunction` commit into its own crate and have `wasmtime-debug` depend on that, but since `wasmtime-debug` is Cranelift-specific at this time it didn't seem like it was too too necessary to keep it separate. If `wasmtime-debug` supports other backends in the future we can recreate a new crate, perhaps with it refactored to not depend on Cranelift. * Move wasmtime_environ::reference_type This now belongs in wasmtime-cranelift and nowhere else * Remove `Type` reexport in wasmtime-environ One less dependency on `cranelift-codegen`! * Remove `types` reexport from `wasmtime-environ` Less cranelift! * Remove `SourceLoc` from wasmtime-environ Change the `srcloc`, `start_srcloc`, and `end_srcloc` fields to a custom `FilePos` type instead of `ir::SourceLoc`. These are only used in a few places so there's not much to lose from an extra abstraction for these leaf use cases outside of cranelift. * Remove wasmtime-environ's dep on cranelift's `StackMap` This commit "clones" the `StackMap` data structure in to `wasmtime-environ` to have an independent representation that that chosen by Cranelift. This allows Wasmtime to decouple this runtime dependency of stack map information and let the two evolve independently, if necessary. An alternative would be to refactor cranelift's implementation into a separate crate and have wasmtime depend on that but it seemed a bit like overkill to do so and easier to clone just a few lines for this. * Define code offsets in wasmtime-environ with `u32` Don't use Cranelift's `binemit::CodeOffset` alias to define this field type since the `wasmtime-environ` crate will be losing the `cranelift-codegen` dependency soon. * Commit to using `cranelift-entity` in Wasmtime This commit removes the reexport of `cranelift-entity` from the `wasmtime-environ` crate and instead directly depends on the `cranelift-entity` crate in all referencing crates. The original reason for the reexport was to make cranelift version bumps easier since it's less versions to change, but nowadays we have a script to do that. Otherwise this encourages crates to use whatever they want from `cranelift-entity` since we'll always depend on the whole crate. It's expected that the `cranelift-entity` crate will continue to be a lean crate in dependencies and suitable for use at both runtime and compile time. Consequently there's no need to avoid its usage in Wasmtime at runtime, since "remove Cranelift at compile time" is primarily about the `cranelift-codegen` crate. * Remove most uses of `cranelift-codegen` in `wasmtime-environ` There's only one final use remaining, which is the reexport of `TrapCode`, which will get handled later. * Limit the glob-reexport of `cranelift_wasm` This commit removes the glob reexport of `cranelift-wasm` from the `wasmtime-environ` crate. This is intended to explicitly define what we're reexporting and is a transitionary step to curtail the amount of dependencies taken on `cranelift-wasm` throughout the codebase. For example some functions used by debuginfo mapping are better imported directly from the crate since they're Cranelift-specific. Note that this is intended to be a temporary state affairs, soon this reexport will be gone entirely. Additionally this commit reduces imports from `cranelift_wasm` and also primarily imports from `crate::wasm` within `wasmtime-environ` to get a better sense of what's imported from where and what will need to be shared. * Extract types from cranelift-wasm to cranelift-wasm-types This commit creates a new crate called `cranelift-wasm-types` and extracts type definitions from the `cranelift-wasm` crate into this new crate. The purpose of this crate is to be a shared definition of wasm types that can be shared both by compilers (like Cranelift) as well as wasm runtimes (e.g. Wasmtime). This new `cranelift-wasm-types` crate doesn't depend on `cranelift-codegen` and is the final step in severing the unconditional dependency from Wasmtime to `cranelift-codegen`. The final refactoring in this commit is to then reexport this crate from `wasmtime-environ`, delete the `cranelift-codegen` dependency, and then update all `use` paths to point to these new types. The main change of substance here is that the `TrapCode` enum is mirrored from Cranelift into this `cranelift-wasm-types` crate. While this unfortunately results in three definitions (one more which is non-exhaustive in Wasmtime itself) it's hopefully not too onerous and ideally something we can patch up in the future. * Get lightbeam compiling * Remove unnecessary dependency * Fix compile with uffd * Update publish script * Fix more uffd tests * Rename cranelift-wasm-types to wasmtime-types This reflects the purpose a bit more where it's types specifically intended for Wasmtime and its support. * Fix publish script
3 years ago
dependencies = [
"cranelift-entity",
"serde",
"thiserror",
"wasmparser",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "wasmtime-wasi"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Reimplement `wasmtime-wasi` on top of `wasmtime` (#899) * Reimplement `wasmtime-wasi` on top of `wasmtime` This commit reimplements the `wasmtime-wasi` crate on top of the `wasmtime` API crate, instead of being placed on top of the `wasmtime-*` family of internal crates. The purpose here is to continue to exercise the API as well as avoid usage of internals wherever possible and instead use the safe API as much as possible. The `wasmtime-wasi` crate's API has been updated as part of this PR as well. The general outline of it is now: * Each module snapshot has a `WasiCtxBuilder`, `WasiCtx`, and `Wasi` type. * The `WasiCtx*` types are reexported from `wasi-common`. * The `Wasi` type is synthesized by the `wig` crate's procedural macro * The `Wasi` type exposes one constructor which takes a `Store` and a `WasiCtx`, and produces a `Wasi` * Each `Wasi` struct fields for all the exported functions in that wasi module. They're all public an they all have type `wasmtime::Func` * The `Wasi` type has a `get_export` method to fetch an struct field by name. The intention here is that we can continue to make progress on #727 by integrating WASI construction into the `Instance::new` experience, but it requires everything to be part of the same system! The main oddity required by the `wasmtime-wasi` crate is that it needs access to the caller's `memory` export, if any. This is currently done with a bit of a hack and is expected to go away once interface types are more fully baked in. * Remove now no-longer-necessary APIs from `wasmtime` * rustfmt * Rename to from_abi
5 years ago
"anyhow",
wasmtime-wasi: re-export wasi-cap-std-sync
4 years ago
"wasi-cap-std-sync",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasi-common",
wasi-cap-std-async is better named wasi-tokio
4 years ago
"wasi-tokio",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"wasmtime",
Shuffle around the wiggle crates (#1414) * Shuffle around the wiggle crates This commit reorganizes the wiggle crates slightly by performing the following transforms: * The `crates/wiggle` crate, previously named `wiggle`, was moved to `crates/wiggle/crates/macro` and is renamed to `wiggle-macro`. * The `crates/wiggle/crates/runtime` crate, previously named `wiggle-runtime`, was moved to `crates/wiggle` and is renamed to `wiggle`. * The new `wiggle` crate depends on `wiggle-macro` and reexports the macro. The goal here is that consumers only deal with the `wiggle` crate itself. No more crates depend on `wiggle-runtime` and all dependencies are entirely on just the `wiggle` crate. * Remove the `crates/wiggle/crates` directory Move everything into `crates/wiggle` directly, like `wasi-common` * Add wiggle-macro to test-all script * Fixup a test
5 years ago
"wiggle",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "wasmtime-wasi-crypto"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"anyhow",
"wasi-crypto",
"wasmtime",
"wiggle",
]
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
[[package]]
name = "wasmtime-wasi-nn"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
dependencies = [
"anyhow",
"openvino",
"thiserror",
wasi-nn: rebuild if the witx files change
4 years ago
"walkdir",
Add an initial wasi-nn implementation for Wasmtime (#2208) * Add an initial wasi-nn implementation for Wasmtime This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn: - `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls - the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate * Test wasi-nn as a CI step This change adds: - a GitHub action for installing OpenVINO - a script, `ci/run-wasi-nn-example.sh`, to run the classification example
4 years ago
"wiggle",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "wasmtime-wast"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"anyhow",
Add a dataflow-based representation of components (#4597) * Add a dataflow-based representation of components This commit updates the inlining phase of compiling a component to creating a dataflow-based representation of a component instead of creating a final `Component` with a linear list of initializers. This dataflow graph is then linearized in a final step to create the actual final `Component`. The motivation for this commit stems primarily from my work implementing strings in fused adapters. In doing this my plan is to defer most low-level transcoding to the host itself rather than implementing that in the core wasm adapter modules. This means that small cranelift-generated trampolines will be used for adapter modules to call which then call "transcoding libcalls". The cranelift-generated trampolines will get raw pointers into linear memory and pass those to the libcall which core wasm doesn't have access to when passing arguments to an import. Implementing this with the previous representation of a `Component` was becoming too tricky to bear. The initialization of a transcoder needed to happen at just the right time: before the adapter module which needed it was instantiated but after the linear memories referenced had been extracted into the `VMComponentContext`. The difficulty here is further compounded by the current adapter module injection pass already being quite complicated. Adapter modules are already renumbering the index space of runtime instances and shuffling items around in the `GlobalInitializer` list. Perhaps the worst part of this was that memories could already be referenced by host function imports or exports to the host, and if adapters referenced the same memory it shouldn't be referenced twice in the component. This meant that `ExtractMemory` initializers ideally needed to be shuffled around in the initializer list to happen as early as possible instead of wherever they happened to show up during translation. Overall I did my best to implement the transcoders but everything always came up short. I have decided to throw my hands up in the air and try a completely different approach to this, namely the dataflow-based representation in this commit. This makes it much easier to edit the component after initial translation for injection of adapters, injection of transcoders, adding dependencies on possibly-already-existing items, etc. The adapter module partitioning pass in this commit was greatly simplified to something which I believe is functionally equivalent but is probably an order of magnitude easier to understand. The biggest downside of this representation I believe is having a duplicate representation of a component. The `component::info` was largely duplicated into the `component::dfg` module in this commit. Personally though I think this is a more appropriate tradeoff than before because it's very easy to reason about "convert representation A to B" code whereas it was very difficult to reason about shuffling around `GlobalInitializer` items in optimal fashions. This may also have a cost at compile-time in terms of shuffling data around, but my hope is that we have lots of other low-hanging fruit to optimize if it ever comes to that which allows keeping this easier-to-understand representation. Finally, to reiterate, the final representation of components is not changed by this PR. To the runtime internals everything is still the same. * Fix compile of factc
2 years ago
"log",
Update the `*.wast` runner to use the `wasmtime` API (#690) * Update the `*.wast` runner to use the `wasmtime` API This commit migrates the `wasmtime-wast` crate, which executes `*.wast` test suites, to use the `wasmtime` crate exclusively instead of the raw support provided by the `wasmtime-*` family of crates. The primary motivation for this change is to use `*.wast` test to test the support for interface types, but interface types is only being added in the `wasmtime` crate for now rather than all throughout the core crates. This means that without this transition it's much more difficult to write tests for wasm interface types! A secondary motivation for this is that it's testing the support we provide to users through the `wasmtime` crate, since that's the expectation of what most users would use rather than the raw `wasmtime-*` crates. * Run rustfmt * Fix the multi example * Handle v128 values in the `wasmtime` crate Ensure that we allocate 128-bit stack slots instead of 64-bit stack slots. * Update to master * Add comment
5 years ago
"wasmtime",
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
"wast 47.0.1",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Wasmtime 0.18.0 and Cranelift 0.65.0.
4 years ago
[[package]]
name = "wast"
update WASI submodule (#3025) * wasi-common: update wasi submodule This updates the WASI submodule, pulling in changes to the witx crate, now that there is a 0.9.1 version including some bug fixes. See WebAssembly/WASI#434 for more information. * wiggle: update witx dependencies * publish: verify and vendor witx-cli * adjust root workspace members This commit removes some items from the root manifest's workspace members array, and adds `witx-cli` to the root `workspace.exclude` array. The motivation for this stems from a cargo bug described in rust-lang/cargo#6745: `workspace.exclude` does not work if it is nested under a `workspace.members` path. See WebAssembly/WASI#438 for the underlying change to the WASI submodule which reorganized the `witx-cli` crate, and WebAssembly/WASI#398 for the original PR introducing `witx-cli`. See [this comment](https://github.com/bytecodealliance/wasmtime/pull/3025#issuecomment-867741175) for more details about the compilation errors, and failed alternative approaches that necessitated this change. N.B. This is not a functional change, these crates are still implicitly workspace members as transitive dependencies, but this will allow us to side-step the aforementioned cargo bug. Co-Authored-By: Alex Crichton <alex@alexcrichton.com> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
3 years ago
version = "35.0.2"
Wasmtime 0.18.0 and Cranelift 0.65.0.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
update WASI submodule (#3025) * wasi-common: update wasi submodule This updates the WASI submodule, pulling in changes to the witx crate, now that there is a 0.9.1 version including some bug fixes. See WebAssembly/WASI#434 for more information. * wiggle: update witx dependencies * publish: verify and vendor witx-cli * adjust root workspace members This commit removes some items from the root manifest's workspace members array, and adds `witx-cli` to the root `workspace.exclude` array. The motivation for this stems from a cargo bug described in rust-lang/cargo#6745: `workspace.exclude` does not work if it is nested under a `workspace.members` path. See WebAssembly/WASI#438 for the underlying change to the WASI submodule which reorganized the `witx-cli` crate, and WebAssembly/WASI#398 for the original PR introducing `witx-cli`. See [this comment](https://github.com/bytecodealliance/wasmtime/pull/3025#issuecomment-867741175) for more details about the compilation errors, and failed alternative approaches that necessitated this change. N.B. This is not a functional change, these crates are still implicitly workspace members as transitive dependencies, but this will allow us to side-step the aforementioned cargo bug. Co-Authored-By: Alex Crichton <alex@alexcrichton.com> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
3 years ago
checksum = "2ef140f1b49946586078353a453a1d28ba90adfc54dde75710bc1931de204d68"
Wasmtime 0.18.0 and Cranelift 0.65.0.
4 years ago
dependencies = [
"leb128",
]
Update wasm-tools crates (#3997) * Update wasm-tools crates This commit updates the wasm-tools family of crates as used in Wasmtime. Notably this brings in the update which removes module linking support as well as a number of internal refactorings around names and such within wasmparser itself. This updates all of the wasm translation support which binds to wasmparser as appropriate. Other crates all had API-compatible changes for at least what Wasmtime used so no further changes were necessary beyond updating version requirements. * Update a test expectation
3 years ago
[[package]]
name = "wast"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
version = "47.0.1"
Update wasm-tools crates (#3997) * Update wasm-tools crates This commit updates the wasm-tools family of crates as used in Wasmtime. Notably this brings in the update which removes module linking support as well as a number of internal refactorings around names and such within wasmparser itself. This updates all of the wasm translation support which binds to wasmparser as appropriate. Other crates all had API-compatible changes for at least what Wasmtime used so no further changes were necessary beyond updating version requirements. * Update a test expectation
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
checksum = "02b98502f3978adea49551e801a6687678e6015317d7d9470a67fe813393f2a8"
Update wasm-tools crates (#3997) * Update wasm-tools crates This commit updates the wasm-tools family of crates as used in Wasmtime. Notably this brings in the update which removes module linking support as well as a number of internal refactorings around names and such within wasmparser itself. This updates all of the wasm translation support which binds to wasmparser as appropriate. Other crates all had API-compatible changes for at least what Wasmtime used so no further changes were necessary beyond updating version requirements. * Update a test expectation
3 years ago
dependencies = [
"leb128",
"memchr",
"unicode-width",
Update wasm-tools crates (#4246) This commit updates the wasm-tools family of crates, notably pulling in the refactorings and updates from bytecodealliance/wasm-tools#621 for the latest iteration of the component model. This commit additionally updates all support for the component model for these changes, notably: * Many bits and pieces of type information was refactored. Many `FooTypeIndex` namings are now `TypeFooIndex`. Additionally there is now `TypeIndex` as well as `ComponentTypeIndex` for the two type index spaces in a component. * A number of new sections are now processed to handle the core and component variants. * Internal maps were split such as the `funcs` map into `component_funcs` and `funcs` (same for `instances`). * Canonical options are now processed individually instead of one bulk `into` definition. Overall this was not a major update to the internals of handling the component model in Wasmtime. Instead this was mostly a surface-level refactoring to make sure that everything lines up with the new binary format for components. * All text syntax used in tests was updated to the new syntax.
2 years ago
"wasm-encoder",
Update wasm-tools crates (#3997) * Update wasm-tools crates This commit updates the wasm-tools family of crates as used in Wasmtime. Notably this brings in the update which removes module linking support as well as a number of internal refactorings around names and such within wasmparser itself. This updates all of the wasm translation support which binds to wasmparser as appropriate. Other crates all had API-compatible changes for at least what Wasmtime used so no further changes were necessary beyond updating version requirements. * Update a test expectation
3 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "wat"
Update wasm-tools dependencies (#4970) * Update wasm-tools dependencies This update brings in a number of features such as: * The component model binary format and AST has been slightly adjusted in a few locations. Names are dropped from parameters/results now in the internal representation since they were not used anyway. At this time the ability to bind a multi-return function has not been exposed. * The `wasmparser` validator pass will now share allocations with prior functions, providing what's probably a very minor speedup for Wasmtime itself. * The text format for many component-related tests now requires named parameters. * Some new relaxed-simd instructions are updated to be ignored. I hope to have a follow-up to expose the multi-return ability to the embedding API of components. * Update audit information for new crates
2 years ago
version = "1.0.49"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update wasm-tools dependencies (#4970) * Update wasm-tools dependencies This update brings in a number of features such as: * The component model binary format and AST has been slightly adjusted in a few locations. Names are dropped from parameters/results now in the internal representation since they were not used anyway. At this time the ability to bind a multi-return function has not been exposed. * The `wasmparser` validator pass will now share allocations with prior functions, providing what's probably a very minor speedup for Wasmtime itself. * The text format for many component-related tests now requires named parameters. * Some new relaxed-simd instructions are updated to be ignored. I hope to have a follow-up to expose the multi-return ability to the embedding API of components. * Update audit information for new crates
2 years ago
checksum = "7aab4e20c60429fbba9670a6cae0fff9520046ba0aa3e6d0b1cd2653bea14898"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Update the wasm-tools family of crates (#5010) * Update the wasm-tools family of crates Only minor updates here, mostly internal changes and no binary-related changes today. * Fix test expectation
2 years ago
"wast 47.0.1",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
[[package]]
name = "web-sys"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "0.3.57"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "7b17e741662c70c8bd24ac5c5b18de314a2c26c32bf8346ee1e6f53de919c283"
x64: add benchmarks for EVEX encoding This change adds a criterion-enabled benchmark, x64-evex-encoding, to compare the performance of the builder pattern used to encode EVEX instructions in the new x64 backend against the function pattern used to encode EVEX instructions in the legacy x86 backend. At face value, the results imply that the builder pattern is faster, but no efforts were made to analyze and optimize these approaches further.
4 years ago
dependencies = [
"js-sys",
"wasm-bindgen",
]
Add differential fuzzing against V8 (#3264) * Add differential fuzzing against V8 This commit adds a differential fuzzing target to Wasmtime along the lines of the wasmi and spec interpreters we already have, but with V8 instead. The intention here is that wasmi is unlikely to receive updates over time (e.g. for SIMD), and the spec interpreter is not suitable for fuzzing against in general due to its performance characteristics. The hope is that V8 is indeed appropriate to fuzz against because it's naturally receiving updates and it also is expected to have good performance. Here the `rusty_v8` crate is used which provides bindings to V8 as well as precompiled binaries by default. This matches exactly the use case we need and at least for now I think the `rusty_v8` crate will be maintained by the Deno folks as they continue to develop it. If it becomes an issue though maintaining we can evaluate other options to have differential fuzzing against. For now this commit enables the SIMD and bulk-memory feature of fuzz-target-generation which should enable them to get differentially-fuzzed with V8 in addition to the compilation fuzzing we're already getting. * Use weak linkage for GDB jit helpers This should help us deduplicate our symbol with other JIT runtimes, if any. For now this leans on some C helpers to define the weak linkage since Rust doesn't support that on stable yet. * Don't use rusty_v8 on MinGW They don't have precompiled libraries there. * Fix msvc build * Comment about execution
3 years ago
[[package]]
name = "which"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
version = "4.2.5"
Add differential fuzzing against V8 (#3264) * Add differential fuzzing against V8 This commit adds a differential fuzzing target to Wasmtime along the lines of the wasmi and spec interpreters we already have, but with V8 instead. The intention here is that wasmi is unlikely to receive updates over time (e.g. for SIMD), and the spec interpreter is not suitable for fuzzing against in general due to its performance characteristics. The hope is that V8 is indeed appropriate to fuzz against because it's naturally receiving updates and it also is expected to have good performance. Here the `rusty_v8` crate is used which provides bindings to V8 as well as precompiled binaries by default. This matches exactly the use case we need and at least for now I think the `rusty_v8` crate will be maintained by the Deno folks as they continue to develop it. If it becomes an issue though maintaining we can evaluate other options to have differential fuzzing against. For now this commit enables the SIMD and bulk-memory feature of fuzz-target-generation which should enable them to get differentially-fuzzed with V8 in addition to the compilation fuzzing we're already getting. * Use weak linkage for GDB jit helpers This should help us deduplicate our symbol with other JIT runtimes, if any. For now this leans on some C helpers to define the weak linkage since Rust doesn't support that on stable yet. * Don't use rusty_v8 on MinGW They don't have precompiled libraries there. * Fix msvc build * Comment about execution
3 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update some dependencies in `Cargo.lock` (#4081) * Run a `cargo update` over our dependencies This'll notably fix a `cargo audit` error where we have a pinned version of the `regex` crate which has a CVE assigned to it. * Update to `object` and `hashbrown` crates Prune some duplicate versions showing up from the previous `cargo update`
3 years ago
checksum = "5c4fb54e6113b6a8772ee41c3404fb0301ac79604489467e0a9ce1f3e97c24ae"
Add differential fuzzing against V8 (#3264) * Add differential fuzzing against V8 This commit adds a differential fuzzing target to Wasmtime along the lines of the wasmi and spec interpreters we already have, but with V8 instead. The intention here is that wasmi is unlikely to receive updates over time (e.g. for SIMD), and the spec interpreter is not suitable for fuzzing against in general due to its performance characteristics. The hope is that V8 is indeed appropriate to fuzz against because it's naturally receiving updates and it also is expected to have good performance. Here the `rusty_v8` crate is used which provides bindings to V8 as well as precompiled binaries by default. This matches exactly the use case we need and at least for now I think the `rusty_v8` crate will be maintained by the Deno folks as they continue to develop it. If it becomes an issue though maintaining we can evaluate other options to have differential fuzzing against. For now this commit enables the SIMD and bulk-memory feature of fuzz-target-generation which should enable them to get differentially-fuzzed with V8 in addition to the compilation fuzzing we're already getting. * Use weak linkage for GDB jit helpers This should help us deduplicate our symbol with other JIT runtimes, if any. For now this leans on some C helpers to define the weak linkage since Rust doesn't support that on stable yet. * Don't use rusty_v8 on MinGW They don't have precompiled libraries there. * Fix msvc build * Comment about execution
3 years ago
dependencies = [
"either",
"lazy_static",
"libc",
]
Fix wiggle's tests
5 years ago
[[package]]
name = "wiggle"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Fix wiggle's tests
5 years ago
dependencies = [
Implement RFC 11: Redesigning Wasmtime's APIs (#2897) Implement Wasmtime's new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it's best to read the RFC thread and the PR thread.
3 years ago
"anyhow",
bump cargo.lock, add wiggle-generate and wiggle-macro to workspace wiggle-macro doc tests weren't being run, so docs had gotten out of sync.
4 years ago
"async-trait",
wiggle: depend on bitflags, and re-export it.
4 years ago
"bitflags",
Fix wiggle's tests
5 years ago
"proptest",
Shuffle around the wiggle crates (#1414) * Shuffle around the wiggle crates This commit reorganizes the wiggle crates slightly by performing the following transforms: * The `crates/wiggle` crate, previously named `wiggle`, was moved to `crates/wiggle/crates/macro` and is renamed to `wiggle-macro`. * The `crates/wiggle/crates/runtime` crate, previously named `wiggle-runtime`, was moved to `crates/wiggle` and is renamed to `wiggle`. * The new `wiggle` crate depends on `wiggle-macro` and reexports the macro. The goal here is that consumers only deal with the `wiggle` crate itself. No more crates depend on `wiggle-runtime` and all dependencies are entirely on just the `wiggle` crate. * Remove the `crates/wiggle/crates` directory Move everything into `crates/wiggle` directly, like `wasi-common` * Add wiggle-macro to test-all script * Fixup a test
5 years ago
"thiserror",
wiggle: expand test suite sync test: show the dummy executor will trap (rather than panic) when a future inside it pends. async test: show that the executor is hooked up to a future that pends for a trivial amount of time. this adds tokio to the dev-dependencies of wiggle, it shouldn't end up increasing the build burden for the project as a whole since its already a dev-dependency.
3 years ago
"tokio",
use tracing 0.1.15 release
4 years ago
"tracing",
Implement RFC 11: Redesigning Wasmtime's APIs (#2897) Implement Wasmtime's new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it's best to read the RFC thread and the PR thread.
3 years ago
"wasmtime",
Shuffle around the wiggle crates (#1414) * Shuffle around the wiggle crates This commit reorganizes the wiggle crates slightly by performing the following transforms: * The `crates/wiggle` crate, previously named `wiggle`, was moved to `crates/wiggle/crates/macro` and is renamed to `wiggle-macro`. * The `crates/wiggle/crates/runtime` crate, previously named `wiggle-runtime`, was moved to `crates/wiggle` and is renamed to `wiggle`. * The new `wiggle` crate depends on `wiggle-macro` and reexports the macro. The goal here is that consumers only deal with the `wiggle` crate itself. No more crates depend on `wiggle-runtime` and all dependencies are entirely on just the `wiggle` crate. * Remove the `crates/wiggle/crates` directory Move everything into `crates/wiggle` directly, like `wasi-common` * Add wiggle-macro to test-all script * Fixup a test
5 years ago
"wiggle-macro",
Fix wiggle's tests
5 years ago
"wiggle-test",
Update wasi submodule (#1345) * Update wasi submodule Removes some dependencies from the `witx` crate since WebAssembly/WASI#243 * Don't pull witx from two places * Update submodule again
5 years ago
"witx",
Fix wiggle's tests
5 years ago
]
[[package]]
name = "wiggle-generate"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Fix wiggle's tests
5 years ago
dependencies = [
"anyhow",
"heck",
"proc-macro2",
"quote",
wiggle: witx paths use shell expansion instead of always being relative to CARGO_MANIFEST_DIR, each use site is responsible for either putting that variable or another one (set by a build.rs) at the start of witx paths.
4 years ago
"shellexpand",
Fix wiggle's tests
5 years ago
"syn",
Update wasi submodule (#1345) * Update wasi submodule Removes some dependencies from the `witx` crate since WebAssembly/WASI#243 * Don't pull witx from two places * Update submodule again
5 years ago
"witx",
Fix wiggle's tests
5 years ago
]
[[package]]
Shuffle around the wiggle crates (#1414) * Shuffle around the wiggle crates This commit reorganizes the wiggle crates slightly by performing the following transforms: * The `crates/wiggle` crate, previously named `wiggle`, was moved to `crates/wiggle/crates/macro` and is renamed to `wiggle-macro`. * The `crates/wiggle/crates/runtime` crate, previously named `wiggle-runtime`, was moved to `crates/wiggle` and is renamed to `wiggle`. * The new `wiggle` crate depends on `wiggle-macro` and reexports the macro. The goal here is that consumers only deal with the `wiggle` crate itself. No more crates depend on `wiggle-runtime` and all dependencies are entirely on just the `wiggle` crate. * Remove the `crates/wiggle/crates` directory Move everything into `crates/wiggle` directly, like `wasi-common` * Add wiggle-macro to test-all script * Fixup a test
5 years ago
name = "wiggle-macro"
Bump Wasmtime to 2.0.0 (#4874) This commit replaces #4869 and represents the actual version bump that should have happened had I remembered to bump the in-tree version of Wasmtime to 1.0.0 prior to the branch-cut date. Alas!
2 years ago
version = "2.0.0"
Fix wiggle's tests
5 years ago
dependencies = [
wiggle::async_trait is defined as async_trait::async_trait(?Send) async methods used by wiggle currently need to Not have the Send constraint, so rather than make all use sites pass the argument to the re-exported async_trait macro, define a new macro that applies the argument.
4 years ago
"proc-macro2",
wiggle-generate: paramaterize library on module path to runtime (#1574) * wiggle-generate: paramaterize library on module path to runtime This change makes no functional difference to users who only use the wiggle crate. Add a parameter to the `Names` constructor that determines the module that runtime components (e.g. GuestPtr, GuestError etc) of wiggle come from. For `wiggle` users this is just `quote!(wiggle)`, but other libraries which consume wiggle-generate may wrap and re-export wiggle under some other path, and not want their consumers to have to know about the wiggle dependency, e.g. `quote!(my_crate::some_path::wiggle)`. * wiggle-generate,macro: move more logic into macro better for code reuse elsewhere
5 years ago
"quote",
Shuffle around the wiggle crates (#1414) * Shuffle around the wiggle crates This commit reorganizes the wiggle crates slightly by performing the following transforms: * The `crates/wiggle` crate, previously named `wiggle`, was moved to `crates/wiggle/crates/macro` and is renamed to `wiggle-macro`. * The `crates/wiggle/crates/runtime` crate, previously named `wiggle-runtime`, was moved to `crates/wiggle` and is renamed to `wiggle`. * The new `wiggle` crate depends on `wiggle-macro` and reexports the macro. The goal here is that consumers only deal with the `wiggle` crate itself. No more crates depend on `wiggle-runtime` and all dependencies are entirely on just the `wiggle` crate. * Remove the `crates/wiggle/crates` directory Move everything into `crates/wiggle` directly, like `wasi-common` * Add wiggle-macro to test-all script * Fixup a test
5 years ago
"syn",
"wiggle",
"wiggle-generate",
Fix wiggle's tests
5 years ago
]
[[package]]
name = "wiggle-test"
wiggle: borrow checker lives in own crate, and supports both mut/immut
4 years ago
version = "0.21.0"
Fix wiggle's tests
5 years ago
dependencies = [
Update to clap 3.* (#4082) * Update to clap 3.0 This commit migrates all CLI commands internally used in this project from structopt/clap2 to clap 3. The intent here is to ensure that we're using maintained versions of the dependencies as structopt and clap 2 are less maintained nowadays. Most transitions were pretty straightforward and mostly dealing with structopt/clap3 differences. * Fix a number of `cargo deny` errors This commit fixes a few errors around duplicate dependencies which arose from the prior update to clap3. This also uses a new feature in `deny.toml`, `skip-tree`, which allows having a bit more targeted ignores for skips of duplicate version checks. This showed a few more locations in Wasmtime itself where we could update some dependencies.
3 years ago
"env_logger 0.9.0",
Fix wiggle's tests
5 years ago
"proptest",
wiggle: can swap in `tracing` for args
5 years ago
"thiserror",
use tracing 0.1.15 release
4 years ago
"tracing",
wiggle: can swap in `tracing` for args
5 years ago
"tracing-subscriber",
Shuffle around the wiggle crates (#1414) * Shuffle around the wiggle crates This commit reorganizes the wiggle crates slightly by performing the following transforms: * The `crates/wiggle` crate, previously named `wiggle`, was moved to `crates/wiggle/crates/macro` and is renamed to `wiggle-macro`. * The `crates/wiggle/crates/runtime` crate, previously named `wiggle-runtime`, was moved to `crates/wiggle` and is renamed to `wiggle`. * The new `wiggle` crate depends on `wiggle-macro` and reexports the macro. The goal here is that consumers only deal with the `wiggle` crate itself. No more crates depend on `wiggle-runtime` and all dependencies are entirely on just the `wiggle` crate. * Remove the `crates/wiggle/crates` directory Move everything into `crates/wiggle` directly, like `wasi-common` * Add wiggle-macro to test-all script * Fixup a test
5 years ago
"wiggle",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
[[package]]
name = "winapi"
Wasmtime 0.19.0 and Cranelift 0.66.0 (#2027) This commit updates Wasmtime's version to 0.19.0, Cranelift's version to 0.66.0, and updates the release notes as well.
4 years ago
version = "0.3.9"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Wasmtime 0.19.0 and Cranelift 0.66.0 (#2027) This commit updates Wasmtime's version to 0.19.0, Cranelift's version to 0.66.0, and updates the release notes as well.
4 years ago
checksum = "5c839a674fcd7a98952e593242ea400abe93992746761e38641405d28b00f419"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"winapi-i686-pc-windows-gnu",
"winapi-x86_64-pc-windows-gnu",
]
[[package]]
name = "winapi-i686-pc-windows-gnu"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ac3b87c63620426dd9b991e5ce0329eff545bccbbb34f3be09ff6fb6ab51b7b6"
[[package]]
name = "winapi-util"
Update deps and tests for `anyref` --> `externref` * Update to using `wasmparser` 0.55.0 * Update wasmprinter to 0.2.5 * Update `wat` to 1.0.18, and `wast` to 17.0.0
5 years ago
version = "0.1.5"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update deps and tests for `anyref` --> `externref` * Update to using `wasmparser` 0.55.0 * Update wasmprinter to 0.2.5 * Update `wat` to 1.0.18, and `wast` to 17.0.0
5 years ago
checksum = "70ec6ce85bb158151cae5e5c87f95a8e97d2c0c4b001223f33a334e3ce5de178"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"winapi",
]
[[package]]
name = "winapi-x86_64-pc-windows-gnu"
version = "0.4.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
[[package]]
name = "windows-sys"
version = "0.36.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "ea04155a16a59f9eab786fe12a4a450e75cdb175f9e0d80da1e17db09f55b8d2"
dependencies = [
"windows_aarch64_msvc",
"windows_i686_gnu",
"windows_i686_msvc",
"windows_x86_64_gnu",
"windows_x86_64_msvc",
]
[[package]]
name = "windows_aarch64_msvc"
version = "0.36.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "9bb8c3fd39ade2d67e9874ac4f3db21f0d710bee00fe7cab16949ec184eeaa47"
[[package]]
name = "windows_i686_gnu"
version = "0.36.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "180e6ccf01daf4c426b846dfc66db1fc518f074baa793aa7d9b9aaeffad6a3b6"
[[package]]
name = "windows_i686_msvc"
version = "0.36.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "e2e7917148b2812d1eeafaeb22a97e4813dfa60a3f8f78ebe204bcc88f12f024"
[[package]]
name = "windows_x86_64_gnu"
version = "0.36.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "4dcd171b8776c41b97521e5da127a2d86ad280114807d0b2ab1e462bc764d9e1"
[[package]]
name = "windows_x86_64_msvc"
version = "0.36.1"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "c811ca4a8c853ef420abd8592ba53ddbbac90410fab6903b3e79972a631f7680"
latest system-interface provides ReadReady::num_ready_bytes
4 years ago
[[package]]
name = "winx"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
version = "0.33.0"
latest system-interface provides ReadReady::num_ready_bytes
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
checksum = "b7b01e010390eb263a4518c8cebf86cb67469d1511c00b749a47b64c39e8054d"
latest system-interface provides ReadReady::num_ready_bytes
4 years ago
dependencies = [
"bitflags",
Port wasi-common from unsafe-io to io-lifetimes (#3049) * Port wasi-common to io-lifetimes. This ports wasi-common from unsafe-io to io-lifetimes. Ambient authority is now indicated via calls to `ambient_authority()` from the ambient-authority crate, rather than using `unsafe` blocks. The `GetSetFdFlags::set_fd_flags` function is now split into two phases, to simplify lifetimes in implementations which need to close and re-open the underlying file. * Use posish for errno values instead of libc. This eliminates one of the few remaining direct libc dependencies. * Port to posish::io::poll. Use posish::io::poll instead of calling libc directly. This factors out more code from Wasmtime, and eliminates the need to manipulate raw file descriptors directly. And, this eliminates the last remaining direct dependency on libc in wasi-common. * Port wasi-c-api to io-lifetimes. * Update to posish 0.16.0. * Embeded NULs in filenames now get `EINVAL` instead of `EILSEQ`. * Accept either `EILSEQ` or `EINVAL` for embedded NULs. * Bump the nightly toolchain to 2021-07-12. This fixes build errors on the semver crate, which as of this writing builds with latest nightly and stable but not 2021-04-11, the old pinned version. * Have cap-std-sync re-export ambient_authority so that users get the same version.
3 years ago
"io-lifetimes",
Update WASI to cap-std 0.25 and windows-sys. (#4302) This updates to rustix 0.35.6, and updates wasi-common to use cap-std 0.25 and windows-sys (instead of winapi). Changes include: - Better error code mappings on Windows. - Fixes undefined references to `utimensat` on Darwin. - Fixes undefined references to `preadv64` and `pwritev64` on Android. - Updates to io-lifetimes 0.7, which matches the io_safety API in Rust. - y2038 bug fixes for 32-bit platforms
2 years ago
"windows-sys",
latest system-interface provides ReadReady::num_ready_bytes
4 years ago
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "witx"
update WASI submodule (#3025) * wasi-common: update wasi submodule This updates the WASI submodule, pulling in changes to the witx crate, now that there is a 0.9.1 version including some bug fixes. See WebAssembly/WASI#434 for more information. * wiggle: update witx dependencies * publish: verify and vendor witx-cli * adjust root workspace members This commit removes some items from the root manifest's workspace members array, and adds `witx-cli` to the root `workspace.exclude` array. The motivation for this stems from a cargo bug described in rust-lang/cargo#6745: `workspace.exclude` does not work if it is nested under a `workspace.members` path. See WebAssembly/WASI#438 for the underlying change to the WASI submodule which reorganized the `witx-cli` crate, and WebAssembly/WASI#398 for the original PR introducing `witx-cli`. See [this comment](https://github.com/bytecodealliance/wasmtime/pull/3025#issuecomment-867741175) for more details about the compilation errors, and failed alternative approaches that necessitated this change. N.B. This is not a functional change, these crates are still implicitly workspace members as transitive dependencies, but this will allow us to side-step the aforementioned cargo bug. Co-Authored-By: Alex Crichton <alex@alexcrichton.com> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
3 years ago
version = "0.9.1"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
Upgrade to witx 0.8.0 with tagged unions (#921) * witx tagged unions: updates to wig to use new semantics * wig: emit a `#variant: ()` union variant for empty variants * wasi-common: translate to use tagged unions * update to flattened layout of event struct * wig: generate layout tests, and delete bindgen ones the bindgen tests became out-of-date with the latest changes to the representation of unions, and the re-jiggering of various struct definitions that went along with it. * wasi: point at master with tagged union PR merged * fix event struct repr on windows
5 years ago
"anyhow",
Auto-generate the `hostcalls` module of `wasi-common` (#846) * Auto-generate shims for old `wasi_unstable` module This commit is effectively just doing what #707 already did, but applying it to the `snapshot_0` module as well. The end result is the same, where we cut down on all the boilerplate in `snapshot_0` and bring it in line with the main `wasi_snapshot_preview1` implementation. The goal here is to make it easier to change the two in tandem since they're both doing the same thing. * Migrate `wasi_common::hostcalls` to a macro This commit migrates the `hostcalls` module to being auto-generated by a macro rather than duplicating a handwritten signature for each wasi syscall. * Auto-generate snapshot_0's `hostcalls` module Similar to the previous commit, but for `snapshot_0` * Delete the `wasi-common-cbindgen` crate This is no longer needed with the hostcalls macro now, we can easily fold the definition of the cbindgen macro into the same crate. * Rustfmt * Fix windows build errors * Rustfmt * Remove now no-longer-necessary code * rustfmt
5 years ago
"log",
Update to the next version of the witx crate This commit updates to the 0.9 version of the witx crate implemented in WebAssembly/wasi#395. This new version drastically changes code generation and how we interface with the crate. The intention is to abstract the code generation aspects and allow code generators to implement much more low-level instructions to enable more flexible APIs in the future. Additionally a bunch of `*.witx` files were updated in the WASI repository. It's worth pointing out, however, that `wasi-common` does not change as a result of this change. The shape of the APIs that we need to implement are effectively the same and the only difference is that the shim functions generated by wiggle are a bit different.
4 years ago
"rayon",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
"thiserror",
update WASI submodule (#3025) * wasi-common: update wasi submodule This updates the WASI submodule, pulling in changes to the witx crate, now that there is a 0.9.1 version including some bug fixes. See WebAssembly/WASI#434 for more information. * wiggle: update witx dependencies * publish: verify and vendor witx-cli * adjust root workspace members This commit removes some items from the root manifest's workspace members array, and adds `witx-cli` to the root `workspace.exclude` array. The motivation for this stems from a cargo bug described in rust-lang/cargo#6745: `workspace.exclude` does not work if it is nested under a `workspace.members` path. See WebAssembly/WASI#438 for the underlying change to the WASI submodule which reorganized the `witx-cli` crate, and WebAssembly/WASI#398 for the original PR introducing `witx-cli`. See [this comment](https://github.com/bytecodealliance/wasmtime/pull/3025#issuecomment-867741175) for more details about the compilation errors, and failed alternative approaches that necessitated this change. N.B. This is not a functional change, these crates are still implicitly workspace members as transitive dependencies, but this will allow us to side-step the aforementioned cargo bug. Co-Authored-By: Alex Crichton <alex@alexcrichton.com> Co-authored-by: Alex Crichton <alex@alexcrichton.com>
3 years ago
"wast 35.0.2",
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
]
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
[[package]]
name = "xoodyak"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "0.7.3"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "94b52dbbb9ca4862dcd5e33383af1610db2f28d081e0803e3a3b2bbdfab5eeed"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"rawbytes",
"zeroize",
]
[[package]]
name = "zeroize"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.4.3"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "d68d9dcec5f9b43a30d38c49f91dfedfaac384cb8f085faca366c26207dd1619"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"zeroize_derive",
]
[[package]]
name = "zeroize_derive"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
version = "1.3.2"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
`wasm-mutate` fuzz targets (#3836) * fuzzing: Add a custom mutator based on `wasm-mutate` * fuzz: Add a version of the `compile` fuzz target that uses `wasm-mutate` * Update `wasmparser` dependencies
3 years ago
checksum = "3f8f187641dad4f680d25c4bfc4225b418165984179f26ca76ec4fb6441d3a17"
Add support for the experimental wasi-crypto APIs (#2597) * 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
4 years ago
dependencies = [
"proc-macro2",
"quote",
"syn",
"synstructure",
]
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
[[package]]
name = "zstd"
Update zstd to 0.11.1 (#3938)
3 years ago
version = "0.11.1+zstd.1.5.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update zstd to 0.11.1 (#3938)
3 years ago
checksum = "77a16b8414fde0414e90c612eba70985577451c4c504b99885ebed24762cb81a"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"zstd-safe",
]
[[package]]
name = "zstd-safe"
Update zstd to 0.11.1 (#3938)
3 years ago
version = "5.0.1+zstd.1.5.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update zstd to 0.11.1 (#3938)
3 years ago
checksum = "7c12659121420dd6365c5c3de4901f97145b79651fb1d25814020ed2ed0585ae"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"libc",
"zstd-sys",
]
[[package]]
name = "zstd-sys"
Update zstd to 0.11.1 (#3938)
3 years ago
version = "2.0.1+zstd.1.5.2"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
source = "registry+https://github.com/rust-lang/crates.io-index"
Update zstd to 0.11.1 (#3938)
3 years ago
checksum = "9fd07cbbc53846d9145dbffdf6dd09a7a0aa52be46741825f5c97bdd4f73f12b"
Commit Cargo.lock. (#705) * Commit Cargo.lock. The Cargo documentation recommends packages which produce end-user programs, which wasmtime-cli is, to check in their Cargo.lock files: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries * Use Cargo's newer less-conflicting lockfile format
5 years ago
dependencies = [
"cc",
"libc",
]