Our implementation of `wasm_func_call` was correct for C code as
follows:
```c
wasm_val_vec_t arguments = WASM_EMPTY_VEC;
wasm_val_vec_t results = WASM_EMPTY_VEC;
wasm_func_call(func, &arguments, &results);
```
However, for a C code such as:
```c
wasm_val_t vals[1];
wasm_val_vec_t arguments = WASM_EMPTY_VEC;
wasm_val_vec_t results = WASM_ARRAY_VEC(vals);
wasm_func_call(func, &arguments, &results);
```
the `vals` array were kept empty/unchanged. Why?
Because `wasm_func_call` was replacing the value of `results` by a new
`wasm_val_vec_t`. It is correct when `results` is an empty vector, but
it is incorrect when `results` is initialized with empty values.
This patch tries to detect this pattern: If `results.data` is `null`,
it means the vector is empty/uninitialized, and we can set a new
`wasm_val_vec_t`, otherwise it means the vector is initialized with
empty values, and we need to update each item individually.
1765: doc(c-api) Update documentation. r=Hywan a=Hywan
# Description
This patch adds documentation to the `engine.rs` module.
# Review
- [ ] ~Add a short description of the the change to the CHANGELOG.md file~ not necessary
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
The `wasm_trap_t**` argument of `wasm_instance_new` represents an
output pointer to a `wasm_trap_t*`, not an array of
`wasm_trap_t*`. This patch updates the code accordingly.
When running `Instance::new`, it can error with an
`InstantiationError`. There is 2 scenarii:
1. Either it's a `InstantiationError::Link`. In this case, the
`wasm_instance_new` function must return `NULL` and register the
error in the Wasmer error registry.
2. Either it's a `InstantiationError::Start`. In this case, the
`wasm_instance_new` function must return `NULL` and the error must be
converted into a `wasm_trap_t`, which is stored in the `wasm_trap_t**`
array. This array is initialized by `wasm_instance_new` itself.
1751: feat(c-api) Correctly implement “trap” in `wasm_func_new*` r=Hywan a=Hywan
The implementation of “trap” in `wasm_func_new` was “incorrect”. It's
more idiomatic to return a `RuntimeError` than raising it in this
case, so that we don't duplicate locations where runtime errors are
raised.
The implementation of “trap” in `wasm_func_new_with_env` was
missing. This patch implements a similar strategy than the sibling
function.
Fixes https://github.com/wasmerio/wasmer/issues/1744.
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
The implementation of “trap” in `wasm_func_new` was “incorrect”. It's
more idiomatic to return a `RuntimeError` than raising it in this
case, so that we don't duplicate locations where runtime errors are
raised.
The implementation of “trap” in `wasm_func_new_with_env` was
missing. This patch implements a similar strategy than the sibling
function.
1725: feat(c-api) Implement `wasm_func_type` r=MarkMcCaskey a=Hywan
This patch creates a `wasm_functype_t::new` constructor, that is used
by the new `wasm_func_type` function, and the existing
`wasm_functype_new_inner` function.
Note: `wasm_func_type` is defined in 193d7c8ce1/lib/c-api/tests/wasm_c_api/wasm-c-api/include/wasm.h (L421).
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
This patch creates a `wasm_functype_t::new` constructor, that is used
by the new `wasm_func_type` function, and the existing
`wasm_functype_new_inner` function.
1715: fix(c-api) Register errors from `wasm_module_serialize` r=Hywan a=Hywan
This patch updates `wasm_module_serialize` to register errors with`update_last_error` if any.
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
1693: Add `wasmer create-exe` r=MarkMcCaskey a=MarkMcCaskey
This adds the `wasmer create-exe` subcommand. This subcommand is a combination of `wasmer compile --object-file` and linking that compiled Wasm with a main function and libwasmer. Put more plainly: it lets us transform Wasm modules into native executables in one step.
In order for this to work we need:
- [x] Ship wasm.h with Wasmer or use different mechanism to find it
- [x] Ship wasmer_wasm.h with Wasmer
- [x] Requires up to date libwasmer... had to build one and copy it over, may fail in CI because of this... will be fixed with next release though
- [x] More gracefully handle wasmer installed without WASMER_DIR, etc (even if just error messages, should be tested)
- [x] Add tests
# 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>
1689: feat(c-api) Use `Option<NonNull<wasm_valtype_t>>` in `wasm_valtype_kind` r=syrusakbary a=Hywan
A more Rust-FFI idiomatic way to handle null pointer.
Note: In `wasm_valtype_kind`, it's tricky to handle the error because
we _must_ return a `wasm_valtype_kind` value. For the moment, it
continues to panic, which is probably the best tradeoff.
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
