Until this patch, our C API comes in 2 flavors: `deprecated` and
`wasm_c_api`. With the coming 2.x version of Wasmer, we would like to
remove the `deprecated` API, and keep the `wasm_c_api` only.
This patch removes the `deprecated` API from the `wasmer-c-api`
crate. It also cleans up the `Makefile` and the documentation
system. Previously, the documentation for the `deprecated` API was
relying on Doxygen, which was one new dependency the user had to
install. For the `wasm_c_api`, it relies on `rustdoc`, which is way
better because all examples are run and tested as part of our test
suite.
This clean up also removes the need to deal with `system-libffi` both
in the crate itself and in the `Makefile`, which was an edge case for
macOS on aarch64, and a needle in the foot for some of our users.
Finally, the `build.rs` is now simplified because we no longer need to
exclude symbols from one header to another. It also means that we only
provide the `wasmer_wasm.h` header file now; the `wasmer.h` and
`wasmer.hh` headers are removed.
compiler-llvm now uses the experimental.constrained intrinsics to ensure
correct behavior on FP operations when full-canonicalization is
disabled.
This patch requires TheDan64/inkwell#247
2003: chore: Build Wasmer on musl r=jubianchi a=jubianchi
This patch adds a specific build for musl. Currently, it will only support JIT engine.
I also changes the workflow definition a bit so we don't depend on the OS name but rather on the environment ID which is our convention.
Closes#1482Closes#1766
<!--
Prior to submitting a PR, review the CONTRIBUTING.md document for recommendations on how to test:
https://github.com/wasmerio/wasmer/blob/master/CONTRIBUTING.md#pull-requests
-->
# Description
<!--
Provide details regarding the change including motivation,
links to related issues, and the context of the PR.
-->
# Review
- [ ] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: jubianchi <julien@wasmer.io>
This patch removes the following type and functions:
* `wasmer_metering_points_t`,
* `wasmer_metering_points_delete`,
* `wasmer_metering_points_is_exhausted`,
* `wasmer_metering_points_t`,
* `wasmer_metering_points_unwrap_or`.
Now, `wasmer_metering_get_remaining_points` returns the number of
points, with zero to represent `MeteringPoints::Exhausted`.
The API is greatly simplified as there is no longer need to allocate
and deallocate a `wasmer_metering_points_t` type.
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.
Remove the `build.rs` hack to add helper functions that are used only
in our tests. Now the tests can use the `tests/wasmer_wasm.h` file,
which simplifies the test workflow: No need to hack the build script
or anything if we want to add a helper function.
It's very similar to `wasm_name_new_from_string` but for
`wasm_byte_vec_t`. It does not make sense to get that in the standard,
but it's very useful when writing tests.
