Stream: git-wasmtime

Topic: wasmtime / issue #4415 Output of `wit-component` doesn't ...

Wasmtime GitHub notifications bot (Jul 11 2022 at 15:27):

alexcrichton edited issue #4415:

Loading in a Component hits this unimplemented!() statement when the component was generated with wit-bindgen and wit-component. According to @alexcrichton this is a bug.

Test Case

I've created a repo. To recreate the example run ./run.sh.

Expected Results

The component loads.

Actual Results

Panic.

thread 'main' panicked at 'not implemented: component type export', /home/klim/.cargo/git/checkouts/wasmtime-41807828cb3a7a7e/a8ce7f1/crates/environ/src/component/translate.rs:743:17

Versions and Environment

Wasmtime version or commit: Latest git commit

Operating system: Fedora Linux

Architecture: x86-64

Notes

Maybe it'd be better to open this issue in the wit-bindgen repo.

Wasmtime GitHub notifications bot (Jul 11 2022 at 15:30):

alexcrichton commented on issue #4415:

Ok I've worked with this a bit and I'm unable to come to an immediate solution. @peterhuene you're likely interested in this as well. The problem here is that Wasmtime doesn't implement type exports because I don't know what those mean (https://github.com/WebAssembly/component-model/issues/12) and I don't know what the purpose of them are beyond the naming here. I naively tried to remove type exports in the wit-component tooling but that doesn't work because it requires types like flags to have a name which is currently lifted from the export name.

Overall I don't know what to do here. It's easy enough to simply ignore type exports in Wasmtime for now or I guess expose RTTI-style information about them. Otherwise though I'm personally uncomfortable continuing to bake in this "wouldn't it be nice to import/export types" scheme without having a clear direction for where this is going. In that sense I would prefer not to simply ignore the types in Wasmtime right now.

Do you have thoughts @peterhuene about how best to tackle this?

Wasmtime GitHub notifications bot (Jul 12 2022 at 18:52):

peterhuene commented on issue #4415:

Given that type imports aren't used in the tooling just yet, but type exports are used today to describe the component's interface(s), I think we should probably represent type exports in Wasmtime's API rather than ignoring them.

I would imagine you could use something like Component::exports (a conceptual analogous method to Module::exports) to view the component's exported types. In theory, you could generate bindings from this information.

For the instance representation, as type imports aren't important yet, we could probably erase type exports for now?

I'm also okay with ignoring type exports in Wasmtime for now if that's easier to do, but keeping the unimplemented! for type imports.

Wasmtime GitHub notifications bot (Jul 12 2022 at 18:53):

peterhuene edited a comment on issue #4415:

Given that type imports aren't used in the tooling just yet, but type exports are used today to describe the component's interface(s), I think we should probably represent type exports in Wasmtime's API rather than ignoring them.

I would imagine you could use something like Component::exports (a conceptual analogous method to Module::exports) to view the component's exported types. In theory, you could generate bindings from this information.

For the instance representation, as type imports aren't important yet, we could probably erase type exports for now?

I'm also okay with ignoring type exports in Wasmtime for now if that's easier to do (with a TODO: represent this eventually), but keeping the unimplemented! for type imports.

Wasmtime GitHub notifications bot (Jul 13 2022 at 14:04):

alexcrichton commented on issue #4415:

While that's probably the easiest solution I'm not sure that it's the best way forward myself. I don't understand why everything is exportable in the sense of what the purpose is beyond simply naming. If all we want is to name something then I think a name section or equivalent is a better option. Right now there are restrictions on *.wit naming and there are no restrictions on the export names.

I ideally want to stick on a trajectory to this all being in a final-ish state in terms of basics, which makes me wary of ignoring type exports or something like that for now.

Wasmtime GitHub notifications bot (Jul 13 2022 at 17:57):

peterhuene commented on issue #4415:

I don't really have a horse in the "how best to give types a name" debate from the proposal repo, to be honest, although I do think exporting types makes sense given its symmetry with type imports and more prescriptive than a custom section that can be stripped.

Indeed, the restrictions on names differing between the component model and wit could be problematic. I realize there is discussion to standardize wit as part of the component model, but I personally think that it should be just a separate representation that sits on top of the component model whereby if you name things according to wit's conventions, then you get to use wit-based bindings generators (thus _wit itself_ is specific to that _wit-based_ tooling). I don't know if that is a popular opinion or not, but I think the component model format itself must have a way to represent interfaces with full-fidelity and thus custom sections feel unsuited to that purpose.

That (needlessly) said, I think we should promptly come to some final conclusion on the utility of type exports in the proposal to move this forward; we shouldn't be blocking the testing of components generated with our tooling that currently uses type exports for the above stated purpose.

Wasmtime GitHub notifications bot (Jul 14 2022 at 14:10):

alexcrichton commented on issue #4415:

My hesitation on exports is that in addition to naming something it also implies runtime support. Given a hypothetical exports iterator from an instance you need to get some sort of runtime value for the type to poke at. Additionally I would symmetrically expect to be able to import a type (which is also something that doesn't make sense to me).

Overall the only purpose seems to be naming, not requiring the runtime bits for exports, so I don't know why we're using the export section for that. If a custom section doesn't sit well with others then we could have a "type name" section or similar which isn't a custom section which lists the names for types. I generally want to move away from the export section itself since we only need one of the features of the export section for this feature.

Wasmtime GitHub notifications bot (Jul 14 2022 at 17:41):

peterhuene commented on issue #4415:

I believe @lukewagner's intention post-MVP is to base support for resources on top of type imports, where the type bounds goes beyond equality to include subtyping. At that point type exports will need to be a thing anyway. I think this is all predicated on the need for components to share _the exact same type_ such that multiple components can pass around handles to the same thing. Luke, please correct me if I'm wrong here (which I like am).

If that's indeed the case, I don't see why we wouldn't use type exports now for the naming of types, at the cost of the some complexity in Wasmtime's component model API for something it won't really make use of today.

Wasmtime GitHub notifications bot (Jul 14 2022 at 17:42):

peterhuene edited a comment on issue #4415:

I believe @lukewagner's intention post-MVP is to base support for resources on top of type imports, where the type bounds goes beyond equality to include subtyping. At that point type exports will need to be a thing anyway. I think this is all predicated on the need for components to share _the exact same type_ such that multiple components can pass around handles to the same thing. Luke, please correct me if I'm wrong here (which I likely am :upside_down:).

If that's indeed the case, I don't see why we wouldn't use type exports now for the naming of types, at the cost of the some complexity in Wasmtime's component model API for something it won't really make use of today.

Wasmtime GitHub notifications bot (Jul 14 2022 at 17:44):

peterhuene edited a comment on issue #4415:

I believe @lukewagner's intention post-MVP is to base support for resources on top of type imports, where the type bounds goes beyond equality to include subtyping. At that point type exports will need to be a thing anyway. I think this is all predicated on the need for components to share _the exact same type_ such that multiple components can pass around handles to the same thing. Luke, please correct me if I'm wrong here (which I likely am :upside_down:).

If that's indeed the case, I don't see why we wouldn't use type exports now for the naming of types, at the cost of the some complexity in Wasmtime's component model API for something it won't really make use (yet).

Wasmtime GitHub notifications bot (Jul 14 2022 at 17:44):

peterhuene edited a comment on issue #4415:

I believe @lukewagner's intention post-MVP is to base support for resources on top of type imports, where the type bounds goes beyond equality to include subtyping. At that point type exports will need to be a thing anyway. I think this is all predicated on the need for components to share _the exact same type_ such that multiple components can pass around handles to the same thing. Luke, please correct me if I'm wrong here (which I likely am :upside_down:).

If that's indeed the case, I don't see why we wouldn't use type exports now for the naming of types, at the cost of the some complexity in Wasmtime's component model API for something it won't really make use of (yet).

Wasmtime GitHub notifications bot (Jul 14 2022 at 18:08):

alexcrichton commented on issue #4415:

If you're right, then I think that may make sense in the long term, but I don't want to bake in design decisions today based on a hypothetical future use case that we haven't sketched out fully. For example if resources are exported and imported then they should perhaps be a separate index space rather than part of the type index space.

With wit you can export the string type but I don't think you'll ever be able to import the string type (or why we'd want to allow that), which is why if all we want to do is name types then I think there should be a dedicated section for that rather than trying to wrap it all up in the import/export machinery.

Wasmtime GitHub notifications bot (Jul 14 2022 at 18:12):

peterhuene commented on issue #4415:

I'm certainly not opposed to having a dedicated (non-custom) section for naming types (vs. what we had before type exports where it was inline in the type section; that way runtimes can just skip that section entirely).

If we do go in that direction, I'd probably favor removing type imports and exports from the MVP until we've fleshed that out more too.

Wasmtime GitHub notifications bot (Jul 14 2022 at 18:21):

peterhuene commented on issue #4415:

In the meantime, I think the prudent course of action is to suppress type exports in wit-component and cargo-component, keeping them only for wit2wasm, until we figure out ultimately how to describe a component's interface in the binary encoding sufficient for bindings generation.

This should unblock running components generated with those tools in Wasmtime.

Wasmtime GitHub notifications bot (Jul 14 2022 at 23:31):

lukewagner commented on issue #4415:

Importing and exporting resource types is intended to be part of the MVP (and added to the component-model proposal just as soon as higher-priority things are out of the way). Having all resources imported from the host via (resource) type imports is a critical part of how host interfaces are virtualizable (and how a component can virtualize a host interface by defining and exporting a resource type imported by another component). Thus, in general, I think we definitely want imports/exports with the sort=type for at least resource types. Allowing all type definitions, instead of just resource type definitions, then just sortof kills a few birds with one stone. In addition to allowing non-resource-types to be named for bindings generation purposes, there are also some other use cases which take a bit more time to motivate and explain, but where type imports/exports serve a more substantial role; I could go into it now, but I don't want to go off on that tangent unless we all want to.

Wasmtime GitHub notifications bot (Jul 21 2022 at 00:50):

peterhuene closed issue #4415:

Loading in a Component hits this unimplemented!() statement when the component was generated with wit-bindgen and wit-component. According to @alexcrichton this is a bug.

Test Case

I've created a repo. To recreate the example run ./run.sh.

Expected Results

The component loads.

Actual Results

Panic.

thread 'main' panicked at 'not implemented: component type export', /home/klim/.cargo/git/checkouts/wasmtime-41807828cb3a7a7e/a8ce7f1/crates/environ/src/component/translate.rs:743:17

Versions and Environment

Wasmtime version or commit: Latest git commit

Operating system: Fedora Linux

Architecture: x86-64

Notes

Maybe it'd be better to open this issue in the wit-bindgen repo.

Last updated: Dec 23 2024 at 12:05 UTC