1042: Make regression test work in release builds too. r=nlewycky a=nlewycky
Fix this regression test to detect the bug it was looking for in release builds too.
This bug triggered an assertion failure in debug, and by examining the pre-opt IR, we can check for the bug in release mode too.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
709: new feature flag: `deterministic` r=MarkMcCaskey a=YaronWittenstein
The motivation for the PR is for introducing a new feature flag called `deterministic`.
When `deterministic` will be enabled (turned-off by default) it'll guarantee deterministic
execution of wasm programs across different hardware/circumstances.
This is critical for Blockchain projects that require execution to be deterministic
in order to reach a consensus of the state transition of each smart-contract transaction.
Co-authored-by: Yaron Wittenstein <yaron.wittenstein@gmail.com>
Co-authored-by: Yaron Wittenstein <yaronwittenstein@users.noreply.github.com>
Co-authored-by: Mark McCaskey <5770194+markmccaskey@users.noreply.github.com>
Co-authored-by: Mark McCaskey <mark@wasmer.io>
1033: Improve default compiler story for wasmer cli r=MarkMcCaskey a=MarkMcCaskey
This PR needs the following to be ready to ship:
- [x] Verified make commands are still fine
- [x] Verified this doesn't do anything bad in CI
This PR adds:
- compile_error if no backend is specified in wasmer.rs
- readds clif as the default
- improves the error message saying "specified backend not found" to include the name of the backend that it couldn't find
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Co-authored-by: Mark McCaskey <5770194+markmccaskey@users.noreply.github.com>
1036: Add experimental invoke support to WASI in wasmer cli r=MarkMcCaskey a=MarkMcCaskey
Resolves#1024
This PR also does a bit of code clean up
# Review
- [ ] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Co-authored-by: Mark McCaskey <5770194+markmccaskey@users.noreply.github.com>
1030: feat(runtime-c-api) Ability to generate `ImportObject` for a specific WASI version r=Hywan a=Hywan
❗️⚠️ Contains #1028, must be merged before this one.
This patch introduces 2 new functions:
* `wasmer_wasi_generate_import_object_for_version` and
* `wasmer_wasi_get_version`.
It mimics the current API provided by `wasmer_wasi`, nothing fancy
here. It's just a regular port to C/C++.
Because `wasmer_wasi::get_wasi_version` returns an option, and in
order to simplify the C/C++ API, `wasmer_wasi_get_version` can return
`Version::Unknown` in case of an error. It's up to the user to check
the version is valid (i.e. not unknown).
To see only the changes provided by this PR (excluding #1028), check https://github.com/Hywan/wasmer/compare/fix-wasi-get-version...feat-runtime-c-api-wasi-version.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
1028: feat(wasi) Introduce strict/non-strict modes for `get_wasi_version` r=Hywan a=Hywan
Sequel of https://github.com/wasmerio/wasmer/pull/957.
If a module has multiple import namespaces, `get_wasi_version` is
broken because it assumes a module must only have a single namespace.
This patch updates `get_wasi_version` to introduce a `strict` flag:
* In strict mode, the previous behavior applies; only one namespace is expected to be found, and this namespace must be a WASI namespace to detect the version,
* In non-strict mode, at least one WASI namespace must be declared, and the first one is used to detect the version if any.
The non-strict mode is slower because it compares namespace strings.
2 new private constants have been declared: `SNAPSHOT0_NAMESPACE` and `SNAPSHOT1_NAMESPACE` to avoid repetition and bugs.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
1040: Add the ability to pass backend specific options through CompilerConfig. r=nlewycky a=nlewycky
# Description
Add the ability to pass backend specific options through CompilerConfig.
Use this to replace wasmer_llvm_backend::GLOBAL_OPTIONS.
This adds a new item to CompilerConfig which can be any struct defined by a backend for backend specific configuration options. So far, we only implement the options that were previously in GLOBAL_OPTIONS, these move to wasmer.rs. The plan is to use these same callbacks for testing in llvm-backend-tests.
# Review
- [ ] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Nick Lewycky <nick@wasmer.io>
When the version has type `Version`, we expect the user to give a
valid `Version` variant. Since the `Version` is basically a `uint8_t`,
the user is able to pass everything she wants, which can create an
undefined behavior on the Rust side.
To avoid such situation, the version has now type `c_uchar` (`unsigned
char` or `uint8_t` on C side —on most platforms). Then the `From`
trait is implemented on `Version`. In case the value is unbound,
`Version::Unknown` is returned.
This patch updates `test-wasi-import-object` to test the new
`wasmer_wasi_get_version` &
`wasmer_wasi_generate_import_object_for_version` functions, and the
new `Version` type.
This patch introduces 2 new functions:
* `wasmer_wasi_generate_import_object_for_version` and
* `wasmer_wasi_get_version`.
It mimics the current API provided by `wasmer_wasi`, nothing fancy
here. It's just a regular port to C/C++.
Because `wasmer_wasi::get_wasi_version` returns an option, and in
order to simplify the C/C++ API, `wasmer_wasi_get_version` can return
`Version::Unknown` in case of an error. It's up to the user to check
the version is valid (i.e. not unknown).
1029: feat(wasi) Add the “floating” `WasiVersion::Latest` version. r=Hywan a=Hywan
In addition to `Snapshot0` and `Snapshot1`, I believe it is an
interesting API to provide the `Latest` version, so that the user can
write:
```rust
generate_import_object_for_version(WasiVersion::Latest, …);
```
This is a way to ensure that modules will run only if they come with
the latest WASI version (in case of security issues for instance), by
just updating the runtime.
Note that it can be dangerous if not used carefully, but we assume the
user knows what it does by sticking on a specific “floating” version.
Also note that the `Latest` version is never returned by any API. It
is provided only by the user.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
In strict mode, `get_wasi_version` uses the previous behavior, i.e. it
checks that there is only one namespace for all imports, and that this
namespace is a WASI namespace (and uses it to find the WASI version).
In non-strict mode, `get_wasi_version` checks that at least one WASI
namespace exists (and uses it to find the WASI version).
By default, `is_wasi_module` uses the non-strict mode.
