wit-component: Eagerly define all exported types #2091
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.