The new rule is the following:
* `wasm_` for the standard C API,
* `wasmer_` or `wasi_` for the Wasmer non-standard C API.
For all symbols inside the `unstable` module, the renaming `wasm_` to
`wasmer_` is done without deprecations. It was clear that those API
were unstable.
For all the other symbols, symbols have been renamed to `wasmer_` but
the old symbols have been kept with deprecation warnings.
Special note: The `wasm_named_extern_t` type (and associated
functions) was in `wasi` by mistake. Its place was in the `unstable`
module. This patch also fixes that.
The `wasm_declare_vec_*` macros have been updated to support a default
prefix, or a user-defined prefix. It's now possible to write
`wasm_declare_boxed_vec!(foo);` to get all the API prefixed by `wasm_`
(as previously), or `wasm_declare_boxed_vec!(foo, wasmer);` to prefix
with `wasmer_`.
A user not using symbols from the `unstable` module will continue to
get working code, modulo some deprecations, after this patch.
So. Let's explain a dirty hack. `cbindgen` reads the code and collects
symbols. What symbols do we need? None of the one declared in
`wasm.h`, but for non-standard API, we need to collect all of
them. The problem is that `wasm_named_extern_t` is the only
non-standard type where extra symbols are generated by a macro
(`wasm_declare_boxed_vec!`). If we want those macro-generated symbols
to be collected by `cbindgen`, we need to _expand_ the crate
(i.e. running something like `rustc -- -Zunstable-options
--pretty=expanded`). Expanding code is unstable and available only on
nightly compiler. We _don't want_ to use a nightly compiler only for
that. So how can we help `cbindgen` to _see_ those symbols?
First solution: We write the C code directly in a file, which is then
included in the generated header file with the `cbindgen`
API. Problem, it's super easy to get it outdated, and it makes the
build process more complex.
Second solution: We write those symbols in a custom module, that is
just here for `cbindgen`, never used by our Rust code (otherwise it's
duplicated code), with no particular implementation.
And that's why we have the following `cbindgen_hack` module.
But this module must not be compiled by `rustc`. How to force `rustc`
to ignore a module? With conditional compilation. Because `cbindgen`
does not support conditional compilation, it will always _ignore_ the
`#[cfg]` attribute, and will always read the content of the module.
Sorry.
This patch updates how `wasm_$name_vec_new_uninitialized` creates the
vector. The vector is now fully allocated with `null` pointer for each
item, instead of having an empty vector with the initial capacity set
to `length`. That way, we are sure the vector is zeroed correctly.
In case of a boxed vector, `wasm_$name_vec_delete` now checks that the
vec is correctly initialized (by checking the first item only) because
transmuting `Vec<*mut T>` to `Vec<Box<T>>`, otherwise it will crash.
This patch does several things:
1. It applies our Rust patterns for C API by replacing the raw pointer
by `Option<Box<T>>`,
2. It allows `wasm_$name_vec_delete` to handle null pointer,
3. Because it takes ownership of the `wasm_$name_vec_t`, the pointer
is correctly dropped (which fix the memory leak).
We have known memory leaks with extern types. The idea is to change
the code so that extern types can hold/own data. This patch does that.
A `wasm_externtype_t` holds a `WasmExternType` enum. This enum owns
sibling types such as `WasmFunctionType`, `WasmGlobalType`,
`WasmTableType` and `WasmMemoryType`. It is those structures that ows
the extern types data, like `params` and `results` as
`wasm_valtype_vec_t` for `WasmFunctionType`. That way, for example,
`wasm_functype_t` can return a pointer to these vec which it owns.
A `wasm_externtype_t` continues to be transmuted to `wasm_functype_t`
etc. Nothing changes on that side.
