Skip to content

Error on single items WIT can't express instead of panicking - #2815

Open
sansmoraxz wants to merge 6 commits into
bytecodealliance:mainfrom
sansmoraxz:wit-decode/2-items
Open

sansmoraxz wants to merge 6 commits into
bytecodealliance:mainfrom
sansmoraxz:wit-decode/2-items

Conversation

@sansmoraxz

Copy link
Copy Markdown
Contributor

Part 2/x of a series of PRs backporting fixes and workarounds discovered via fuzzing

Decoding panicked on components with items WIT has no form for, such as an imported function type, a function or type named like a:b/c, a method of a resource from another interface, or a component-type section that isn't one world. These now return "cannot represent this component in WIT" errors.

WIT types are value types and resources. Decoding panicked on a
component that imports a component, instance or function type, or has
an instance exporting one, and now returns an error.
Only interfaces have names like `a:b/c` in WIT. Decoding panicked on a
function imported under such a name, and now returns an error.
Only interfaces have names like `a:b/c` in WIT. Decoding accepted a type
imported or exported under such a name and printed `type a:b/c = ...`,
which doesn't parse.
WIT puts a resource's constructor, methods and static functions in the
interface that defines it. Decoding panicked on an interface with
`[method]r.f` where `r` is only a `use` of another interface's resource,
and now returns an error.
A core module's `component-type` custom section holds a component type
with no imports and one world as its only export, as `wit-component`
writes it. Decoding panicked on one with imports, with other than one
export, or exporting something that isn't a world, and now returns an
error.
@sansmoraxz
sansmoraxz requested a review from a team as a code owner November 11, 2026 08:45
@sansmoraxz
sansmoraxz requested review from alexcrichton and removed request for a team November 11, 2026 08:45
Decoding now matches on whether a function belongs to a resource and
looks up the resource only in that branch, so the function kind no
longer unwraps an `Option`. The impossible states (a resource function
without a resource, an async accessor, a constructor with an accessor)
return errors rather than panicking, and the error for a function not
next to its resource now names the resource.
;; (component (type $c (component (export "a:b/w" (instance)))) (export "w" (type $c)))

(module
(@custom "component-type:x" "\00\61\73\6d\0d\00\01\00\07\10\01\41\02\01\42\00\04\00\05\61\3a\62\2f\77\05\00\0b\07\01\00\01\77\03\00\00\00\16\0e\63\6f\6d\70\6f\6e\65\6e\74\2d\6e\61\6d\65\01\05\03\01\00\01\63")

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.

I'm a bit wary of tests like this which are otherwise suitable for the text format but due to tooling limitations require the binary format. If you're up for it this might make sense as a new CLI flag to wasm-tools component embed to create this component, but otherwise I think it's ok to drop the binary-style tests for now.

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.

I think technically this is supposed to be an invalid component, not just an invalid-WIT component. I think it's a bug in wasmparser's valiator that this is accepted

This branch has not been deployed

No deployments
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