Breaking changes between 2.0.0 and 2.1.1

[Michael-F-Bryan]

It looks like the return type of WasmPtr::<T, Array>::deref() was changed from &[Cell<u8>] to Vec<WasmCell<u8>> between version 2.0.0 and 2.1.1 of the wasmer crate without bumping the major version number.

Before:

wasmer/lib/api/src/ptr.rs

Lines 146 to 154 in 327192c

	impl<T: Copy + ValueType> WasmPtr<T, Array> {
	/// Dereference the `WasmPtr` getting access to a `&[Cell<T>]` allowing for
	/// reading and mutating of the inner values.
	///
	/// This method is unsound if used with unsynchronized shared memory.
	/// If you're unsure what that means, it likely does not apply to you.
	/// This invariant will be enforced in the future.
	#[inline]
	pub fn deref(self, memory: &Memory, index: u32, length: u32) -> Option<&[Cell<T>]> {

After:

wasmer/lib/api/src/sys/ptr.rs

Lines 126 to 139 in 9f92666

	impl<T: Copy + ValueType> WasmPtr<T, Array> {
	/// Dereference the `WasmPtr` getting access to a `&[Cell<T>]` allowing for
	/// reading and mutating of the inner values.
	///
	/// This method is unsound if used with unsynchronized shared memory.
	/// If you're unsure what that means, it likely does not apply to you.
	/// This invariant will be enforced in the future.
	#[inline]
	pub fn deref<'a>(
	self,
	memory: &'a Memory,
	index: u32,
	length: u32,
	) -> Option<Vec<WasmCell<'a, T>>> {

---

I was initally unable to reproduce this issue because there seem to be breaking changes in other parts of the API. That meant when I pinned wasmer to 2.0.0 it tried to use version 2.1.1 of wasmer-engine and friends, which triggers other compile errors.

Steps to reproduce:

$ cargo new --lib asdf
     Created library `asdf` package
$ cd asdf
$ cargo add wasmer@=2.0.0
    Updating 'https://github.com/rust-lang/crates.io-index' index
      Adding wasmer v=2.0.0 to dependencies
$ cat src/lib.rs
cat src/lib.rs
use std::cell::Cell;
use wasmer::{Array, Memory, ValueType, WasmPtr};

fn call_deref<T: ValueType>(ptr: WasmPtr<T, Array>, memory: &Memory) -> Option<(&[Cell<T>])> {
    ptr.deref(memory, 0, 0)
}
$ cargo check
    Updating crates.io index
   Compiling proc-macro2 v1.0.36
   Compiling unicode-xid v0.2.2
   ...
    Checking rkyv v0.7.29
    Checking wasmer-types v2.1.1
    Checking cranelift-codegen v0.76.0
    Checking backtrace v0.3.63
    Checking wasmer-vm v2.1.1
    Checking wasmer-compiler v2.1.1
    Checking wasmer-engine v2.1.1
    Checking wasmer-object v2.1.1
    Checking wasmer-engine-dylib v2.1.1
    Checking wasmer-engine-universal v2.1.1
    Checking cranelift-frontend v0.76.0
    Checking wasmer-compiler-cranelift v2.1.1
    Checking wasmer v2.0.0
error[E0277]: the trait bound `u64: From<usize>` is not satisfied
   --> /home/consulting/.cargo/registry/src/github.com-1ecc6299db9ec823/wasmer-2.0.0/src/externals/memory.rs:134:28
    |
134 |         def.current_length.into()
    |                            ^^^^ the trait `From<usize>` is not implemented for `u64`
    |
    = help: the following implementations were found:
              <u64 as From<&'a rend::BigEndian<u64>>>
              <u64 as From<&'a rend::LittleEndian<u64>>>
              <u64 as From<&'a rend::NativeEndian<u64>>>
              <u64 as From<NonZeroU64>>
            and 8 others
    = note: required because of the requirements on the impl of `Into<u64>` for `usize`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `wasmer` due to previous error

Git bisect says the breaking change was introduced around 5ede1ac (#2442). Depending on your versioning policy, you may want to yank 2.0.0 or yank 2.1.1 and re-release it as 3.0.0.

[syrusakbary]

Thanks for reporting @Michael-F-Bryan.

This breaking change is affecting 2.1 and 2.1.1.
We did the changes because they were required for wasmer-js (you can't access the Wasm memory directly in js environments, and thus an API that work for both the browser and outside will need a uniform and safe approach).
Because of the breaking change was not on the broader wasmer API but rather on just two functions we decided to not go with wasmer 3.0 (we are planning that for bigger API changes).

We are thinking on publishing 2.0.1 and pin-point the exact versions for wasmer-related crates so that way you can depend on wasmer = "2.0.1" safely.
Thanks to this issue, in future versions of wasmer crates we will depend on exact versions for the wasmer crates so we assure this doesn't happen again and people can roll-back safely.

We apologize for any inconvenience the breaking change caused on your side.

[Michael-F-Bryan]

Thanks @syrusakbary! Luckily, we were able to pin to a specific version and had already committed our Cargo.lock so there were no issues on our end.

#2759 pinned internal crate versions, so this issue should now be resolved.