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.
We said that `wasi_get_imports` was taking ownership of
`wasi_env_t`. It wasn't. In 9e63ba9a25,
we have fixed this. But it creates another bug when `wasi_env_t` is
used _after_ for example when calling `wasi_env_read_stdout`.
So this patch reverts the bug fix. And we will discuss about how to
fix that later.
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.
2083: doc(c-api) Remove inline documentation in `wasmer_wasm.h`, clarification about stability… r=Hywan a=Hywan
# Description
As suggested in https://github.com/wasmerio/wasmer/pull/2053#discussion_r566692725, this PR removes the automatically generated documentation when building `wasmer_wasm.h`.
It also clarifies our position regarding stability, and add a section about the documentation.
This PR takes also the opportunity to mark `wasi_env_set_(instance|memory)` as deprecated functions.
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
A function environment `WrapperEnv` can be cloned. In case the
original and the cloned environments are being dropped, the
`self.finalizer` function —if any— is called twice. That's a bug. It
must be called only once.
This patch updates the code to apply the finalizer only once by taking
it —if any— the first time it's called.
In `wasi_get_imports` and `wasi_get_unordered_imports`, we said the
ownership of `wasi_env_t` was taken by the function, but it wasn't the
case. This patch changes the type from `&wasi_env_t` to
`Box<wasi_env_t>` to take ownership of it.
The rest of the patch updates the documentation, and improves null
protections with `Option<T>`.
