First, great work on the package!

I'd love to have Wasmer server-side WebAssembly runtime available for users of cargo-wasi, as I think it will very useful for them to test and run WASI files with our runtime with different backends (regarding speed, for example, for benchmarking).

What would be required in our side to make this possible?

Keep up the great work!

When I run

cargo new missing_manifest_path
cargo wasi test --manifest-path missing_manifest_path/Cargo.toml

I get the following error

error: could not find `Cargo.toml` in `/private/tmp` or any parent directory
error: failed to execute "cargo" "metadata" "--no-deps" "--format-version=1"

I guess there is some kind of recognition of the flag because if I indicate just the folder and not the Cargo.toml file itself, I get

cargo wasi test --manifest-path missing_manifest_path/    // missing Cargo.toml here
error: the manifest-path must be a path to a Cargo.toml file

Something like cargo wasi build -t wat.

Right now, I'm running cargo wasi build followed by wasm2wat /path/to/project.wasm which generates /path/to/project.wat.

The book has:

authors = ["The carog-wasi Authors"]

I just tried this project out this morning and hit an issue. I think I must have missed a step but not sure where. I can build simple projects but when running them I get an error that "wasi_snapshot_preview1" isn't found. The wasm file produced runs just fine in a bench build of wasmtime I have. I have a feeling I missed a step.

Following are versions and output from running

$ cargo wasi --version
cargo-wasi 0.1.20 (ad1e122eb2 2020-01-21)
$ rustc --version
rustc 1.41.0 (5e1a79984 2020-01-27)
$ cargo wasi run
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `/home/stusmall/.cargo/bin/cargo-wasi target/wasm32-wasi/debug/wasi-hello-world.wasm`
     Running `target/wasm32-wasi/debug/wasi-hello-world.wasm`
error: failed to process main module `target/wasm32-wasi/debug/wasi-hello-world.wasm`
    caused by: Import module wasi_snapshot_preview1 was not found

Please let me know if you need any more information about my host set up

• Thread at start
• Throttle the thread over time
• Print if build was successful

Is there a way to somehow pass --lightbeam flag to the wasmtime? I could not find a way to do this.

As a policy, the Bytecode Alliance is changing the default branch names in all repositories. We would like for all projects to change the default to main by June 26. (We mention June 26th because there is some suggestion that GitHub may be adding the ability to make this process more seamless. Feel free to wait for that, but only up to June 26. We'll provide further support and documentation before that date.)

Please consider this a tracking issue. It is not intended for public debate.

• Change branch name
• Update CI
• Update build scripts
• Update documentation

• Auto publish it
• CLI options
• Manifest options
• Examples

I'm trying to use cargo wasi in conjunction with wasmtime and I'm having difficulties, because I'd like to use the wasm interface types. For example I have a simple rust lib:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

When I compile it with cargo wasi build --release, I get the Webassembly module (printed with wasmprinter):

(module
  (type (;0;) (func (param i32 i32) (result i32)))
  (func $add (type 0) (param i32 i32) (result i32)
    local.get 1
    local.get 0
    i32.add)
  (table (;0;) 32 anyref)
  (memory (;0;) 17)
  (global (;0;) (mut i32) (i32.const 1048576))
  (export "memory" (memory 0))
  (export "add" (func $add))
  (data (;0;) (i32.const 1048576) "\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00"))

However, the table with anyref generated always seems to throw an error. Specifically with wasmtime::Config.wasm_reference_types enabled:

thread 'main' panicked at 'not implemented: tables of types other than anyfunc (r64)'

I don't know if this is expected behavior, and I'm also confused on why the table is generated in the first place. Any help and explanation would be greatly appreciated

Hi I have a web app (yew based) which uses wasm-bindgen. cargo wasi check returns no errors and the build itself seems to work. However the wasm-bindgen-cli thingy fails with this error:

error: failed to generate a standard interface types section

Caused by:
    0: in adapter function
    1: import of wasm-bindgen specific intrinsic `__wbindgen_string_new` requires JS glue
error: failed to process wasm at `C:\Users\mtrnord\IdeaProjects\Daydream\target\wasm32-wasi\release\daydream_app.rustc.wasm`

Caused by:
    failed to execute "C:\\Users\\mtrnord\\AppData\\Local\\cargo-wasi\\0.1.22\\wasm-bindgen\\0.2.67\\wasm-bindgen.exe" "C:\\Users\\mtrnord\\IdeaProjects\\Daydream\\target\\wasm32-wasi\\release\\daydream_app.rustc.wasm" "--out-dir" "C:\\Users\\mtrnord\\IdeaProjects\\Daydream\\target\\wasm32-wasi\\release\\.tmpc3QP8R" "--out-name" "foo"
        status: exit code: 1
[cargo-make] ERROR - Error while executing command, exit code: 1

Any hint on why this happens or how I can fix this issue? I ran cargo wasi build --release --bin daydream_app to get to this issue

Hi, I am getting a build failure on Windows:

C:\Users\mylogin>cargo install cargo-wasi
   ...
   Compiling toml v0.5.5
   Compiling cookie_store v0.7.0
   Compiling reqwest v0.9.24
   Compiling cargo-wasi v0.1.18
error[E0433]: failed to resolve: use of undeclared type or module `cargo_wasi_src`
  --> C:\Users\mylogin\.cargo\registry\src\github.com-1ecc6299db9ec823\cargo-wasi-0.1.18\src\main.rs:43:32
   |
43 |         fn cargo_wasi_main() { cargo_wasi_src::main() }
   |                                ^^^^^^^^^^^^^^ use of undeclared type or module `cargo_wasi_src`

error: aborting due to previous error

I am trying to follow this instruction:
https://github.com/bytecodealliance/wasmtime-demos/tree/master/dotnet

The only preceding step was to install Rust from: https://win.rustup.rs/

Am I missing something or is there a problem in cargo-wasi?

Hello, I'm fairly new to the WASI ecosystem, and am trying to use cargo-wasi to build and run an application that uses rusty v8 it fails with this output:

❯ cargo wasi build
   Compiling v8 v0.60.0
error: failed to run custom build command for `v8 v0.60.0`

Caused by:
  process didn't exit successfully: `/Users/ethanarrowood/Documents/Programming/github/ethan-arrowood/blegh/target/debug/build/v8-f3fd52c561ba89f3/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=.gn
  cargo:rerun-if-changed=BUILD.gn
  cargo:rerun-if-changed=src/binding.cc
  cargo:rerun-if-env-changed=CCACHE
  cargo:rerun-if-env-changed=CLANG_BASE_PATH
  cargo:rerun-if-env-changed=DENO_TRYBUILD
  cargo:rerun-if-env-changed=DOCS_RS
  cargo:rerun-if-env-changed=GN
  cargo:rerun-if-env-changed=GN_ARGS
  cargo:rerun-if-env-changed=HOST
  cargo:rerun-if-env-changed=NINJA
  cargo:rerun-if-env-changed=OUT_DIR
  cargo:rerun-if-env-changed=RUSTY_V8_ARCHIVE
  cargo:rerun-if-env-changed=RUSTY_V8_MIRROR
  cargo:rerun-if-env-changed=SCCACHE
  cargo:rerun-if-env-changed=V8_FORCE_DEBUG
  cargo:rerun-if-env-changed=V8_FROM_SOURCE
  cargo:rustc-link-lib=static=rusty_v8
  download lockfile: "/Users/ethanarrowood/Documents/Programming/github/ethan-arrowood/blegh/target/wasm32-wasi/debug/build/lib_download.fslock"
  static lib URL: https://github.com/denoland/rusty_v8/releases/download/v0.60.0/librusty_v8_release_wasm32-wasi.a
  cargo:rustc-link-search=/Users/ethanarrowood/Documents/Programming/github/ethan-arrowood/blegh/target/wasm32-wasi/debug/gn_out/obj
  Downloading https://github.com/denoland/rusty_v8/releases/download/v0.60.0/librusty_v8_release_wasm32-wasi.a
  Python downloader failed, trying with curl.

  --- stderr
  thread 'main' panicked at 'assertion failed: status.success()', /Users/ethanarrowood/.cargo/registry/src/github.com-1ecc6299db9ec823/v8-0.60.0/build.rs:411:3
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I looked into it and the error is cause from this part of the libraries build script: https://github.com/denoland/rusty_v8/blob/b7cfc588fd598440c9681cb20dbe923aa355421c/build.rs#L392-L411

This build script has no issue when run with cargo build. Is curl disabled or unavailable from cargo wasi build?

Blow away the entire internal cache when this is executed

When I build using cargo wasi build on Mac OS on a Mac with an M1 processor, I get:

  Optimizing with wasm-opt
error: failed to process wasm at `***.wasm`

Caused by:
    `wasm-opt` failed to execute

Caused by:
    no precompiled binaries of `wasm-opt` are available for this platform, you'll want to set `$WASM_OPT` to a preinstalled `wasm-opt` command or disable via `wasm-opt = false` in your manifest

I found the program in the latest release of bynaryen.

Is that possible that cargo-wasi does not have it because it uses an older version which might not support amd64-mac?

If this is packaged elsewhere the update-check will want to be disabled!

I am using cargo-wasi for Shopify functions. However, whenever I run cargo wasi run, the following error shows error: failed to find the wasm32-wasitarget installed, and rustup is also not detected, you'll need to be sure to install thewasm32-wasi target before using this command.

I've tried rustup target add wasm32-wasi command. And I am using mac m1.

# Cargo.toml

[package]
name = "hello-multi-value"
version = "0.1.0"
authors = ["Nick Fitzgerald <[email protected]>"]
edition = "2018"



# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2.54"

// src/lib.rs

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        assert_eq!(2 + 2, 4);
    }
}

$ cargo wasi build
   Compiling hello-multi-value v0.1.0 (/home/fitzgen/scratch/hello-multi-value)
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
 Downloading precompiled wasm-bindgen v0.2.54
error: failed to find heap alloc

error: failed to process wasm at `/home/fitzgen/scratch/hello-multi-value/target/wasm32-wasi/debug/hello_multi_value.rustc.wasm`

Caused by:
    failed to execute "/home/fitzgen/.cache/cargo-wasi/0.1.16/wasm-bindgen/0.2.54/wasm-bindgen" "/home/fitzgen/scratch/hello-multi-value/target/wasm32-wasi/debug/hello_multi_value.rustc.wasm" "--keep-debug" "--out-dir" "/home/fitzgen/scratch/hello-multi-value/target/wasm32-wasi/debug/.tmpMS6NTH" "--out-name" "foo"
        status: exit code: 1

I think the root cause is in wasm-bindgen but it is more clear that this is a bug and not expected behavior in the context of cargo wasi.

This appears to be originating in the anyref xform, and we probably just need to gracefully handle when there aren't any anyrefs better.

It looks like some Wasm modules produced by Rust 1.67 include memory.copy and memory.fill instructions. Unfortunately when wasm-opt is invoked by cargo wasi build --release, the --enable-bulk-memory flag is not passed to wasm-opt, so we see errors that look like:

[wasm-validator error in function 432] unexpected false: Bulk memory operations require bulk memory [--enable-bulk-memory], on

These errors appear on modules that wasm-opt is able to process without enabling bulk memory operations when compiled with Rust 1.66. Passing the --enable-bulk-memory flag to wasm-opt allows it to process these modules compiled by Rust 1.67 successfully.

If cargo-wasi were to pass that flag when invoking wasm-opt, that should result in these validation errors not surfacing when running cargo wasi build --release when using Rust 1.67.

Currently wasm-opt is run like so:

• If WASM_OPT is set, run that
• Otherwise, download a precompiled binary
• If no precompiled binary exists, error

This fails to handle a pre-installed wasm-opt, and while it's perhaps a good balance for cargo install'd binaries this probably is the wrong balance for installation of this tool through other mechanisms. A build time config option should be added to enable usage of wasm-opt on PATH by default and/or disabling the download of precompiled binaries.

As brought up in #25 I think it's fine to pick any option as the default, since the main use case is the precompiled binaries on crates.io which we can always configure as we want on CI.

Related to #17, tests that rely on any kind of test file, like expected results or test data, are unable to run with cargo wasi test.

When running tests, we should have a sensible default like --dir=.. We could use the same mechanism proposed in #19, but I would still want to provide a default preopen. This will make converting existing projects to Wasm and WASI as seamless as possible.

git clone https://github.com/image-rs/image-tiff.git
cd image-tiff
cargo build && cargo test # works

cargo wasi build && cargo wasi test # should also "just work"

Im having trouble compiling with SIMD. When trying to compile, I receive the following:

RUSTFLAGS="-C target-feature=+simd128" cargo wasi build --release --package app
<compilation output>
Finished release [optimized] target(s) in 0.09s
  Processing /home/rimi/Documents/example/target/wasm32-wasi/release/app.rustc.wasm
error: failed to process wasm at `/home/rimi/Documents/example/target/wasm32-wasi/release/app.rustc.wasm`
Caused by:
    failed to parse code section
Caused by:
    found type v128
Caused by:
    expected type i32
Caused by:
    The input WebAssembly is invalid

I suspect that there is a need to pass SIMD specific flags to some of the tooling, such as wasm-opt.
However, the same occurs even without the --release flag which should disable running the optimization step, so maybe the error originates from wasm bindgen? Its hard to tell what tool in the toolchain the error is originating from. Same is true for succeeding steps - there is no report on what tool actually succeeded in running
I am trying to target wasmtime and other standalone runtimes.
What kind of flags / steps do I need to take in order to compile with SIMD or is it not supported by cargo-wasi?

I also noted that if I have already compiled without SIMD successfully and then compile with SIMD unsuccessfully and try again, the compilation will simply skip the compilation and other steps altogether and report a success.
The compilation succeeds (as seen in the above error output), sure, but the optimization steps and such that are normally performed afterwards that cause an error are skipped. The files from a previous working non SIMD build are left in the target folder and could be used by a user if they are not careful.
For example:

cargo wasi build --release --package app # Success
RUSTFLAGS="-C target-feature=+simd128" cargo wasi build --release --package app # Error
RUSTFLAGS="-C target-feature=+simd128" cargo wasi build --release --package app # Success, even though shouldnt

Following #3, I'd like to know if you would be interested in supporting multiple WASI runtimes (wasmer, WAVM) so we don't need to fork the project to make them available for the users :)

cc @AndrewScheidecker

I am having an issue building the markdown example. I clone the repo and tried to build the markdown example using the following command

cargo wasi build --release

The build failed with following error:

Following are the version of tools installed:

cargo-wasi 0.1.23 (aa58e595d4 2021-07-29)
rustc 1.57.0 (f1edd0429 2021-11-29)
cargo 1.57.0 (b2e52d7ca 2021-10-21)
wasmtime 0.28.0

Could someone help me to build and run it using wastime?

When debugging a build script, I noticed that building with cargo wasi build -vv can error out when encountering extra print statements in build.rs. For example, with the wasi-hello-world project, adding a build.rs file with:

fn main() {
   println!("the build is going great!");
}

leads to an error with the message: error: failed to parse [wasi-hello-world 0.1.0] the build is going great!: expected value at line 1 column 2 because this line aborts the program when parsing fails. Changing that line to print a warning and continue seems like a straightforward fix.

Building with just a single -v doesn't trigger issue because Cargo suppresses the print statements at that level of verbosity (commit rust-lang/cargo@2c0d6af)

I am trying to use this inside a workspace to compile one member which will then be called from another member, however it is failing to deserialize the Cargo.toml.

The project structure looks like:

Cargo.toml
host
 - Cargo.toml
 - src/main.rs
udf
 - Cargo.toml
 - src/lib.rs

The workspace is defined in the top level Cargo.toml, and then I try to call cargo wasi build from the udf folder. This errors with the following:

< [/code/some_project/udf] cargo wasi build
> Finished dev [unoptimized + debuginfo] target(s) in 0.04s
> error: failed to deserialize as TOML: /code/some_project/Cargo.toml
> Caused by:
>    missing field `package` at line 3 column 1

If I add [package] to the worspace's Cargo.toml I get the following error:

> Caused by:
>   no targets specified in the manifest
>   either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present

create ./.cargo/config.toml file, and write content:

[build]
target = "wasm32-wasi"

[target.wasm32-wasi]
runner = "wasmtime"

next, run some cargo command,

• cargo run
• cargo build
• ...

While playing with cargo-wasi, I've encountered a strange error when trying to build the markdown example. Here's the cargo wasi build output:

kubkon@kubkon-mac ~/d/cargo-wasi> cargo wasi build -p markdown
  Downloaded pulldown-cmark v0.6.1
  Downloaded wasm-bindgen v0.2.50
  Downloaded getopts v0.2.21
  Downloaded memchr v2.2.1
  Downloaded unicase v2.6.0
  Downloaded bitflags v1.2.1
  Downloaded wasm-bindgen-macro v0.2.50
  Downloaded unicode-width v0.1.6
  Downloaded version_check v0.9.1
  Downloaded quote v1.0.2
  Downloaded wasm-bindgen-macro-support v0.2.50
  Downloaded syn v1.0.8
  Downloaded proc-macro2 v1.0.6
  Downloaded wasm-bindgen-shared v0.2.50
  Downloaded wasm-bindgen-backend v0.2.50
  Downloaded unicode-xid v0.2.0
  Downloaded bumpalo v2.6.0
  Downloaded lazy_static v1.4.0
  Downloaded log v0.4.8
   Compiling proc-macro2 v1.0.6
   Compiling unicode-xid v0.2.0
   Compiling log v0.4.8
   Compiling syn v1.0.8
   Compiling wasm-bindgen-shared v0.2.50
   Compiling cfg-if v0.1.10
   Compiling lazy_static v1.4.0
   Compiling version_check v0.9.1
   Compiling bumpalo v2.6.0
   Compiling memchr v2.2.1
   Compiling bitflags v1.2.1
   Compiling wasm-bindgen v0.2.50
   Compiling pulldown-cmark v0.6.1
   Compiling unicode-width v0.1.6
   Compiling unicase v2.6.0
   Compiling getopts v0.2.21
   Compiling quote v1.0.2
   Compiling wasm-bindgen-backend v0.2.50
   Compiling wasm-bindgen-macro-support v0.2.50
   Compiling wasm-bindgen-macro v0.2.50
   Compiling markdown v0.1.0 (/Users/kubkon/dev/cargo-wasi/examples/markdown)
    Finished dev [unoptimized + debuginfo] target(s) in 31.77s
error: failed to generate a standard wasm bindings custom section
    caused by: cannot generate a standalone WebAssembly module which contains an import of wasm-bindgen specific intrinsic `__wbindgen_throw` since it requires JS glue
error: failed to process wasm at `/Users/kubkon/dev/cargo-wasi/target/wasm32-wasi/debug/markdown.rustc.wasm`

Caused by:
    failed to execute "/Users/kubkon/Library/Caches/cargo-wasi/0.1.17/wasm-bindgen/0.2.50/wasm-bindgen" "/Users/kubkon/dev/cargo-wasi/target/wasm32-wasi/debug/markdown.rustc.wasm" "--keep-debug" "--out-dir" "/Users/kubkon/dev/cargo-wasi/target/wasm32-wasi/debug/.tmpdKaBFK" "--out-name" "foo"
        status: exit code: 1

To my inexperienced eyes, this looks like a problem with wasm-bindgen. In fact, I've traced it down to [this line here].

I'm not sure whether this is the best place to submit the issue since it looks like not a problem with cargo-wasi itself, but I thought I'll submit it here first to gather some feedback (looking at you here @alexcrichton ;-) and we'll take it from there.

Oh, and this might be of help, I've tried all wasm-bindgen versions starting from 0.2.50 all the way up to 0.2.54, alas, no joy.

Hi, I try to build a project using cargo wasi with the cargo wasi build command.
But it returnes with the following error:

   Compiling version_check v0.9.3
   Compiling rand_core v0.6.3
   Compiling cc v1.0.68
   Compiling subtle v2.4.0
   Compiling protobuf v2.24.1
   Compiling untrusted v0.7.1
   Compiling generic-array v0.14.4
   Compiling ring v0.16.20
error[E0432]: unresolved import `super::sysrand_chunk`
   --> /home/hanif/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.20/src/rand.rs:306:16
    |
306 |     use super::sysrand_chunk::chunk;
    |                ^^^^^^^^^^^^^ could not find `sysrand_chunk` in `super`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `ring`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed```


The content of cargo.toml file is as follows:

[package]
name = "echo_server"
version = "0.1.0"
authors = ["hanifff [email protected]"]
edition = "2018"

[lib]
crate-type = ['cdylib']

[dependencies]
protobuf = "2.24.1"
ecdsa = "0.12.2"
ring = "0.16.20"

Rust verison: 

```rustc 1.55.0-nightly (7c3872e6b 2021-06-24)````

Cargo version:

```
cargo 1.55.0-nightly (9233aa06c 2021-06-22)
```

Cargo-wasi version:

```
cargo-wasi 0.1.22 (22e2961ab2 2020-04-23)

The project can be build by cargo build command.

CI seems to install a precompiled binary of wasmtime 0.3.0, rather than the current version. Please consider testing against the current version.

This project is really cool, and I'm trying to wrap it into a nix expression so that people can get this tool from nix directly, to install it in the nix-store and without installation issues.
This have been done for cargo-watch.
This is really simple to create a nix-expression for a derivation with a rust program, you have the example for cargo-watch here

And to do that, I would just need a Cargo.lock, to create a hash of it and get a reproducible build.
(and this is best practise to add this file to a repository anyway).

Is that possible ?

Trying to run my library with cargo wasi test --doc has no output besides Finished test [unoptimized + debuginfo] target(s) in 0.04s.

I have doc tests present in my code, though they don't seem to be run at all with or without the --doc flag.

Precompiled ones segfault everywhere!

cargo wasi run -- --dir=. currently fails, but it's pretty close to working. I found out that after removing arg("--") the above command succeeds. Is it here intentionally?

Hello!

I am very new to the wasm ecosystem and trying a bit all the tools/framework/runtime out there.
I am working on porting https://github.com/cloudflare/sliceslice-rs to wasm.
That project requires simd instructions to work.

I have a wip branch working but to run the tests, I cannot simple do:

$ cargo wasi test
    Finished test [unoptimized + debuginfo] target(s) in 0.00s
     Running unittests (target/wasm32-wasi/debug/deps/sliceslice-c22d039e805d5bb0.wasm)
     Running tests/i386.rs (target/wasm32-wasi/debug/deps/i386-310c1b29d531f32f.wasm)
     Running `/home/adema/code/sliceslice-rs/target/wasm32-wasi/debug/deps/sliceslice-c22d039e805d5bb0.wasm`
Error: failed to run main module `/home/adema/code/sliceslice-rs/target/wasm32-wasi/debug/deps/sliceslice-c22d039e805d5bb0.wasm`

Caused by:
    0: WebAssembly translation error
    1: Invalid input WebAssembly code at offset 337919: SIMD support is not enabled

because the simd feature of wasmtime is not enabled by default.

My problem is that I haven't found a way to enable simd from cargo-wasi.
To run the tests, I have to manually run:

$ wasmtime --enable-simd /home/adema/code/sliceslice-rs/target/wasm32-wasi/debug/deps/sliceslice-c22d039e805d5bb0.wasm

running 14 tests
test tests::memchr_search_different ... ok
test tests::memchr_search_middle ... ok
test tests::memchr_search_mutiple ... ok
test tests::memchr_search_prefix ... ok
test tests::memchr_search_same ... ok
test tests::memchr_search_suffix ... ok
test tests::needle_array_size ... ok
test tests::needle_slice_size ... ok
test wasm32::tests::search_different ... ok
test wasm32::tests::search_middle ... ok
test wasm32::tests::search_multiple ... ok
test wasm32::tests::search_prefix ... ok
test wasm32::tests::search_same ... ok
test wasm32::tests::search_suffix ... ok

test result: ok. 14 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

but that requires finding the wasm binary path which is not easily predictable.

My question is then: is there a way to pass command line options to wasmtime?
I can see different options if that's not already implemented:

• by specifying cargo metadata variable
• by using an environment variable like WASMTIMEFLAGS
• by specifying command line arguments tocargo wasi test

Thank you in advance for taking the time to read this 👍

When executing cargo wasi run on Windows with a username with a space in it, cargo-wasi does not properly quote the path of the cargo-wasi executable.

 cargo wasi run -v
     Running "cargo" "run" "--target" "wasm32-wasi" "--message-format" "json-render-diagnostics" "-v"
       Fresh rustagram v0.1.0 (C:\Code\testrun\rustagram)
     Running `C:\Users\Florian Gilcher\.cargo\bin\cargo-wasi.exe target\wasm32-wasi\debug\rustagram.wasm`
wasm` (never executed)
Caused by:
  The system cannot find the file specified. (os error 2)
error: failed to execute "cargo" "run" "--target" "wasm32-wasi" "--message-format" "json-render-diagnostics" "-v"
    status: exit code: 101

Further investigation shows that C:\Users\Florian Gilcher\.cargo\bin\cargo-wasi.exe is not found due to a space in the username.

When using the dot method from the ndarray crate, a library compiled with cargo-wasi fails to import into wasmtime for .NET with the exception:

Unhandled exception. Wasmtime.WasmtimeException: WebAssembly module 'module.wasm' is not valid.

Testing the generated wasm file with the wasm-validate tool from https://github.com/WebAssembly/wabt results in the following output:

0000034: error: result count must be 0 or 1

Using wasm-objdump to investigate the header at 000034 gives the following output:

Contents of section Type:
000000e: 1460 0000 6000 017f 6001 7f00 6001 7f01  .`..`...`...`...
000001e: 7f60 017f 017e 6002 7f7f 0060 027f 7f01  .`...~`....`....
000002e: 7f60 027f 7f02 7f7f 6003 7f7f 7f00 6003  .`......`.....`.
000003e: 7f7f 7f01 7f60 047f 7f7f 7f00 6004 7f7f  .....`......`...
000004e: 7f7f 017f 6005 7f7f 7f7f 7f00 6005 7f7f  ....`.......`...
000005e: 7f7f 7f01 7f60 067f 7f7f 7f7f 7f01 7f60  .....`.........`
000006e: 077f 7f7f 7f7f 7f7f 017f 6009 7f7f 7f7f  ..........`.....
000007e: 7f7f 7f7f 7f01 7f60 037f 7c7c 0060 037e  .......`..||.`.~
000008e: 7f7f 017f 6007 7c7c 7f7f 7c7c 7f00       ....`.||..||..

When commenting out the call to the dot method, the Type section changes to:

Contents of section Type:
000000e: 1260 0000 6000 017f 6001 7f00 6001 7f01  .`..`...`...`...
000001e: 7f60 017f 017e 6002 7f7f 0060 027f 7f01  .`...~`....`....
000002e: 7f60 027f 7f02 7f7f 6003 7f7f 7f00 6003  .`......`.....`.
000003e: 7f7f 7f01 7f60 047f 7f7f 7f00 6004 7f7f  .....`......`...
000004e: 7f7f 017f 6005 7f7f 7f7f 7f00 6005 7f7f  ....`.......`...
000005e: 7f7f 7f01 7f60 067f 7f7f 7f7f 7f01 7f60  .....`.........`
000006e: 077f 7f7f 7f7f 7f7f 017f 6009 7f7f 7f7f  ..........`.....
000007e: 7f7f 7f7f 7f01 7f60 037e 7f7f 017f       .......`.~....

I'm having problems using cargo-wasi in conjunction with with wasm-bindgen. Specifically, cargo-wasi seems to force WebAssembly interface types to be enabled, and if there is a technique to turn it off, I can't seem to find it.

This seems to happen with a completely fresh project. Steps to reproduce:

1. cargo new uses-wasm-bindgen --lib
2. Add wasm-bindgen = "0.2.78" to the [dependencies] section of Cargo.toml
3. Add wasm-bindgen-test = "0.3.13" to the [dev-dependencies] section of Cargo.toml
4. cargo wasi test --release

Running this gives me the following message:

Error: failed to run main module C:\dev\uses-wasm-bindgen\target\wasm32-wasi\release\deps\uses_wasm_bindgen-40c17809ffa9b77b.wasm

Caused by:
0: failed to parse WebAssembly module
1: Unsupported feature: Support for interface types has temporarily been removed from wasmtime.

   For more information about this temoprary you can read on the issue online:

       https://github.com/bytecodealliance/wasmtime/issues/1271

   and for re-adding support for interface types you can see this issue:

       https://github.com/bytecodealliance/wasmtime/issues/677

Curiously wasm-pack test --node works just fine (though it reports no tests to run in this trivial case)

I want to make some use of wasm-bindgen to generate bindings so that I can invoke Rust methods from JavaScript, but cargo-wasi seems to force on a capability (interface types) not supported by wasm-bindgen. I'm very new to WebAssembly, so I could be making a simple mistake.

cargo add zstd-sys # or any other C-dependent crate
cargo wasi build

Results in:

warning: zstd/lib/common/zstd_deps.h:29:10: fatal error: 'string.h' file not found
warning: #include <string.h>
…
error occurred: Command "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "--target=wasm32-wasi" "-I" "zstd/lib/" "-I" "zstd/lib/common" "-I" "zstd/lib/legacy" "-fvisibility=hidden" "-DZSTD_LIB_DEPRECATED=0" "-DXXH_PRIVATE_API=" "-DZSTDLIB_VISIBILITY=" "-DZDICTLIB_VISIBILITY=" "-DZSTDERRORLIB_VISIBILITY=" "-DZSTD_LEGACY_SUPPORT=1" "-o" "/private/tmp/testing/target/wasm32-wasi/debug/build/zstd-sys-1e822e2310f0cb71/out/zstd/lib/common/entropy_common.o" "-c" "zstd/lib/common/entropy_common.c" with args "clang" did not execute successfully (status code exit status: 1).

(cargo-wasi v0.1.23, Rust 1.55, macOS 15b/x86-64)

From what I could gather, compiling C deps with headers requires wasi-sdk and adding a flag to clang: --sysroot=${WASI_SDK_PATH}/share/wasi-sysroot".

Could cargo wasi support installing and configuring the SDK? Without it it's hard to build any non-trivial Rust project (about 23% of Rust crates depend on C code).

I was very surprised when running cargo install cargo-wasi that it seems to have installed a precompiled binary rather than installing from source.

I realize that cargo install does not have support for installing precompiled binaries, and I realize that you're trying to optimize for people running cargo install cargo-wasi so they don't have to wait for cargo-wasi's dependencies to compile. I'd also like to take a moment to say that this is a very impressive hack. :)

However, manually implementing support for precompiled binaries in this way has several surprising side effects:

• There's no clear indication that this is happening, other than noticing a mention of cargo-wasi-exe-x86_64-unknown-linux-musl and realizing what that implied.
• There's no obvious way to avoid this and install from source. (Any mechanism integrated into cargo would be user-controllable, such as through an explicit option to install or a separate command.)
• This installs a binary that may not match the user's desired configuration (e.g. dynamically linking against system libraries, using glibc rather than musl). (Note that I was installing for a glibc target.)
• The update checking will not be desirable for packaged versions of cargo-wasi, and would require patching to disable in that case.
• As far as I can tell, cargo-wasi-src from crates.io doesn't build; it errors out with: error[E0433]: failed to resolve: use of undeclared type or module cargo_wasi.
• cargo-wasi seems to also assume a prebuilt binary version of wasm-opt as well, rather than using a system version. (I managed to find where that's documented in the manual, but that's another behavior that wouldn't be desired for integration into a distribution and would need working around.)

Could you please provide a means of using cargo install to install cargo-wasi from source and not use precompiled binaries?

I would personally prefer if cargo install cargo-wasi-bin installed a precompiled binary that uses precompiled binaries, and cargo install cargo-wasi installed from source and expected system binaries. But I could also live with flipping those around so that cargo install cargo-wasi-src installed from source and expected system binaries, or if passing a feature flag disabled the use of precompiled binaries, as long as that was clearly documented; it wouldn't be my preference, but I can imagine that others might prefer that.

Hi All
Thanks very much for this addon it's been very useful.
I find myself typing cargo wasi clippy which of course fails and I have to revert to cargo clippy --target wasm32-wasi.
Would you be interested in a PR that enables cargo wasi clippy?

Steps to reproduce

(1) cargo new testfile
(2) cd testfile
Modify the main.rs :

use std::fs::File;
use std::os::unix::io::AsRawFd;

fn main() {
    let file = File::open("./hello.txt").expect("Can not open.");
    let file_descriptor = file.as_raw_fd();
    println!("File descriptor {}", file_descriptor);

}

And create file hello.txt.

(3) execute cargo run , it prints:

File descriptor 3

(4) However, when execute 'cargo build --target wasm32-wasi', it prints

We create it when cargo wasi is first executed which contains the contents of the actual binary. We should improve the cleanup strategy for this binary if we can.

right now it just panics for non-precompiled binaries

Maybe this has unforeseen consequences but it sure would be nice if cargo-wasi automatically installed wasmtime-cli as a cargo dependency. Right now you just get an error with a pointer to the wasmtime installation webpage, which incidentally doesn't even mention that you can just do cargo install wasmtime-cli.

It would be great to include a command to directly sign and publish the package to WAPM.

I was trying to build parts of the rustc using cargo wasi and found that librustc_expand causes wasm-opt to crash.

I filed an issue WebAssembly/binaryen#2821 but it seems that the most recent version does fine.

Any ideas on why this happens?

Hi, I have installed rust and cargo but still not be able to install the cargowasi. When I am trying to install it, it says,"could not find cargowasi in registry crates-io with version *." Help me out to install this. Thank you!

The cargo-wasi experience will depend heavily on the versions of the tools invoked (in addition to the version of cargo-wasi itself), and as mentioned in the documentation, wasm-opt in particular can sometimes be flaky. To improve the usability and reproducibility of bug reports, you may want to add an option to collect all the information needed for a good bug report, printing it directly in markdown format for convenient pasting into a github issue. You could then have a simple issue template that asks the user to run that and paste the result below their bug report.