Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wit-component: Eagerly define all exported types #2091

Merged
merged 2 commits into from
Mar 11, 2025

Conversation

alexcrichton
Copy link
Member

This commit fixes an assertion failure found via the fuzzing of wit-component. The basic problem is that the task.return intrinsic, and other async intrinsics, need to refer to asynchronous types to be declared, but while defining some types can be done lazily it's not always easy to do so. Currently all types are defined lazily as the intrinsic is declared, but this panics when referring to types defined in other interfaces as the current type-defining machinery (rightfully) panics in this situation.

The fix applied in this commit is to update the part of encoding which eagerly defines type information for imported intrinsics, previously just resources, to now also define all types for exported interfaces. This ensures that all defined types necessary will already be available by the time that intrinsics are defined. Overall wit-component is definitely in need of cleaning up how types are defined, but for now that's left for a future refactoring...

Otherwise some test expectations are also changing here in this commit as types were shuffled around and a few dead types were also generated.

This commit fixes an assertion failure found via the fuzzing of
wit-component. The basic problem is that the `task.return` intrinsic,
and other async intrinsics, need to refer to asynchronous types to be
declared, but while defining some types can be done lazily it's not
always easy to do so. Currently all types are defined lazily as the
intrinsic is declared, but this panics when referring to types defined
in other interfaces as the current type-defining machinery (rightfully)
panics in this situation.

The fix applied in this commit is to update the part of encoding which
eagerly defines type information for imported intrinsics, previously
just resources, to now also define all types for exported interfaces.
This ensures that all defined types necessary will already be available
by the time that intrinsics are defined. Overall `wit-component` is
definitely in need of cleaning up how types are defined, but for now
that's left for a future refactoring...

Otherwise some test expectations are also changing here in this commit
as types were shuffled around and a few dead types were also generated.
@alexcrichton alexcrichton requested a review from dicej March 11, 2025 15:09
@alexcrichton alexcrichton added this pull request to the merge queue Mar 11, 2025
Merged via the queue into bytecodealliance:main with commit 5704953 Mar 11, 2025
31 checks passed
@alexcrichton alexcrichton deleted the fix-fuzz-panic branch March 11, 2025 19:29
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