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>`.
2071: feat(c-api) Rename the `wasmer` module to `unstable` r=Hywan a=Hywan
# Description
This patch is the first step to prepare more unstable API (like cross-compilation etc.). Nothing changes for the moment from the user perspective, it's not a breaking change. It's just a reorganisation of the code, and better documentation. Basically the `wasmer_c_api::wasm_c_api::wasmer` module has been renamed `unstable`, so that it's super clear :-).
# Review
- [ ] ~Add a short description of the the change to the CHANGELOG.md file~ not necessary
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
We use `VecDeque::drain` to read the captured stream, zipped with the
given buffer. We could expect that only the yielded items from the
`drain` will be removed, but actually no. Reading [the
documentation](https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.drain):
> Note 1: The element `range` is removed even if the iterator is not
> consumed until the end.
So by using a range like `..` will drain the entire captured stream,
whatever we read from it. Said differently, if the given buffer length
is smaller than the captured stream, the first read will drain the
entire captured stream.
This patch fixes the problem by specifying a better range:
`..min(inner_buffer.len(), oc.buffer.len())`.
With this new range, it's actually useless to increment
`num_bytes_written`, we already know ahead of time the amount of bytes
we are going to read. Consequently, the patch simplifies this code a
little bit more.
On Windows, using a `u32` representation for `wasi_version_t` fails if
a C++ compiler is used to treat a C program. So we change our strategy
here. We use a C representation to be FFI-safe, and the
`INVALID_VERSION` variant is now set to -1 instead of `u32::MAX`.
This patch also adds unit tests for `wasi_get_wasi_version` so that we
are sure of the behavior of this `type` on all platforms.
2054: Add `wasm_config_delete` to the Wasm C API r=MarkMcCaskey a=MarkMcCaskey
Fixes 1 missing import reported in #2052
This function is relatively new to the Wasm C API and its implementation is trivial
Co-authored-by: Mark McCaskey <mark@wasmer.io>
First, let's no longer derive from `Default` for `wasi_config_t`. By
default, we want to inherit `stdin`, `stdout` and `stderr`. The
default for `bool` is `false`; we want `true` here.
Second, let's update `wasi_config_new` to correctly set `inherit_*`
fields to `true`.
Third, lets' create `wasi_config_capture_*` functions. By default,
`std*` are inherited, so we need functions to capture them. That's the
new feature this patch introduces. The `wasi_config_inherit_*`
functions are kept for the sake of backward compatibility. Ideally, we
would want an API like `wasi_config_capture_*(capture: bool)`, but it
would duplicate the API somehow.
Fourth, let's fix `wasi_env_new`. We want to capture `stdout` and
`stderr` if and only if the `inherit_*` fields are set to
`false`. There was bug here. That's why everything was working
correctly by the way: `bool::default()` is `false`, and we have this
inverted condition here, so everything was working as expected because
of a double error. The only bug was that it wasn't possible to capture
`std*` before.
