[12.0.0] Revert "Require wasmtime options are first when running modules (#6737)" #6830
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…les (bytecodealliance#6737)" This reverts commit 8091556. The fallout of this change has been larger than expected so revert this on the 12.0.0 branch to provide more time to discuss this and figure out the best course of action.
|
For fuller context see #6737 |
jameysharp
approved these changes
Aug 10, 2023
|
(We probably want to update the release notes as well?) |
|
Yeah I mostly don't want to feel time pressure to discuss this just before the release and make a snap decision. I'm driving back from Chicago on Thursday so I may be around but may also be somewhere in the middle of I-80 and I'm pretty sure zooming-and-driving is not recommended. Deferring should help make the timing around this change a bit more comfy. I'll be sure to update the release notes on |
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Aug 10, 2023
This was reverted for 12.0.0 in bytecodealliance#6830
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Aug 10, 2023
This was reverted for 12.0.0 in bytecodealliance#6830
github-merge-queue bot
pushed a commit
that referenced
this pull request
Aug 11, 2023
This was reverted for 12.0.0 in #6830
eduardomourar
pushed a commit
to eduardomourar/wasmtime
that referenced
this pull request
Aug 18, 2023
This was reverted for 12.0.0 in bytecodealliance#6830
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Aug 31, 2023
This commit is a partial revert of bytecodealliance#6737. That change was reverted in bytecodealliance#6830 for the 12.0.0 release of Wasmtime and otherwise it's currently slated to get released with the 13.0.0 release of Wasmtime. Discussion at today's Wasmtime meeting concluded that it's best to couple this change with bytecodealliance#6925 as a single release rather than spread out across multiple releases. This commit is thus the revert of bytecodealliance#6737, although it's a partial revert in that I've kept many of the new tests added to showcase the differences before/after when the change lands. This means that Wasmtime 13.0.0 will exhibit the same CLI behavior as 12.0.0 and all prior releases. The 14.0.0 release will have both a new CLI and new argument passing semantics. I'll revert this revert (aka re-land bytecodealliance#6737) once the 13.0.0 release branch is created and `main` becomes 14.0.0.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Aug 31, 2023
* Partially revert CLI argument changes from #6737 This commit is a partial revert of #6737. That change was reverted in #6830 for the 12.0.0 release of Wasmtime and otherwise it's currently slated to get released with the 13.0.0 release of Wasmtime. Discussion at today's Wasmtime meeting concluded that it's best to couple this change with #6925 as a single release rather than spread out across multiple releases. This commit is thus the revert of #6737, although it's a partial revert in that I've kept many of the new tests added to showcase the differences before/after when the change lands. This means that Wasmtime 13.0.0 will exhibit the same CLI behavior as 12.0.0 and all prior releases. The 14.0.0 release will have both a new CLI and new argument passing semantics. I'll revert this revert (aka re-land #6737) once the 13.0.0 release branch is created and `main` becomes 14.0.0. * Update release notes
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Aug 31, 2023
This commit implements a new behavior for the CLI of the `wasmtime` executable which will require that options for Wasmtime itself come before the wasm module being run. Currently they're allowed to come afterwards, but instead all arguments and flags coming after a module will be interpreted as arguments for the module itself. This feature has a bit of a storied history at this point, and the breadcrumbs are: * Originally landed in bytecodealliance#6737 * Reverted for 12.0.0 in bytecodealliance#6830 * Reverted for 13.0.0 in bytecodealliance#6944 This PR is intended to be landed as a sibling of bytecodealliance#6925, another independent overhaul of Wasmtime's own options on the CLI, for the Wasmtime 14.0.0 release. More information about the motivation for this change, as well as consequences of the fallout, can be found on bytecodealliance#6737.
pchickey
pushed a commit
that referenced
this pull request
Sep 1, 2023
…6950) * Enhance `async` configuration of `bindgen!` macro (#6942) This commit takes a leaf out of `wiggle`'s book to enable bindings generation for async host functions where only some host functions are async instead of all of them. This enhances the `async` key with a few more options: async: { except_imports: ["foo"], only_imports: ["bar"], } This is beyond what `wiggle` supports where either an allow-list or deny-list can be specified (although only one can be specified). This can be useful if either the list of sync imports or the list of async imports is small. * cranelift-interpreter: Fix SIMD shifts and rotates (#6939) * cranelift-interpreter: Fix SIMD `ishl`/`{s,u}`shr * fuzzgen: Enable a few more ops * cranelift: Fix tests for {u,s}shr * fuzzgen: Change pattern matching arms for shifts Co-Authored-By: Jamey Sharp <[email protected]> --------- Co-authored-by: Jamey Sharp <[email protected]> * Partially revert CLI argument changes from #6737 (#6944) * Partially revert CLI argument changes from #6737 This commit is a partial revert of #6737. That change was reverted in #6830 for the 12.0.0 release of Wasmtime and otherwise it's currently slated to get released with the 13.0.0 release of Wasmtime. Discussion at today's Wasmtime meeting concluded that it's best to couple this change with #6925 as a single release rather than spread out across multiple releases. This commit is thus the revert of #6737, although it's a partial revert in that I've kept many of the new tests added to showcase the differences before/after when the change lands. This means that Wasmtime 13.0.0 will exhibit the same CLI behavior as 12.0.0 and all prior releases. The 14.0.0 release will have both a new CLI and new argument passing semantics. I'll revert this revert (aka re-land #6737) once the 13.0.0 release branch is created and `main` becomes 14.0.0. * Update release notes * riscv64: Use `PCRelLo12I` relocation on Loads (#6938) * riscv64: Use `PCRelLo12I` relocation on Loads * riscv64: Strenghten pattern matching when emitting Load's * riscv64: Clarify some of the load address logic * riscv64: Even stronger matching * Update Rust in CI to 1.72.0, clarify Wasmtime's MSRV (#6900) * Update Rust in CI to 1.72.0 * Update CI, tooling, and docs for MSRV This commit codifies an MSRV policy for Wasmtime at "stable minus two" meaning that the latest three releases of Rust will be supported. This is enforced on CI with a full test suite job running on Linux x86_64 with the minimum supported Rust version. The full test suite will use the latest stable version. A downside of this approach is that new changes may break MSRV support on non-Linux or non-x86_64 platforms and we won't know about it, but that's deemed a minor enough risk at this time. A minor fix is applied to Wasmtime's `Cargo.toml` to support Rust 1.70.0 instead of requiring Rust 1.71.0 * Fix installation of rust * Scrape MSRV from Cargo.toml * Cranelift is the same as Wasmtime's MSRV now, more words too * Fix a typo * aarch64: Use `RegScaled*` addressing modes (#6945) This commit adds a few cases to `amode` construction on AArch64 for using the `RegScaled*` variants of `AMode`. This won't affect wasm due to this only matching the sign-extension happening before the shift, but it should otherwise help non-wasm Cranelift use cases. Closes #6742 * cranelift: Validate `iconst` ranges (#6850) * cranelift: Validate `iconst` ranges Add the following checks: `iconst.i8` immediate must be within 0 .. 2^8-1 `iconst.i16` immediate must be within 0 .. 2^16-1 `iconst.i32` immediate must be within 0 .. 2^32-1 Resolves #3059 * cranelift: Parse `iconst` according to its type Modifies the parser for textual CLIF so that V in `iconst.T V` is parsed according to T. Before this commit, something like `iconst.i32 0xffff_ffff_ffff` was valid because all `iconst` were parsed the same as an `iconst.i64`. Now the above example will throw an error. Also, a negative immediate as in `iconst.iN -X` is now converted to `2^N - X`. This commit also fixes some broken tests. * cranelift: Update tests to match new CLIF parser * Some minor fixes and features for WASI and sockets (#6948) * Use `command::add_to_linker` in tests to reduce the number of times all the `add_to_linker` are listed. * Add all `wasi:sockets` interfaces currently implemented to both the sync and async `command` functions (this enables all the interfaces in the CLI for example). * Use `tokio::net::TcpStream::try_io` whenever I/O is performed on a socket, ensuring that readable/writable flags are set/cleared appropriately (otherwise once readable a socket is infinitely readable). * Add a `with_ambient_tokio_runtime` helper function to use when creating a `tokio::net::TcpStream` since otherwise it panics due to a lack of active runtime in a synchronous context. * Add `WouldBlock` handling to return a 0-length read. * Add an `--inherit-network` CLI flag to enable basic usage of sockets in the CLI. This will conflict a small amount with #6877 but should be easy to resolve, and otherwise this targets different usability points/issues than that PR. --------- Co-authored-by: Afonso Bordado <[email protected]> Co-authored-by: Jamey Sharp <[email protected]> Co-authored-by: Timothée Jourde <[email protected]>
eduardomourar
pushed a commit
to eduardomourar/wasmtime
that referenced
this pull request
Sep 6, 2023
…ecodealliance#6944) * Partially revert CLI argument changes from bytecodealliance#6737 This commit is a partial revert of bytecodealliance#6737. That change was reverted in bytecodealliance#6830 for the 12.0.0 release of Wasmtime and otherwise it's currently slated to get released with the 13.0.0 release of Wasmtime. Discussion at today's Wasmtime meeting concluded that it's best to couple this change with bytecodealliance#6925 as a single release rather than spread out across multiple releases. This commit is thus the revert of bytecodealliance#6737, although it's a partial revert in that I've kept many of the new tests added to showcase the differences before/after when the change lands. This means that Wasmtime 13.0.0 will exhibit the same CLI behavior as 12.0.0 and all prior releases. The 14.0.0 release will have both a new CLI and new argument passing semantics. I'll revert this revert (aka re-land bytecodealliance#6737) once the 13.0.0 release branch is created and `main` becomes 14.0.0. * Update release notes
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Sep 13, 2023
This commit implements a new behavior for the CLI of the `wasmtime` executable which will require that options for Wasmtime itself come before the wasm module being run. Currently they're allowed to come afterwards, but instead all arguments and flags coming after a module will be interpreted as arguments for the module itself. This feature has a bit of a storied history at this point, and the breadcrumbs are: * Originally landed in bytecodealliance#6737 * Reverted for 12.0.0 in bytecodealliance#6830 * Reverted for 13.0.0 in bytecodealliance#6944 This PR is intended to be landed as a sibling of bytecodealliance#6925, another independent overhaul of Wasmtime's own options on the CLI, for the Wasmtime 14.0.0 release. More information about the motivation for this change, as well as consequences of the fallout, can be found on bytecodealliance#6737.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Sep 13, 2023
This commit implements a new behavior for the CLI of the `wasmtime` executable which will require that options for Wasmtime itself come before the wasm module being run. Currently they're allowed to come afterwards, but instead all arguments and flags coming after a module will be interpreted as arguments for the module itself. This feature has a bit of a storied history at this point, and the breadcrumbs are: * Originally landed in bytecodealliance#6737 * Reverted for 12.0.0 in bytecodealliance#6830 * Reverted for 13.0.0 in bytecodealliance#6944 This PR is intended to be landed as a sibling of bytecodealliance#6925, another independent overhaul of Wasmtime's own options on the CLI, for the Wasmtime 14.0.0 release. More information about the motivation for this change, as well as consequences of the fallout, can be found on bytecodealliance#6737.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Sep 13, 2023
This commit implements a new behavior for the CLI of the `wasmtime` executable which will require that options for Wasmtime itself come before the wasm module being run. Currently they're allowed to come afterwards, but instead all arguments and flags coming after a module will be interpreted as arguments for the module itself. This feature has a bit of a storied history at this point, and the breadcrumbs are: * Originally landed in #6737 * Reverted for 12.0.0 in #6830 * Reverted for 13.0.0 in #6944 This PR is intended to be landed as a sibling of #6925, another independent overhaul of Wasmtime's own options on the CLI, for the Wasmtime 14.0.0 release. More information about the motivation for this change, as well as consequences of the fallout, can be found on #6737.
eduardomourar
pushed a commit
to eduardomourar/wasmtime
that referenced
this pull request
Sep 15, 2023
) This commit implements a new behavior for the CLI of the `wasmtime` executable which will require that options for Wasmtime itself come before the wasm module being run. Currently they're allowed to come afterwards, but instead all arguments and flags coming after a module will be interpreted as arguments for the module itself. This feature has a bit of a storied history at this point, and the breadcrumbs are: * Originally landed in bytecodealliance#6737 * Reverted for 12.0.0 in bytecodealliance#6830 * Reverted for 13.0.0 in bytecodealliance#6944 This PR is intended to be landed as a sibling of bytecodealliance#6925, another independent overhaul of Wasmtime's own options on the CLI, for the Wasmtime 14.0.0 release. More information about the motivation for this change, as well as consequences of the fallout, can be found on bytecodealliance#6737.
eduardomourar
pushed a commit
to eduardomourar/wasmtime
that referenced
this pull request
Sep 22, 2023
) This commit implements a new behavior for the CLI of the `wasmtime` executable which will require that options for Wasmtime itself come before the wasm module being run. Currently they're allowed to come afterwards, but instead all arguments and flags coming after a module will be interpreted as arguments for the module itself. This feature has a bit of a storied history at this point, and the breadcrumbs are: * Originally landed in bytecodealliance#6737 * Reverted for 12.0.0 in bytecodealliance#6830 * Reverted for 13.0.0 in bytecodealliance#6944 This PR is intended to be landed as a sibling of bytecodealliance#6925, another independent overhaul of Wasmtime's own options on the CLI, for the Wasmtime 14.0.0 release. More information about the motivation for this change, as well as consequences of the fallout, can be found on bytecodealliance#6737.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This reverts commit 8091556. The fallout of this change has been larger than expected so revert this on the 12.0.0 branch to provide more time to discuss this and figure out the best course of action.