Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wasm GC: Fix an incorrect assertion and canonicalize types for runtime usage in ExternType::from_wasmtime #10223

Merged
merged 4 commits into from
Feb 14, 2025

Conversation

fitzgen
Copy link
Member

@fitzgen fitzgen commented Feb 12, 2025

see commit messages for details

It is possible for two `WasmSubType`s to be equal to each other, as far as
`derive(PartialEq)` is concerned, but still different from each other if they
are in different rec groups or even if they are at different indices within the
same rec group. The assertion mistakenly did not permit either of these,
however.

Fixes bytecodealliance#9714
@fitzgen fitzgen requested a review from alexcrichton February 12, 2025 17:39
@fitzgen fitzgen requested review from a team as code owners February 12, 2025 17:39
@github-actions github-actions bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Feb 12, 2025
@alexcrichton
Copy link
Member

Nick and I talked a bit about this in person and the conclusion was that we'll instead try canonicalizing ModuleTypes when the signature collection is created instead of later when type-checking happens to avoid threading through the new state

…dule,Component}`s

Rather than canonicalizing them on demand in functions like
`{Func,Global,Table}Type::from_wasmtime` and other places. Instead, we do it in
one place, up front, so that it is very unlikely we miss anything. Doing this
involves changing some things from `ModuleInternedTypeIndex`es to
`EngineOrModuleTypeIndex`es in `wasmtime_environ`, which means that a bunch of
uses of those things need to unwrap the appropriate kind of type index at usage
sites (e.g. compilation uses will unwrap `ModuleInternedTypeIndex`es, runtime
uses usage will unwrap `VMSharedTypeIndex`es). And it additionally required
implementing the `TypeTrace` trait for a handful of things to unlock the
provided `canonicalize_for_runtime_usage` trait method for those things.

All this machinery is required to avoid an assertion failure in the regression
test introduced in the previous commit, which was triggered because we were
failing to canonicalize type indices inside `ExternType`s for runtime usage on
some code paths. We shouldn't have to play that kind of whack-a-mole in the
future, thanks to this new approach.
@fitzgen fitzgen requested a review from a team as a code owner February 13, 2025 22:22
@fitzgen fitzgen requested review from abrown and removed request for a team February 13, 2025 22:22
@github-actions github-actions bot added wasmtime:ref-types Issues related to reference types and GC in Wasmtime winch Winch issues or pull requests labels Feb 13, 2025
Copy link

Subscribe to Label Action

cc @fitzgen, @saulecabrera

This issue or pull request has been labeled: "wasmtime:api", "wasmtime:ref-types", "winch"

Thus the following users have been cc'd because of the following labels:

  • fitzgen: wasmtime:ref-types
  • saulecabrera: winch

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

@alexcrichton alexcrichton added this pull request to the merge queue Feb 14, 2025
Merged via the queue into bytecodealliance:main with commit cb235ec Feb 14, 2025
39 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:ref-types Issues related to reference types and GC in Wasmtime winch Winch issues or pull requests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants