The `returns_len` argument type of `wasmer_export_func_returns_params`
must be `uint32_t` to match the `wasmer_export_func_returns_arity` results,
so that casts are not required.
The `params_len` argument type of `wasmer_export_func_params_arity`
must be `uint32_t` to match the `wasmer_export_func_*_arity` results,
so that casts are not required.
The `wasmer_export_func_params_arity` and
`wasmer_export_func_returns_arity` functions store the arity in a
`uint32_t`. The `wasmer_instance_call` expects `c_int`. There is a
type mismatch here. It's not annoying in C or C++, but in some other
languages that have bindings to C/C++, it can imply useless casting.
This patch changes `wasmer_instance_call` to expect `uint32_t` for
`params_len` and `results_len` to match the
`wasmer_export_func_*_arity` functions.
It's safer to check the buffer size is large enough to hold the error
message before creating the slice from raw parts.
Also, this patch remove the need for `last_error`, simplifying the
code a little bit. The `length` variable is casted to `usize` once.
`wasmer-runtime` has a `debug` and a `llvm` features. Let's mirror
them in `wasmer-runtime-c-api` so that the user can, for instance,
compile with the LLVM backend.
This function is required to transform a `wasmer_byte_array` into a
`wasmer_serialized_module_t`. This is the complementary function of
`wasmer_serialized_module_bytes`.
The `wasmer_module_serialize` function now computes a
`wasmer_serialized_module_t` value. The `wasmer_module_deserialize`
function takes this value as an input. Same for
`wasmer_serialized_module_destroy`.
The new function `wasmer_serialized_module_bytes` allows to read the
bytes inside the `wasmer_serialized_mdule_t` structure.
This test suite compiles a module, then serializes it, deserializes
it, and continues by creating an instance and calling a function on
it. It allows to test the entire roundtrip.
This patch updates the first argument of `wasmer_validate` from `*mut
uint8_t` to `*const uint8_t`. Indeed, the
`wasmer-runtime-core::validate` function doesn't expect a mutable
slice, so it's not required to expect a mutable array from C.
Also, it's likely for the Wasm bytes to be stored in the
`wasmer_byte_array` structure. The first field `bytes` is defined as
`*const uint8_t`. So this patch avoids a cast when writing a C++
program.
This patch adds 2 functions for the runtime C API, respectively
`wasmer_instance_context_data_set` and
`wasmer_instance_context_data_get`. The goal is to modify the
`vm::Ctx.data` field in the `runtime-core` library.
This is required to pass dynamic data to imported functions for
instance.
`imports` contains `func_import`, `global_import`, `memory_import` and
`table_import`, so 4 items. This patch updates the length of `imports`
when calling the `wasmer_instantiate` function.
This patch ensures that all our examples and tests do not generate
warnings. In C, it can be catastrophic sometimes…
Also, be sure that the `cmake` command doesn't emit any warnings too.
When compiling `wasmer-runtime-c-api` as a dependency of another
crate, `rustc` emits this warning:
```
warning: The package `wasmer_runtime_c_api` provides no linkable
target. The compiler might raise an error while compiling
`foo`. Consider adding 'dylib' or 'rlib' to key `crate-type` in
`wasmer_runtime_c_api`'s Cargo.toml. This warning might turn into a
hard error in the future.
```
To solve this issue, the `rlib` type has been added to the
`crate-type` list.
This patch removes the `WASM_EMSCRIPTEN_GENERATE_C_API_HEADERS`
flag. Consequently, the C header files will be generated for each
build.
The `generate-c-api-headers` feature is also removed, since it becomes useless.
This patch changes the directory where the C header files are
generated, from `CARGO_MANIFEST_DIR` to `OUT_DIR`. The goal is: When
`wasm-runtime-c-api` is used as a dependency of another Rust project,
then the C header files are accessible in the `target/` directory
(i.e. the `OUT_DIR`).
Also, since `rustc` has a `--out-dir` directory, it increases the
flexibility of this approach: The user can generate the C header files
where she wants.
When requiring `wasmer-runtime-c-api`, I get the following conflicts:
```
error: failed to select a version for `serde_derive`.
... required by package `cbindgen v0.7.1`
... which is depended on by `wasmer-runtime-c-api v0.2.1`
... which is depended on by `foo v0.1.0 (/private/tmp/foo)`
versions that meet the requirements `= 1.0.58` are: 1.0.58
all possible versions conflict with previously selected packages.
previously selected package `serde_derive v1.0.89`
... which is depended on by `wasmer-runtime-core v0.2.1`
... which is depended on by `wasmer-runtime-c-api v0.2.1`
... which is depended on by `foo v0.1.0 (/private/tmp/foo)`
failed to select a version for `serde_derive` which could resolve this conflict
```
This issue resolves by updating `cbindgen` to 0.8.
This patch cleans several warnings where mutable bindings are declared
but used only as immutable bindings.
It's a little bit opinionated patch. I think it's interesting to use
`const` pointers as much as possible.
This patch removes `unsafe { … }` blocks inside `unsafe` functions.
This patch also removes some warnings about camel case. All structures
with a C representation are automatically not mangle, and allow non
camel case.
