wasmtime / issue #6925 Redesign Wasmtime's CLI · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #6925 Redesign Wasmtime's CLI

Wasmtime GitHub notifications bot (Aug 29 2023 at 18:21):

Also, as a final note, there's a shed with bikes here and we gotta figure out the color. I'm happy to hand out paint brushes to anyone willing! AKA now's the time for bikeshedding this where we only get to do this once really IMO

Wasmtime GitHub notifications bot (Aug 29 2023 at 18:25):

alexcrichton commented on issue #6925:

I'll note that this is a breaking change and we're in the period of "no breaking changes before WasmCon", so this shouldn't land for a few weeks. Additionally some more background for this is available at https://github.com/bytecodealliance/wasmtime/issues/6741 too.

Finally here's some snippets:

<summary><code>./target/debug/wasmtime -h</code></summary>

Wasmtime WebAssembly Runtime

Usage: wasmtime [OPTIONS] <WASM>...
       wasmtime <COMMAND>

Commands:
  config    Controls Wasmtime configuration settings
  compile   Compiles a WebAssembly module
  explore   Explore the compilation of a WebAssembly module to native code
  run       Runs a WebAssembly module
  settings  Displays available Cranelift settings for a target
  wast      Runs a WebAssembly test script file
  help      Print this message or the help of the given subcommand(s)

Arguments:
  <WASM>...  The WebAssembly module to run and arguments to pass to it

Options:
  -O, --optimize <KEY[=VAL[,..]]>    Optimization and tuning related options for wasm performance, `-O help` to see all
  -C, --codegen <KEY[=VAL[,..]]>     Codegen-related configuration options, `-C help` to see all
  -D, --debug <KEY[=VAL[,..]]>       Debug-related configuration options, `-D help` to see all
  -W, --wasm <KEY[=VAL[,..]]>        Options for configuring semantic execution of WebAssembly, `-W help` to see all
  -S, --wasi <KEY[=VAL[,..]]>        Options for configuring WASI and its proposals, `-S help` to see all
      --allow-precompiled            Allow executing precompiled WebAssembly modules as `*.cwasm` files
      --dir <GUEST_DIR[::HOST_DIR]>  Grant access of a host directory to a guest
      --env <NAME[=VAL]>             Pass an environment variable to the program
      --invoke <FUNCTION>            The name of the function to run
      --preload <NAME=MODULE_PATH>   Load the given WebAssembly module before the main module
      --profile <STRATEGY>           Profiling strategy (valid options are: perfmap, jitdump, vtune, guest)
  -h, --help                         Print help (see more with '--help')
  -V, --version                      Print version

If a subcommand is not provided, the `run` subcommand will be used.

Usage examples:

Running a WebAssembly module with a start function:

  wasmtime example.wasm

Passing command line arguments to a WebAssembly module:

  wasmtime example.wasm arg1 arg2 arg3

Invoking a specific function (e.g. `add`) in a WebAssembly module:

  wasmtime example.wasm --invoke add 1 2

</details>

<summary><code>./target/debug/wasmtime run -h</code></summary>

Runs a WebAssembly module

Usage: wasmtime run [OPTIONS] <WASM>...

Arguments:
  <WASM>...  The WebAssembly module to run and arguments to pass to it

Options:
  -O, --optimize <KEY[=VAL[,..]]>    Optimization and tuning related options for wasm performance, `-O help` to see all
  -C, --codegen <KEY[=VAL[,..]]>     Codegen-related configuration options, `-C help` to see all
  -D, --debug <KEY[=VAL[,..]]>       Debug-related configuration options, `-D help` to see all
  -W, --wasm <KEY[=VAL[,..]]>        Options for configuring semantic execution of WebAssembly, `-W help` to see all
  -S, --wasi <KEY[=VAL[,..]]>        Options for configuring WASI and its proposals, `-S help` to see all
      --allow-precompiled            Allow executing precompiled WebAssembly modules as `*.cwasm` files
      --dir <GUEST_DIR[::HOST_DIR]>  Grant access of a host directory to a guest
      --env <NAME[=VAL]>             Pass an environment variable to the program
      --invoke <FUNCTION>            The name of the function to run
      --preload <NAME=MODULE_PATH>   Load the given WebAssembly module before the main module
      --profile <STRATEGY>           Profiling strategy (valid options are: perfmap, jitdump, vtune, guest)
  -h, --help                         Print help (see more with '--help')

</details>

<summary><code>./target/debug/wasmtime compile -h</code></summary>

Compiles a WebAssembly module

Usage: wasmtime compile [OPTIONS] <MODULE>

Arguments:
  <MODULE>  The path of the WebAssembly to compile

Options:
  -O, --optimize <KEY[=VAL[,..]]>  Optimization and tuning related options for wasm performance, `-O help` to see all
  -C, --codegen <KEY[=VAL[,..]]>   Codegen-related configuration options, `-C help` to see all
  -D, --debug <KEY[=VAL[,..]]>     Debug-related configuration options, `-D help` to see all
  -W, --wasm <KEY[=VAL[,..]]>      Options for configuring semantic execution of WebAssembly, `-W help` to see all
  -S, --wasi <KEY[=VAL[,..]]>      Options for configuring WASI and its proposals, `-S help` to see all
      --target <TARGET>            The target triple; default is the host triple
  -o, --output <OUTPUT>            The path of the output compiled module; defaults to <MODULE>.cwasm
      --emit-clif <PATH>           The directory path to write clif files into, one clif file per wasm function
  -h, --help                       Print help
  -V, --version                    Print version

By default, no CPU features or presets will be enabled for the compilation.

Usage examples:

Compiling a WebAssembly module for the current platform:

  wasmtime compile example.wasm

Specifying the output file:

  wasmtime compile -o output.cwasm input.wasm

Compiling for a specific platform (Linux) and CPU preset (Skylake):

  wasmtime compile --target x86_64-unknown-linux -Ccranelift-skylake foo.wasm

</details>

<summary><code>./target/debug/wasmtime -O help</code></summary>

Available optimize options:

  -O                          opt-level=val -- Optimization level of generated code (0-2, s; default: 0)
  -O          dynamic-memory-guard-size=val -- Byte size of the guard region after dynamic memories are allocated
  -O             static-memory-forced[=val] -- Force using a "static" style for all wasm memories
  -O         static-memory-maximum-size=val -- Maximum size in bytes of wasm memory before it becomes dynamically relocatable instead of up-front-reserved.
  -O           static-memory-guard-size=val -- Byte size of the guard region after static memories are allocated
  -O dynamic-memory-reserved-for-growth=val -- Bytes to reserve at the end of linear memory for growth for dynamic memories.
  -O                pooling-allocator[=val] -- Enable the pooling allocator, in place of the on-demand allocator.
  -O                  memory-init-cow[=val] -- Configure attempting to initialize linear memory via a copy-on-write mapping (default: yes)

pass `-O help-long` to see longer-form explanations

</details>

<summary><code>./target/debug/wasmtime -C help</code></summary>

Available codegen options:

  -C                   compiler=val -- Either `cranelift` or `winch`.
  -C cranelift-debug-verifier[=val] -- Enable Cranelift's internal debug verifier (expensive)
  -C                    cache[=val] -- Whether or not to enable caching of compiled modules.
  -C               cache-config=val -- Configuration for compiled module caching.
  -C     parallel-compilation[=val] -- Whether or not to enable parallel compilation of modules.
  -C          cranelift-<KEY>[=val] -- Set a cranelift-specific option. Use `wasmtime settings` to see all.

pass `-C help-long` to see longer-form explanations

</details>

<summary><code>./target/debug/wasmtime -W help</code></summary>

-W         -W   -W   -W   -W   -W   -W   -W   -W   -W   -W   -W   -W   -W   -W   -W   -W   -W   -W [message




class="n">Available wasm options: class="n">nan-canonicalization[=val] -- Enable canonicalization of all NaN values. fuel=val -- Enable execution fuel with N units fuel, trapping after running out of fuel. epoch-interruption[=val] -- Yield when a global epoch counter changes, allowing for async operation without blocking the executor. max-wasm-stack=val -- Maximum stack size, in bytes, that wasm is allowed to consume before a stack overflow is reported. unknown-exports-allow[=val] -- Allow unknown exports when running commands. unknown-imports-trap[=val] -- Allow the main module to import unknown functions, using an implementation that immediately traps, when running commands. unknown-imports-default[=val] -- Allow the main module to import unknown functions, using an implementation that returns default values, when running commands. wmemcheck[=val] -- Enables memory error checking. (see wmemcheck.md for more info) max-memory-size=val -- Maximum size, in bytes, that a linear memory is allowed to reach. max-table-elements=val -- Maximum size, in table elements, that a table is allowed to reach. max-instances=val -- Maximum number of WebAssembly instances allowed to be created. max-tables=val -- Maximum number of WebAssembly tables allowed to be created. max-memories=val -- Maximum number of WebAssembly linear memories allowed to be created. trap-on-grow-failure[=val] -- Force a trap to be raised on `memory.grow` and `table.grow` failure instead of returning -1 from these instructions. timeout=val -- Maximum execution time of wasm code before timing out (1, 2s, 100ms, etc) all-proposals[=val] -- Configures support for all WebAssembly proposals implemented. bulk-memory[=val] -- Configure support for the bulk memory proposal. multi-memory[=val] -- Configure support for the multi-memory proposal. class="n">truncated]






 Wasmtime GitHub notifications bot (Aug 29 2023 at 18:53):
abrown commented on issue #6925:

bikeshed: in the printed --help output, can we get all the val (I'm only looking under -S but this may apply elsewhere) to be printed as y|n or <encoding>::<dir> or whatever that flag expects? Essentially communicate more clearly what kinds of things are valid after =?





 Wasmtime GitHub notifications bot (Aug 29 2023 at 19:30):
alexcrichton commented on issue #6925:

Good point! Updated to that now





 Wasmtime GitHub notifications bot (Aug 29 2023 at 20:44):
github-actions[bot] commented on issue #6925:

Subscribe to Label Action
cc @peterhuene
<details>

This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config", "wasmtime:docs"
Thus the following users have been cc'd because of the following labels:

peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.

</details>





 Wasmtime GitHub notifications bot (Aug 29 2023 at 21:18):
github-actions[bot] commented on issue #6925:

Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to

complete this check list:


[ ] If you added a new Config method, you wrote extensive documentation for

      it.
<details>
Our documentation should be of the following form:
```text

Short, simple summary sentence.
More details. These details can be multiple paragraphs. There should be

information about not just the method, but its parameters and results as

well.
Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.

```
</details>


[ ] If you added a new Config method, or modified an existing one, you

  ensured that this configuration is exercised by the fuzz targets.
<details>
For example, if you expose a new strategy for allocating the next instance

slot inside the pooling allocator, you should ensure that at least one of our

fuzz targets exercises that new strategy.
Often, all that is required of you is to ensure that there is a knob for this

configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one

of its nested structs).
Rarely, this may require authoring a new fuzz target to specifically test this

configuration. See [our docs on fuzzing][fuzzing-docs] for more details.
</details>


[ ] If you are enabling a configuration option by default, make sure that it

  has been fuzzed for at least two weeks before turning it on by default.


[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194

[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html

<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the

<code>.github/label-messager.json</code> configuration file.
Learn more.
</details>





 Wasmtime GitHub notifications bot (Aug 31 2023 at 15:39):
alexcrichton edited a comment on issue #6925:

I'll note that this is a breaking change and we're in the period of "no breaking changes before WasmCon", so this shouldn't land for a few weeks. Additionally some more background for this is available at https://github.com/bytecodealliance/wasmtime/issues/6741 too.
Finally here's some snippets:
<details>
<summary><code>./target/debug/wasmtime -h</code></summary>
Wasmtime WebAssembly Runtime

Usage: wasmtime [OPTIONS] <WASM>...
       wasmtime <COMMAND>

Commands:
  config    Controls Wasmtime configuration settings
  compile   Compiles a WebAssembly module
  explore   Explore the compilation of a WebAssembly module to native code
  run       Runs a WebAssembly module
  settings  Displays available Cranelift settings for a target
  wast      Runs a WebAssembly test script file
  help      Print this message or the help of the given subcommand(s)

Arguments:
  <WASM>...  The WebAssembly module to run and arguments to pass to it

Options:
  -O, --optimize <KEY[=VAL[,..]]>    Optimization and tuning related options for wasm performance, `-O help` to see all
  -C, --codegen <KEY[=VAL[,..]]>     Codegen-related configuration options, `-C help` to see all
  -D, --debug <KEY[=VAL[,..]]>       Debug-related configuration options, `-D help` to see all
  -W, --wasm <KEY[=VAL[,..]]>        Options for configuring semantic execution of WebAssembly, `-W help` to see all
  -S, --wasi <KEY[=VAL[,..]]>        Options for configuring WASI and its proposals, `-S help` to see all
      --allow-precompiled            Allow executing precompiled WebAssembly modules as `*.cwasm` files
      --dir <GUEST_DIR[::HOST_DIR]>  Grant access of a host directory to a guest
      --env <NAME[=VAL]>             Pass an environment variable to the program
      --invoke <FUNCTION>            The name of the function to run
      --preload <NAME=MODULE_PATH>   Load the given WebAssembly module before the main module
      --profile <STRATEGY>           Profiling strategy (valid options are: perfmap, jitdump, vtune, guest)
  -h, --help                         Print help (see more with '--help')
  -V, --version                      Print version

If a subcommand is not provided, the `run` subcommand will be used.

Usage examples:

Running a WebAssembly module with a start function:

  wasmtime example.wasm

Passing command line arguments to a WebAssembly module:

  wasmtime example.wasm arg1 arg2 arg3

Invoking a specific function (e.g. `add`) in a WebAssembly module:

  wasmtime example.wasm --invoke add 1 2

</details>
<details>
<summary><code>./target/debug/wasmtime run -h</code></summary>
Runs a WebAssembly module

Usage: wasmtime run [OPTIONS] <WASM>...

Arguments:
  <WASM>...  The WebAssembly module to run and arguments to pass to it

Options:
  -O, --optimize <KEY[=VAL[,..]]>    Optimization and tuning related options for wasm performance, `-O help` to see all
  -C, --codegen <KEY[=VAL[,..]]>     Codegen-related configuration options, `-C help` to see all
  -D, --debug <KEY[=VAL[,..]]>       Debug-related configuration options, `-D help` to see all
  -W, --wasm <KEY[=VAL[,..]]>        Options for configuring semantic execution of WebAssembly, `-W help` to see all
  -S, --wasi <KEY[=VAL[,..]]>        Options for configuring WASI and its proposals, `-S help` to see all
      --allow-precompiled            Allow executing precompiled WebAssembly modules as `*.cwasm` files
      --dir <GUEST_DIR[::HOST_DIR]>  Grant access of a host directory to a guest
      --env <NAME[=VAL]>             Pass an environment variable to the program
      --invoke <FUNCTION>            The name of the function to run
      --preload <NAME=MODULE_PATH>   Load the given WebAssembly module before the main module
      --profile <STRATEGY>           Profiling strategy (valid options are: perfmap, jitdump, vtune, guest)
  -h, --help                         Print help (see more with '--help')

</details>
<details>
<summary><code>./target/debug/wasmtime compile -h</code></summary>
Compiles a WebAssembly module

Usage: wasmtime compile [OPTIONS] <MODULE>

Arguments:
  <MODULE>  The path of the WebAssembly to compile

Options:
  -O, --optimize <KEY[=VAL[,..]]>  Optimization and tuning related options for wasm performance, `-O help` to see all
  -C, --codegen <KEY[=VAL[,..]]>   Codegen-related configuration options, `-C help` to see all
  -D, --debug <KEY[=VAL[,..]]>     Debug-related configuration options, `-D help` to see all
  -W, --wasm <KEY[=VAL[,..]]>      Options for configuring semantic execution of WebAssembly, `-W help` to see all
  -S, --wasi <KEY[=VAL[,..]]>      Options for configuring WASI and its proposals, `-S help` to see all
      --target <TARGET>            The target triple; default is the host triple
  -o, --output <OUTPUT>            The path of the output compiled module; defaults to <MODULE>.cwasm
      --emit-clif <PATH>           The directory path to write clif files into, one clif file per wasm function
  -h, --help                       Print help
  -V, --version                    Print version

By default, no CPU features or presets will be enabled for the compilation.

Usage examples:

Compiling a WebAssembly module for the current platform:

  wasmtime compile example.wasm

Specifying the output file:

  wasmtime compile -o output.cwasm input.wasm

Compiling for a specific platform (Linux) and CPU preset (Skylake):

  wasmtime compile --target x86_64-unknown-linux -Ccranelift-skylake foo.wasm

</details>
<details>
<summary><code>./target/debug/wasmtime -O help</code></summary>
Available optimize options:

  -O                    opt-level=0|1|2|s -- Optimization level of generated code (0-2, s; default: 0)
  -O          dynamic-memory-guard-size=N -- Byte size of the guard region after dynamic memories are allocated
  -O           static-memory-forced[=y|n] -- Force using a "static" style for all wasm memories
  -O         static-memory-maximum-size=N -- Maximum size in bytes of wasm memory before it becomes dynamically relocatable instead of up-front-reserved.
  -O           static-memory-guard-size=N -- Byte size of the guard region after static memories are allocated
  -O dynamic-memory-reserved-for-growth=N -- Bytes to reserve at the end of linear memory for growth for dynamic memories.
  -O              pooling-allocator[=y|n] -- Enable the pooling allocator, in place of the on-demand allocator.
  -O                memory-init-cow[=y|n] -- Configure attempting to initialize linear memory via a copy-on-write mapping (default: yes)

pass `-O help-long` to see longer-form explanations

</details>
<details>
<summary><code>./target/debug/wasmtime -C help</code></summary>
Available codegen options:

  -C       compiler=winch|cranelift -- Either `cranelift` or `winch`.
  -C cranelift-debug-verifier[=y|n] -- Enable Cranelift's internal debug verifier (expensive)
  -C                    cache[=y|n] -- Whether or not to enable caching of compiled modules.
  -C               cache-config=val -- Configuration for compiled module caching.
  -C     parallel-compilation[=y|n] -- Whether or not to enable parallel compilation of modules.
  -C            cranelift-<KEY>=val -- Set a cranelift-specific option. Use `wasmtime settings` to see all.

pass `-C help-long` to see longer-form explanations

</details>
<details>
<summary><code>./target/debug/wasmtime -W help</code></summary>
Available wasm options:

  -W       nan-canonicalization[=y|n] -- Enable canonicalization of all NaN values.
  -W                           fuel=N -- Enable execution fuel with N units fuel, trapping after running out of fuel.
  -W         epoch-interruption[=y|n] -- Yield when a global epoch counter changes, allowing for async operation without blocking the executor.
  -W                 max-wasm-stack=N -- Maximum stack size, in bytes, that wasm is allowed to consume before a stack overflow is reported.
  -W      unknown-exports-allow[=y|n] -- Allow unknown exports when running commands.
  -W       unknown-imports-trap[=y|n] -- Allow the main module to import unknown functions, using an implementation that immediately traps, when running commands.
  -W    unknown-imports-default[=y|n] -- Allow the main module to import unknown functions, using an implementation that returns default values, when running commands.
  -W                  wmemcheck[=y|n] -- Enables memory error checking. (see wmemcheck.md for more info)
  -W                max-memory-size=N -- Maximum size, in bytes, that a linear memory is allowed to reach.
  -W             max-table-elements=N -- Maximum size, in table elements, that a table is allowed to reach.
  -W                  max-instances=N -- Maximum number of WebAssembly instances allowed to be created.
  -W                     max-tables=N -- Maximum number of WebAssembly tables allowed to be created.
  -W                   max-memories=N -- Maximum number of WebAssembly linear memories allowed to be created.
  -W       trap-on-grow-failure[=y|n] -- Force a trap to be raised on `memory.grow` and `table.grow` failure instead of returning -1 from these instructions.
  -W              timeout=N|Ns|Nms|.. -- Maximum execution time of wasm code before timing out (1, 2s, 100ms, etc)
  -W              all-proposals[=y|n] -- Configures support for all WebAssembly proposals implemented.
  -W                bulk-memory[=y|n] -- Configure support for the bulk memory proposal.
  -W               multi-memory[=y|n] -- Configure support for the multi-memory proposal.
  -W                mu
[message truncated]








 Wasmtime GitHub notifications bot (Aug 31 2023 at 17:43):
alexcrichton commented on issue #6925:

From today's Wasmtime meeting discussion the conclusion is that this PR will land in Wasmtime 14.0.0 and will be coupled with https://github.com/bytecodealliance/wasmtime/pull/6737. Despite https://github.com/bytecodealliance/wasmtime/pull/6737 being a landed PR on main it was reverted for 12.0.0 and is being reverted for the upcoming 13.0.0 branch. That'll re-land via a separate future PR for the 14.0.0 release once the 13.0.0 branch is created.





 Wasmtime GitHub notifications bot (Aug 31 2023 at 20:02):
alexcrichton commented on issue #6925:

I've converted this PR to a draft while we wait for Wasmtime 13.0.0 to get branched. In the meantime I've created a stream on Zulip to discuss these changes and there's a sibling PR for how Wasmtime's options are required to be first now.





 Wasmtime GitHub notifications bot (Sep 11 2023 at 14:33):
alexcrichton commented on issue #6925:

Ok now that we're post-WasmCon and given @abrown's previous approval I'm going to go ahead and land this.





 Wasmtime GitHub notifications bot (Oct 23 2023 at 18:13):
ydnar commented on issue #6925:

This broke TinyGo (and also mainline Go’s wasip1 runner): https://github.com/tinygo-org/tinygo/issues/3970
Would it be possible to introduce a minor change for backwards compatibility? I think these would be sufficient to fix at least TinyGo and Go:

Support --mapdir=GUEST::HOST as an alias for --dir=HOST::GUEST
If the command args includes --, then interpret everything before the -- as arguments to wasmtime, and everything after -- as arguments to the guest program






 Wasmtime GitHub notifications bot (Oct 23 2023 at 18:24):
ydnar edited a comment on issue #6925:

This broke TinyGo (and also mainline Go’s wasip1 runner): https://github.com/tinygo-org/tinygo/issues/3970
Would it be possible to introduce a minor change for backwards compatibility? I think these would be sufficient to fix at least TinyGo and Go:

Support --mapdir=GUEST::HOST as an alias for --dir=HOST::GUEST
If the command args includes --, then interpret everything before the -- as arguments to wasmtime, and everything after -- as arguments to the guest program

Edit: the above changes would fix TinyGo, but not mainline Go, which uses --max-wasm-stack N (now changed to -W max-wasm-stack=N





 Wasmtime GitHub notifications bot (Oct 23 2023 at 18:37):
alexcrichton commented on issue #6925:

Thanks for the report! I suspect that https://github.com/bytecodealliance/wasmtime/issues/7336 is a good place to continue discussion perhaps? (looks like y'all raced in reports!)
While it would be possible to implement something like what you mention, is it possible to require Wasmtime 14 and update scripts for Wasmtime 14?





 Wasmtime GitHub notifications bot (Oct 23 2023 at 18:52):
ydnar commented on issue #6925:

I made a PR for TinyGo (https://github.com/tinygo-org/tinygo/pull/3972), but landing a change to mainline Go will take time.
We got bit by this on Friday when CI started breaking. While it’s our fault for not pinning the version of wasmtime, I’m somewhat surprised y’all didn’t release at least one major version of wasmtime with a compatibility shim and deprecation warnings, so dependents would have time to migrate.





 Wasmtime GitHub notifications bot (Oct 23 2023 at 18:54):
ydnar edited a comment on issue #6925:

I made a PR for TinyGo (https://github.com/tinygo-org/tinygo/pull/3972), but landing a change to mainline Go will take time.
We got bit by this on Friday when CI started breaking. While it’s our fault for not pinning the version of wasmtime, I’m somewhat surprised y’all didn’t release at least one major version of wasmtime with a compatibility shim and deprecation warnings, so dependents would have time to migrate.
Edit: for example:
--max-wasm-stack: deprecated in wasmtime v14. Did you mean -W max-wasm-stack=N?





 Wasmtime GitHub notifications bot (Oct 23 2023 at 19:02):
alexcrichton commented on issue #6925:

Yes we decided in the development of this that smoothing the path with warnings and such was unfortunately not tenable in this case. For example many previous invocations are reinterpreted entirely differently and we didn't want one release of some breakage and another release of even more breakage. If it works in your CI I'd definitely recommend pinning Wasmtime versions with explicit updates.
FWIW if you're curious we attempted to discuss this broadly with lots of lead time about this. If you've got suggestions for how to improve the communication process and ensure this doesn't slip through the cracks again for y'all, please let us know!

original issue
Zulip discussion
Discussed in a bi-weekly meeting





Last updated: Dec 23 2024 at 12:05 UTC