Skip to content

Handle complex types in assertion wrapper modules#152

Open
tlively wants to merge 1 commit into
cont-new-testsfrom
ref-cont-js-wrapper
Open

Handle complex types in assertion wrapper modules#152
tlively wants to merge 1 commit into
cont-new-testsfrom
ref-cont-js-wrapper

Conversation

@tlively
Copy link
Copy Markdown
Member

@tlively tlively commented May 14, 2026

Continuation types cannot be passed to JS, so assert_return actions must be implemented with WebAssembly wrapper modules when converting tests to JS. There is precedent for this with vector and exnref types. The difference for continuations is that they are defined types, so creating the wrapper modules with the correct import types requires arbitrarily complex type sections.

Add code to traverse and topologically sort the rec groups reachable from the type of an exported function or global, then map them back to surface syntax that can be emitted.

Continuation types cannot be passed to JS, so `assert_return` actions must be implemented with WebAssembly wrapper modules when converting tests to JS. There is precedent for this with vector and exnref types. The difference for continuations is that they are defined types, so creating the wrapper modules with the correct import types requires arbitrarily complex type sections.

Add code to traverse and topologically sort the rec groups reachable from the type of an exported function or global, then map them back to surface syntax that can be emitted.
@tlively tlively requested a review from rossberg May 14, 2026 01:01
@rossberg
Copy link
Copy Markdown
Member

Oh right, I hadn't realised that you need the type section, too!

I appreciate that you implemented all the machinery to minimise it. :) But is that complexity actually needed? Why not just copy the type section as is? For just driving a test, I don't think it matters whether the wrapper has redundant definitions in it, and the type sections in the test suite won't be huge.

@tlively
Copy link
Copy Markdown
Member Author

tlively commented May 14, 2026

Yes, I had the same thought. The problem is that the type section we have is in terms of recursive DefT, not type indices. Mapping the entire type section back to using type indices is no easier than just doing so for the types we need. (Or maybe there's a shortcut I didn't find?)

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