cargo update to pick up latest inkwell branch commit.
Add lifetime annotations to Module which now takes a lifetime, and more lifetime annotations across intrinsics.rs.
Add <'ctx> to missing places in CtxType and Intrinsics. Remove it from reference bindings.
Use ManuallyDrop to ensure that context's members are dropped before the Context.
Co-authored-by: Mark McCaskey <mark@wasmer.io>
1020: Turn a few more assert!s that should never fire into debug_assert!s. r=nlewycky a=nlewycky
These are here to protect against errors when refactoring more than anything else.
Co-authored-by: Nick Lewycky <nick@wasmer.io>
1006: fix 1005 panic sub overflow r=MarkMcCaskey a=pventuzelo
# Description
Fix issue https://github.com/wasmerio/wasmer/issues/1005
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Patrick Ventuzelo <ventuzelo.patrick@gmail.com>
Co-authored-by: Patrick Ventuzelo <9038181+pventuzelo@users.noreply.github.com>
Fix a bug in Operator::Select and add a comment to explain the intention.
Use derived default for ExtraInfo.
Make ExtraInfo associated functions const.
Turn two asserts into debug_asserts.
Unfortunately, this is quite buggy. For something as simple as F32Sub, to combine two ExtraInfos, we want to add a new pending_f32_nan(), unless both of the inputs are arithmetic_f32(). In this commit, we incorrectly calculate that we don't need a pending_f32_nan if either one of the inputs was arithmetic_f32().
It seemed like a good idea at the time, but in practice we discard the extra info all or almost all of the time.
This also introduces a new bug. In an operation like multiply, it's valid to multiply two values, one with a pending NaN and one without. As written, in the SIMD case (because of the two kinds of pending in play), we assert.
Instead of ensuring outputs are arithmetic NaNs on every function, we tag them as pending such a check, so that a sequence of computation can have a single canonicalization step at the end.
There's an extra wriggle for SIMD. The Wasm type system only indicates them as V128, so it's possible that we might do computations as F32x4Add, I8x16Add, F64x2Add in a row with no other computations in between. Thus, most SIMD functions apply pending canonicalizations to their inputs, even integer SIMD operations.
