Stream: git-wasmtime

Topic: wasmtime / PR #10610 Pch/typecheck componentfunc


view this post on Zulip Wasmtime GitHub notifications bot (Apr 17 2025 at 22:06):

pchickey opened PR #10610 from bytecodealliance:pch/typecheck_componentfunc to bytecodealliance:main:

<!--
Please make sure you include the following information:

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

view this post on Zulip Wasmtime GitHub notifications bot (Apr 17 2025 at 22:16):

pchickey updated PR #10610.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 17 2025 at 22:22):

pchickey updated PR #10610.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 17 2025 at 22:37):

pchickey updated PR #10610.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 17 2025 at 22:49):

pchickey updated PR #10610.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 00:30):

pchickey updated PR #10610.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 15:21):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 15:21):

alexcrichton created PR review comment:

Technically this isn't possible, type-checking at the component level. Components import abstract resources which don't match any types defined in Rust, which is what would be passed in as the type parameters here. The type-check can only be done once you have an InstancePre or Linker where the actual resource types are all assigned and we can match up the host-provided resources with our expectations.

That being said I do like the property that FooIndices is all you need to "quickly load the thing" and as such represents a type-checked version of the component. Given that one options is to switch this to using InstancePre<T> instead of &Component as a construction argument. In doing so though we're not really prepared to have that working. The problem is that we'd have to prevent crossing FooIndices values by accident. Right now export indices are intrinsically tied to a Component which has a unique ID, but not a Linker which does not have a unique ID. That means you could technically create a FooIndices with one linker and then extract exports from a component created with another linker, and if we skip the type-checks with unsafe (which I assume this PR is building towards) that could be memory-unsafe.

That might be solvable though by putting a unique ID in linkers and plumbing that to InstancePre and Instance which is checked.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 15:50):

pchickey submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 15:50):

pchickey created PR review comment:

The type-check can only be done once you have an InstancePre or Linker where the actual resource types are all assigned and we can match up the host-provided resources with our expectations.
Agreed, thats exactly where I got to - something representing that resource assignment (__internals::InstanceType) needs to be passed into ComponentFunc::typecheck as an argument. I got pretty tangled up with InstanceType because it borrows arcs of Store's type tables instead of cloning the arcs, so I am going to either change the structure or make a variant of it that owns the arcs.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 15:50):

pchickey edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 15:54):

pchickey edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 20:26):

pchickey updated PR #10610.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 20:28):

pchickey updated PR #10610.


Last updated: Dec 06 2025 at 07:03 UTC