wasmtime-wit-bindgen: Typecheck exports at {Foo}Indices construction

[pchickey]

Based on #10621

Currently, in bindgen-emitted component wrappers, the existence of export functions is checked at the construction of the {interface-name}Indices struct, but each export function is only finally typechecked on their invocation in {interface-name}::call_{func-name}.

The goal of this PR is to typecheck component exports at the construction of Indices. This is desirable because it gives a type error as early as possible - when using {interface-name}Indices by way of {interface-name}Pre, this can be performed with only an InstancePre, where the creation of an InstancePre requires only a Component and Linker, and typechecks all of the Component's imports. So, really, this is about getting exports on parity with imports.

Closes #9155 . I've worked around this with ugly hacks in embeddings for 2 different employers now and I'm not about to do it for a third.

Addition to Wasmtime

component::types::ComponentFunc has a new method typecheck<Params, Returns>(&self, instance_type: &InstanceType) -> Result<()>. The underlying typecheck performed here is the exact same one performed in Func::typed<Params, Returns>(&self, store: impl AsContextMut) -> Result<()>, except rather than the type information coming out of the store, its provided by the InstanceType.

This addition is a pub interfaces but marked #[doc(hidden)] to make them "internal", because the prior art was that InstanceType and is internal, and there are no other public interfaces for retrieving InstanceType or typechecking, with the sole exception of Func::typed. I think that we should consider making these documented public interfaces, but I'll leave that to a future PR unless requested.

Changes to wasmtime-wit-bindgen

The resources-import test case demonstates the extent of the changes: https://github.com/bytecodealliance/wasmtime/pull/10610/files#diff-0b0815115f3addd488fbf1f032466f210b9fcd29ec42f4b4a777e58f80abba16

• Since typechecking information is available from the InstancePre (thanks to wasmtime component: get InstancePre from Instance #10621), we can unify the two variations on constructing an Indices struct: there is now a single constructor fn new<T>(_instance_pre: InstancePre<T>) -> Result<Self>. Deduplicating this eliminates both generated code and complexity in the generator.
• The new sigular constructor uses _instance_pre.component() to lookup exports (both their index and their ComponentItem), and _instance_pre.instance_type() is used to typecheck the export.
• Each place an export index is retrieved for a function, .get_export_index has been substituted out with .get_export, and the returned ComponentItem is checked to be a ComponentItem::ComponentFunc(func), and then func.typecheck is invoked with the type argument corresponding to the TypedFunc type parameters.

Future work

Each export func is typechecked again in its bindgen call_{funcname} function, in which the Func member owned by the typed instance {Foo} struct is cast to a TypedFunc with the specific type parameters bindgen keeps track of for each func. Since the {Foo} struct is created from a {Foo}Indices, we can guarantee that the export funcs have been typechecked against a given Linker or Store, so we could potentially elide the repeated typecheck there, and make an unchecked cast to TypedFunc instead. (TypedFuncs are not stored in the {Foo} struct at least in part because their type parameters may use &'a ... which only apply to the site of the call, and not to the storage of that member in {Foo}. The for<'a> trick only works for trait objects, not concrete types like TypedFunc.)

[alexcrichton]

I'm a bit concerned about #10616 and the cost implications of having more Arc-clones on lifting/lowering paths, and after reading over this more I've got a possibilty which I forget if we already talked about and/or whether you tried, so let me know if I sound like a broken record. Could the various *Indices constructors take a &InstancePre<T> instead of a &Component? That way we could refactor the internals of InstancePre<T> to hold whatever is necessary to cheaply create the InstanceType<'_> I think?

[pchickey]

Thanks, I'll explore that now!

[pchickey]

I addressed the concerns above and rewrote the description accordingly.