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>
1685: feat(c-api) Implement `wasm_exporttype_delete` r=Hywan a=Hywan
This PR implements the destructor for `wasm_exporttype_t`.
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
`wasm_$name_vec_t.into_slice` returns `None` if the vec is empty. So
an empty vec of `wasm_extern_t` given to `wasm_func_call` was raising
an error. This patch fixes this.
When building a `wasm_memorytype_t` with `wasm_memorytype_new`, we
pass a `wasm_limits_t`, where `min` and `max` represent `Pages`. This
semantics is set by `wasm_memorytype_new` itself where `min` and `max`
from `wasm_limits_t` are used to compute `Pages`, which are then passed
to `MemoryType`.
Then, in `wasm_memorytype_limits`, we expect to get the same
`wasm_limits_t` given to `wasm_memorytype_new`. But it's not!
The same `MemoryType` is read, good. The `minimum` and `maximum`
fields are `Pages`, good. Then, we compute the `min` and `max` values
for the resulting `wasm_limits_t`, which receive `Page.bytes().0`, not
good! We don't want the number of bytes, but the number of pages.
This patch fixes that.
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.
`wasm_exporttype_t` has 2 fields: `name` and `extern_type`. Both are
of kind `NonNull`. When `wasm_exporttype_t` is dropped, nor `name` nor
`extern_type` are going to be dropped.
To avoid leaking data, this patch adds a new field: `owns_fields`:
* When `wasm_exporttype_t` is built from `wasm_exportype_new`, this
field is set to `false` because `name` and `extern_type` are
received by pointer, and its the responsibility of the caller to
free them,
* When `wasm_exporttype_t` is built from the `From<&ExportType>`
implementation, _we_ create `name` and `extern_type` to then leak
them. In this case, it is safe to reconstruct proper `Box`es to
finally drop them.
`wasm_store_t` is now a proper struct (rather than an opaque type) of
kind:
```rs
struct wasm_store_t {
inner: Store
}
```
The rest of the patch updates the code accordingly.
