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.
2364: feat: Rename `wasmer-engine-object-file` to `wasmer-engine-staticlib`. r=Hywan a=Hywan
# Description
This PR renames the `wasmer-engine-object-file` crate into `wasmer-engine-staticlib`. We believe it conveys a better meaning of what it does. This PR is similar to its siblings, #2340 and #2356.
Co-authored-by: Ivan Enderlin <ivan@mnt.io>
2161: feat(llvm): Make NaN canonicalization configurable r=jubianchi a=jubianchi
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
# Review
- [ ] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: jubianchi <julien@wasmer.io>
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
2092: Add reference types r=MarkMcCaskey a=MarkMcCaskey
This PR adds support for reference types in the API and in our compilers.
Wasm C API support should probably be a separate PR after this one lands.
# Status
- [x] spectests passing
- [x] compiler-cranelift
- [x] compiler-singlepass
- [x] compiler-llvm
- [x] Tables work with references
- [x] Globals work with references
- [x] FuncRefs for local functions
- [x] FuncRefs for imported functions
- [ ] ExternRefs
- [x] Work as values in Wasm
- [x] Tests showing it being passed to/from host functions
- [x] Top level API for interacting with ExternRefs
- [ ] Reference counting works as expected, fully tested
- [ ] ~~Wasm C API support (should be done on a PR branched off of this branch)~~ (not going to do this in this PR)
- [x] ~Host info (see Wasm C API and wasmer Rust API)~ (not going to do this in this PR. The value of this feature seems low and the cost seems high; unclear if we even want it at the Rust API level)
# Review
<!--
## High priority things to review
- [ ] ExternRef reference counting behavior (blocked on implementation, but feedback of what's there is welcome)
- [ ] That we're counting in all the places that matter (we're not yet)
- [ ] The manual `ref_clone` and `ref_drop` in order to make putting `VMExternRef` in a `union` work.
- [ ] FuncRef storage
- [ ] Distinction between imported and local FuncRef
- [x] Duplicating data rather than storing it inline in the dynamic part of the `Instance`
- [ ] Changes to `wasmer_types::Value`
- [ ] ExternRef
- [ ] FuncRef / ValueEnumType
- [ ] Passing a store via `&dyn Any` to some methods and the garbage placeholder values we pass when we don't have a store.
- [ ] The location of the `Option` for `FuncRef`
- [x] Implementation of new instructions (bug check)
- [ ] API changes
- [ ] Changes in the wasmer crate
- [ ] Changes in the core traits for example `vm::Table`
- [ ] Use of `repr(C)` union `vm::table::TableElement` in `extern "C"` / FFI contexts. I just assumed `repr(C)` on a union of all usize sized things would just be passed like a usize.
- [ ] WAST test runner updates
## Lower priority things to review
These are things that I think we can fix with follow-up PRs. Let me know if you think anything on this list is too important to fix later.
- [ ] Implementation of new instructions (calling functions rather than doing it inline)
- [ ] Use of libcalls distinguishing between imported vs local in cases where it probably doesn't matter
-->
# misc
- [ ] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Co-authored-by: Nick Lewycky <nick@wasmer.io>
2210: Fix memory leak in C API in some uses of `wasm_name_t` r=MarkMcCaskey a=MarkMcCaskey
This PR fixes a bug relating to `wasm_importtype_t` leaking memory, particularly on the path where `String` is converted into `wasm_name_t`. It fixes this by introducing a new type, `owned_wasm_name_t`, which is identical to `wasm_name_t` but has RAII and calls the destructor if it goes out of scope.
I'm not confident that the use of `owned_wasm_name_t` on the FFI boundary is correct though, we'll have to thoroughly review that before shipping this PR.
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Mark McCaskey <mark@wasmer.io>
Converting from `String` means that the type should auto-destruct to make sure
we free that memory. The memory can still be freed manually though. We need
thorough review for the changes were the `owned_wasm_name_t` is coming from user
code. Is it guaranteed that `wasm_name_t` coming from the user always uses a
host allocation? I don't think so, in which case, we have to find some way to
handle transfer of ownership where it's unclear who owns it...
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>
