Stream: git-wasmtime

Topic: wasmtime / PR #11229 Gut `vm::Export` to mostly be `crate...

Wasmtime GitHub notifications bot (Jul 11 2025 at 23:32):

alexcrichton opened PR #11229 from alexcrichton:less-exports to bytecodealliance:main:

This series of commits removes all of the vm::Export* types from Wasmtime. These were all relatively unsafe types which were schlepping around unsafe pointers from point A to point B. In lieu of this and given prior refactorings this commit replaces all of these items with the top-level crate definitions (e.g. crate::Func instead of ExportFunc). The goal here is to improve safety and generally reduce unsafe functions and blocks necessary. A nice benefit is that from a vm::Instance you can now directly load all top-level types such as crate::Table.

Wasmtime GitHub notifications bot (Jul 11 2025 at 23:32):

alexcrichton requested fitzgen for a review on PR #11229.

Wasmtime GitHub notifications bot (Jul 11 2025 at 23:32):

alexcrichton requested wasmtime-core-reviewers for a review on PR #11229.

Wasmtime GitHub notifications bot (Jul 12 2025 at 00:09):

alexcrichton updated PR #11229.

Wasmtime GitHub notifications bot (Jul 12 2025 at 03:16):

github-actions[bot] commented on PR #11229:

Subscribe to Label Action

cc @fitzgen

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

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

• fitzgen: wasmtime:ref-types

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 (Jul 14 2025 at 18:45):

fitzgen submitted PR review:

LGTM modulo one safety comment/question below that should be addressed before merging

Wasmtime GitHub notifications bot (Jul 14 2025 at 18:45):

fitzgen created PR review comment:

yesss

Wasmtime GitHub notifications bot (Jul 14 2025 at 18:45):

fitzgen created PR review comment:

Can we actually encapsulate the unsafety here? Because from_vm_func_ref requires that the store owns the given funcref, but because we take the store as an argument but get the funcref from self, we don't technically have the guarantee that the given store owns this funcref. So I think either this function should be unsafe because it relies on passing the correct StoreId in, or we need to get that StoreId from self somehow.

Wasmtime GitHub notifications bot (Jul 14 2025 at 18:45):

fitzgen created PR review comment:

Needs safety comment

Wasmtime GitHub notifications bot (Jul 14 2025 at 20:50):

alexcrichton updated PR #11229.

Wasmtime GitHub notifications bot (Jul 14 2025 at 20:51):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 14 2025 at 20:51):

alexcrichton created PR review comment:

Good point yeah, I meant to come back and fix this up but forgot to do so. It's a bit unfortunate how infectious the unsafety is here but I agree it's required to be sound regardless.

Wasmtime GitHub notifications bot (Jul 14 2025 at 20:51):

alexcrichton has enabled auto merge for PR #11229.

Wasmtime GitHub notifications bot (Jul 14 2025 at 21:29):

alexcrichton merged PR #11229.

Last updated: Dec 06 2025 at 06:05 UTC