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>
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.
