Merge with upstream #238
Merged
Merge with upstream #238
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
…d `externref` (bytecodealliance#9435) * Implement the Wasm GC instructions for converting between `anyref` and `externref` This commit implements two instructions: 1. `any.convert_extern` 2. `extern.convert_any` These instructions are used to convert between `anyref` and `externref` values. The `any.convert_extern` instruction takes an `anyref` value and converts it to an `externref` value. The `extern.convert_any` instruction takes an `externref` value and converts it to an `anyref` value. Rather than implementing wrapper objects -- for example an `struct AnyOfExtern(ExternRef)` type that is a subtype of `AnyRef` -- we instead reuse the same representation converted references as their unconverted reference. For example, `(any.convert_extern my_externref)` is identical to the original `my_externref` value. This means that we don't actually emit any clif instructions to implement these Wasm instructions; they are no-ops! Wasm code remains none-the-wiser because it cannot directly test for the difference between, for example, a `my_anyref` and the result of `(extern.convert_any my_anyref)` because they are in two different type hierarchies, so any direct `ref.test` would be invalid. The Wasm code would have to convert one into the other's type hierarchy, at which point it doesn't know whether wrapping/unwrapping took place. We did need some changes at the host API and host API implementation levels, however: * We needed to relax the requirement that a `wasmtime::AnyRef` only wraps a `VMGcRef` that points to an object that is a subtype of `anyref` and similar for `wasmtime::ExternRef`. * We needed to make the `wasmtime::ExternRef::data[_mut]` methods return an option of their associated host data, since any `externref` resulting from `(extern.convert_any ...)` does not have any associated host data. (This change would have been required either way, even if we used wrapper objects.) * fix tests * fix wasmtime-environ tests
…nce#9438) Just gluing our existing `ref.test` and conditional branching support together.
…9433) This commit codifies the process [documented here](https://github.com/bytecodealliance/rfcs/blob/main/accepted/vulnerability-response-runbook.md) in the Wasmtime repository as it relates to Wasmtime itself. There's also a few minor changes from recent advisories such as: * We'll no longer use the publish-the-changes-from-the-advisory feature from GitHub. That basically just doesn't work any more. * PRs will instead be manually created to have CI run on them to weed out any issues. * Details about preparing the `main` branch ahead of the release are interleaved with the rest of the runbook. The intention is to supplement the official runbook with Wasmtime-specific information and flesh out a few minor steps we're following that are "extra" here too.
…t linking and subtyping (bytecodealliance#9446) * Enable some miscellaneous GC spec tests These weren't caught by our checks that `should_fail` tests do not pass, I think because they only contain modules that should validate, and not any actual assertions. * Require declared subtyping when linking module import/export functions We were previously incorrectly doing a (shallow) match on structure when we should have been doing a subtyping check.
…9256) (bytecodealliance#9447) * Update `decommit_batch_size` type to `usize` * Add missing pooling options to `OptimizeOptions` * Add new pooling options to configuration * Add `max_memory_protection_keys` option also rename `memory_protection_keys` to `pooling_memory_protection_keys` * Add `total_gc_heaps` option * Add default options in comments
Help trim version of wasm-tools crates.
* Update docs/stabilization of wasm proposals This commit updates our documentation and documented status of various WebAssembly proposals. The goal of this commit it to explicitly list all requirements for each WebAssembly proposal in a way such that enabling a feature requires actively checking this table and performing effort to fill in. This is intended to mitigate GHSA-q8hx-mm92-4wvg where it was found that we were accidentally not fuzzing tail calls but had enabled it by default. This shuffles around some documentation, modernizes a bit, and notably tries to list out a green checkbox or red X for the status of various proposals. Notes for "holes" in the "on by default matrix" are also added. * Add a link to the GC tracking issue * Tweak the list of supported targets Android is listed in Tier 3 now
…ytecodealliance#9448) * Implement subtype checking for `[return_]call_indirect` instructions When Wasm GC is enabled, the `[return_]call_indirect` instructions must do full subtyping checks, rather than simple strict equality type checks. This adds an additional branch and slow path to indirect calls, so we only emit code for this check when Wasm GC is enabled, even though it would otherwise be correct to always emit it (because the `is_subtype` check would always fail for non-equal types, since there is no subtyping before Wasm GC). * fix no-gc builds
…iance#9453) This helps us keep track of their code quality, and the way that some of them are reusing our implementation of `ref.test`.
This commit adds a test to the `wasmtime-fuzzing` crate as a sanity-check that eventually a module is generated requiring all of the features that wasmtime supports. This is intended to be another double-check in the process of enabling a proposal in Wasmtime by ensuring that the feature is added to this list which then transitively requires that fuzzing eventually generates a module needing that feature. cc bytecodealliance#9449
… from host APIs (bytecodealliance#9454) * Add support for initializing/getting/setting `funcref`s in GC structs from host APIs We implemented support for `funcref`s in both Wasm and host APIs for arrays, but somehow only implemented support for `funcref`s in structs for compiled Wasm code, and mistakenly forgot about them for structs and host APIs (and things that use host APIs, such as const expressions). * fix clippy
Move everything into the same location about what features are enabled, which are disabled, and such. Also statically enumerate all the features that wasm-smith enables for us and acknowledge that here too.
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.
No description provided.