wasm-encoder: add ComponentBuilder::instantiate_exports

[zacharywhitley]

The core-level analogue core_instantiate_exports already exists on
ComponentBuilder and mirrors the Instance::FromExports variant of
the core instance section. The component-level side had no equivalent:
ComponentInstanceSection::export_items is public but only reachable
through the manual section-append path, not the builder facade.

This adds instantiate_exports next to instantiate so callers
rebuilding a component structurally from a parsed one can round-trip
ComponentInstance::FromExports the same way core-level
Instance::FromExports already round-trips.

Signature

Mirrors core_instantiate_exports — same (&'a str, K, u32) triples,
just with ComponentExportKind in the kind slot instead of
ExportKind:

pub fn instantiate_exports<'a, E>(
    &mut self,
    debug_name: Option<&str>,
    exports: E,
) -> u32
where
    E: IntoIterator<Item = (&'a str, ComponentExportKind, u32)>,
    E::IntoIter: ExactSizeIterator,
{
    self.component_instances().export_items(exports);
    self.instances.add(debug_name)
}

Motivation

A component optimizer that reads a component with wasmparser and
re-emits it via ComponentBuilder needs to round-trip every
ComponentInstance variant. Instantiate was already covered by
ComponentBuilder::instantiate; FromExports was the missing case.
The public alternative was dropping down to
ComponentInstanceSection::export_items and manually appending the
section, bypassing the builder's index-space bookkeeping — which
defeats the point of using the builder.

Alternatives

• Expose the builder's internal component_instances() accessor:
  wider surface area than needed and doesn't match the pattern
  established by core_instantiate_exports.
• Require callers to use the raw section API: works but requires
  duplicating the builder's index-space accounting.

The chosen shape sticks to the precedent already set for the core
side.

[alexcrichton]

Thanks for the PR, and looks like a rustfmt is needed to get CI passing. Also please make sure to review our AI tool usage policy, for a change like this a small new function doesn't need such a large PR description

[zacharywhitley]

Sorry about that. Damn things are a little too enthusiastic to post a PR before I can review it. I really wish they'd add something that would queue so it couldn't send them out before review. "Let me just go ahead and submit that PR.....beep bop-boop!" nooooo!!! :)

[cfallin]

Sorry about that. Damn things are a little too enthusiastic to post a PR before I can review it. I really wish they'd add something that would queue so it couldn't send them out before review. "Let me just go ahead and submit that PR.....beep bop-boop!" nooooo!!! :)

FYI, just to make the point more explicit: automated posting of code that has not been reviewed by a human is even more against our policies than the lengthy LLM-generated description is. (In this case it's a trivial function, but the process is important here.)

I say this because your wording seems to imply somehow that this is not in your control ("I wish they'd add..."). I'd recommend either removing your bot's GitHub token or setting a hard blocker on creating PRs to Bytecode Alliance repos in whatever permissions system you have until you can work out why this slipped through. If we otherwise have an account that is posting AI-authored content, unreviewed by humans, with a human admitting they don't have full control of it, then this would have to go to the TSC for further action. Thanks!

[zacharywhitley]

I appreciate that. I was just highlighting that it's far too easy to have happen and making a joke out of it

[zacharywhitley]

On that note I think WebAssembly should be used more often for AI agent sanboxing. It could possibly have prevented the recent OpenAI/HF incident.