Skip to content

fix: substituted_component_type panic on guest-exported resources#13608

Merged
alexcrichton merged 2 commits into
bytecodealliance:mainfrom
rvolosatovs:fix/substituted_component_type
Jun 10, 2026
Merged

fix: substituted_component_type panic on guest-exported resources#13608
alexcrichton merged 2 commits into
bytecodealliance:mainfrom
rvolosatovs:fix/substituted_component_type

Conversation

@rvolosatovs

@rvolosatovs rvolosatovs commented Jun 10, 2026

Copy link
Copy Markdown
Member

I've encountered a panic working with guest-exported resources and Linker::substituted_component_type:

thread 'drives_score_utxo_resource' (8643070) panicked at /Users/rvolosatovs/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasmtime-45.0.1/src/runtime/component/matching.rs:208:27:
index out of bounds: the len is 0 but the index is 0

I had an LLM debug and add a test, which fails on current main with:


thread 'component_model::dynamic::substituted_component_type_with_exported_resource' (8668306) panicked at crates/wasmtime/src/runtime/component/matching.rs:208:27:
index out of bounds: the len is 0 but the index is 0

Other than me changing the commit message titles (and opening this PR/writing the description), this contribution is entirely LLM-generated, but reviewed by me.

The fix itself is a one-line change, which seems correct to me.
The analysis added by the LLM in the commits seems valid.
Test seems to make sense - I guess we could make it shorter, but I'll leave this up to reviewers to decide.

This is my first LLM-assisted contribution to Wasmtime, I belive it's compliant with https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.md, but please let me know if I have missed something.

`Linker::substituted_component_type` builds a `types::Component` whose
resource substitution map is `Some(..)` but only covers the component's
*imported* resources. Introspecting an exported function that references
an *exported* (non-imported) resource then panics with an
index-out-of-bounds, because `InstanceType::resource_type` hard-indexes
that partial map (`matching.rs`) instead of falling back to treating an
absent resource as uninstantiated.

This adds a test that builds a component exporting a resource plus a
constructor returning `own<t>` and a method taking `borrow<t>`, then
walks the introspected function types via `substituted_component_type`.
It panics today (index out of bounds) and will pass once the resolver
falls back gracefully.

Assisted-by: claude:claude-opus-4-8
`Linker::substituted_component_type` constructs the introspection type
with `resources: Some(&cx.imported_resources)`, a map that only contains
the component's *imported* resources. `InstanceType::resource_type`
previously hard-indexed that map (`self.resources.map(|t| t[ty])`), so
resolving a resource that is not in the map -- e.g. a resource the
component *exports* -- panicked with an index-out-of-bounds whenever an
exported function's params/results referenced it.

Fix this by using a fallible lookup and falling back to
`ResourceType::uninstantiated` when the resource is absent from the map,
exactly as the `resources: None` path already does. This is the
semantically correct behavior: a resource that has no substitution is
"not (yet) instantiated", which is also what `Component::component_type()`
relies on (it passes `resources: None`). With this fix the same safe,
public introspection API no longer panics depending on which (also
public) API produced the `types::Component`.

Assisted-by: claude:claude-opus-4-8
@rvolosatovs rvolosatovs requested a review from a team as a code owner June 10, 2026 12:36
@rvolosatovs rvolosatovs requested review from dicej and removed request for a team June 10, 2026 12:36

@alexcrichton alexcrichton left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

The only mild comment I'd have is that LLMs tend to be a bit too verbose in tests insofar as they try to document the exact state of the world before a test was added and when it was added, so the comment basically becomes irrelevant after a test lands. Not a huge thing though, so no worries.

@alexcrichton alexcrichton added this pull request to the merge queue Jun 10, 2026
Merged via the queue into bytecodealliance:main with commit 5b77e16 Jun 10, 2026
51 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants