Bump wasmex from 0.7.0 to 0.8.2

[dependabot]

Bumps wasmex from 0.7.0 to 0.8.2.

Release notes

Sourced from wasmex's releases.

v0.8.2

Added

• list aarch64-unknown-linux-musl in rustler targets, so we actually include it in our releases

v0.8.1

This release makes running user-provided WASM binaries a whole bunch safter by providing restrictions on memory and CPU usage.

Have a look at Wasmex.StoreLimits for memory restrictions and Wasmer.EngineConfig on how to limit fuel (CPU usage quota).

The new Wasmex.EngineConfig allows better reporting when WASM execution fails -- setting wasm_backtrace_details enables error backtraces to include file and line number information if that debug info is available in the running WASM file.

A Wasmex.EngineConfig is used to create a Wasmex.Engine, which holds configuration for a Wasmex.Store. It allows us to selectively enable/disable more WASM option (e.g. enabling certain WASM proposals). Today, a Wasmex.Engine already gives us a faster way to precompile modules without the need to instantiate them through Wasmex.Engine.precompile_module/2.

Added

• Added precompiled binary for aarch64-unknown-linux-musl
• Added support for setting store limits. This allows users to limit memory usage, instance creation, table sizes and more. See Wasmex.StoreLimits for details.
• Added support for metering/fuel_consumption. This allows users to limit CPU usage. A Wasmex.Store can be given fuel, where each WASM instruction of a running WASM binary uses a certain amount of fuel. If no fuel remains, execution stops. See Wasmex.EngineConfig for details.
• Added Wasmex.EngineConfig as a place for more complex WASM settings. With this release an engine can be configured to provide more detailed backtraces on errors during WASM execution by setting the wasm_backtrace_details flag.
• Added Wasmex.Engine.precompile_module/2 which allows module precompilation from a .wat or .wasm binary without the need to instantiate said module. A precompiled module can be hydrated with Module.unsafe_deserialize/2.
• Added Wasmex.module/1 and Wasmex.store/1 to access the module and store of a running Wasmex GenServer process.
• Added option to Wasmex.EngineConfig to configure the cranelift_opt_level (:none, :speed, :speed_and_size) allowing users to trade compilation time against execution speed

Changed

• mix.exs now also requires at least Elixir 1.12
• Module.unsafe_deserialize/2 now accepts a Wasmex.Engine in addition to the serialized module binary. It's best to hydrate a module using the same engine config used to serialize or precompile it. It has no harsh consequences today, but will be important when we add more WASM features (e.g. SIMD support) in the future.
• added typespecs for all public Wasmex methods
• improved documentation and typespecs
• allow starting the Wasmex GenServer with a %{bytes: bytes, store: store} map as a convenience to spare users the task of manually compiling a Wasmex.Module

v0.8.0

This release brings some changes to our API because of the change of the underlying WASM engine to wasmtime.

It brings a new abstraction, the Wasmex.Store, which holds all internal structures. Thus, the store (or a "caller" in function-call contexts) needs to be provided in most Wasmex APIs in the form of a Wasmex.StoreOrCaller struct.

The WASM engine change requires us to do further changes, most notably a change in how Wasmex.Memory is accessed. We dropped support for different data types and simplified the memory model to be just an array of bytes. The concept of memory offsets was dropped.

Special thanks goes to @​hamptokr for his help in getting the wasmtime/Rust side working 💜

Please see the list of changes below for more details.

Added

• Added support for OTP 25
• Added support for Elixir 1.14

Removed

... (truncated)

Changelog

Sourced from wasmex's changelog.

[0.8.2] - 2023-01-08

Added

• list aarch64-unknown-linux-musl in rustler targets, so we actually include it in our releases

[0.8.1] - 2023-01-08

This release makes running user-provided WASM binaries a whole bunch safter by providing restrictions on memory and CPU usage.

Have a look at Wasmex.StoreLimits for memory restrictions and Wasmer.EngineConfig on how to limit fuel (CPU usage quota).

The new Wasmex.EngineConfig allows better reporting when WASM execution fails -- setting wasm_backtrace_details enables error backtraces to include file and line number information if that debug info is available in the running WASM file.

A Wasmex.EngineConfig is used to create a Wasmex.Engine, which holds configuration for a Wasmex.Store. It allows us to selectively enable/disable more WASM option (e.g. enabling certain WASM proposals). Today, a Wasmex.Engine already gives us a faster way to precompile modules without the need to instantiate them through Wasmex.Engine.precompile_module/2.

Added

• Added precompiled binary for aarch64-unknown-linux-musl
• Added support for setting store limits. This allows users to limit memory usage, instance creation, table sizes and more. See Wasmex.StoreLimits for details.
• Added support for metering/fuel_consumption. This allows users to limit CPU usage. A Wasmex.Store can be given fuel, where each WASM instruction of a running WASM binary uses a certain amount of fuel. If no fuel remains, execution stops. See Wasmex.EngineConfig for details.
• Added Wasmex.EngineConfig as a place for more complex WASM settings. With this release an engine can be configured to provide more detailed backtraces on errors during WASM execution by setting the wasm_backtrace_details flag.
• Added Wasmex.Engine.precompile_module/2 which allows module precompilation from a .wat or .wasm binary without the need to instantiate said module. A precompiled module can be hydrated with Module.unsafe_deserialize/2.
• Added Wasmex.module/1 and Wasmex.store/1 to access the module and store of a running Wasmex GenServer process.
• Added option to Wasmex.EngineConfig to configure the cranelift_opt_level (:none, :speed, :speed_and_size) allowing users to trade compilation time against execution speed

Changed

• mix.exs now also requires at least Elixir 1.12
• Module.unsafe_deserialize/2 now accepts a Wasmex.Engine in addition to the serialized module binary. It's best to hydrate a module using the same engine config used to serialize or precompile it. It has no harsh consequences today, but will be important when we add more WASM features (e.g. SIMD support) in the future.
• added typespecs for all public Wasmex methods
• improved documentation and typespecs
• allow starting the Wasmex GenServer with a %{bytes: bytes, store: store} map as a convenience to spare users the task of manually compiling a Wasmex.Module

[0.8.0] - 2023-01-03

This release brings some changes to our API because of the change of the underlying WASM engine to wasmtime.

It brings a new abstraction, the Wasmex.Store, which holds all internal structures. Thus, the store (or a "caller" in function-call contexts) needs to be provided in most Wasmex APIs in the form of a Wasmex.StoreOrCaller struct.

The WASM engine change requires us to do further changes, most notably a change in how Wasmex.Memory is accessed. We dropped support for different data types and simplified the memory model to be just an array of bytes. The concept of memory offsets was dropped.

Please visit the list of changes below for more details.

... (truncated)

Commits

• 398933a prepare v0.8.2
• 751ea7b upgrade release pipeine and add aarch64-unknown-linux-musl not only to CI but...
• 3395d4b prepare version 0.8.1
• f8d3a07 Fix typo in docs (#393)
• 62e6980 Add option to EngineConfig to configure cranelift_opt_level (#390)
• 57d1d5d Add support for fuel_consumption and Engine configs (#389)
• e043f35 Add support for setting Store limits (#388)
• 1df863f Improve CI workflows, add support for aarch64-unknown-linux-musl precompiled ...
• e592d23 release 0.8.0
• 32cfd5d Switch WASM engine to wasmtime (#385)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)