feat: support component type introspection

[rvolosatovs]

This allows for embedders to introspect the component type to e.g. construct Vals of complex types expected by the components at runtime.
Closes #7726
I'll work on adding a simple test once I verify this covers my own use case

cc @alexcrichton

[alexcrichton]

Thanks for this! At a high level this looks pretty good, although there's two parts of this I'd have a comment on. One is that from a component model point of view an instance does not have imports, only exports and their types. In that sense Instance::import_types is not necessarily a component-model-based primitive here, and that's where Component::imports() would show up instead. I suspect though that this is critical to your use case, though.

To handle this I might recommend a slightly updated approach. From a Linker it should be possible to acquire a types::Component from a component::Component. This would synthesize the "InstanceType" data internally required to get a Handle which is more-or-less a glorified resource mapping. That would be a built-in way of asking "If I instantiate this component using this linker what resource would correspond to this import?" (happy to jump on a call to explain this more too)

The second thing is mostly minor API adjustments here and there, but nothing requiring major refactoring, so I'll note those later.

[rvolosatovs]

Thanks for this! At a high level this looks pretty good, although there's two parts of this I'd have a comment on. One is that from a component model point of view an instance does not have imports, only exports and their types. In that sense Instance::import_types is not necessarily a component-model-based primitive here, and that's where Component::imports() would show up instead. I suspect though that this is critical to your use case, though.

To handle this I might recommend a slightly updated approach. From a Linker it should be possible to acquire a types::Component from a component::Component. This would synthesize the "InstanceType" data internally required to get a Handle which is more-or-less a glorified resource mapping. That would be a built-in way of asking "If I instantiate this component using this linker what resource would correspond to this import?" (happy to jump on a call to explain this more too)

The second thing is mostly minor API adjustments here and there, but nothing requiring major refactoring, so I'll note those later.

Thanks for the quick response, is this what you mean 56f68d5 ?
Otherwise, happy to jump on a call tomorrow

[alexcrichton]

Yep exactly!

I'll go over this with a more fine-toothed comb tonight so you can have a review for when you wake up

[github-actions]

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:api"

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

• peterhuene: wasmtime:api

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

Learn more.

[rvolosatovs]

@alexcrichton I've studied the wasmtime_environ implementation a little bit and looks like I came up with a solution that makes sense (after all types are resolved, "synthesize" a TypeComponent and store in ComponentTypes on finish to acquire a type index, which is then propagated further).
I had to also add the type index info to exports, which was missing.

I've added a test case reusing a big chunk of the dynamic::everything component (it does not actually contain everything, but hopefully this is "good enough"). PTAL

[rvolosatovs]

@alexcrichton although in our conversation yesterday we discussed that the static module and "instance item bag" case type indexes should be constructed somewhere along the way and thrown out, that did not seem to be the case in all occurrences, therefore in the proposed approach the static module type is "synthesized" from compiled artifacts on finish for cases where instance type is not assigned yet, that is also done recursively in the same step.
Note the updated test case - I duplicated, for the most part, test cases that were causing panics during development due to type not being available (in particular, the "instance item bag" case)

[alexcrichton]

Looks great to me, thanks!

[sehz]

Nice work!