Skip to content

Conversation

@alexcrichton
Copy link
Member

This commit changes wit-defined functions to have precisely one return
value instead of a list of return values. This matches the upstream
component-model draft specification and canonical ABI. The main fallout
here is that the spidermonkey tests stopped testing multiple-returns
since while multi-value was implemented struct lifting/lowering is not
yet implemented. Otherwise this is relatively straightforward although
there are a few gotchas here and there as some language like JS, Python,
and C don't have native tuple types and we still want to generate
reasonable-ish code.

@alexcrichton
Copy link
Member Author

Note that this is stacked on #205 and #204, both of which are prerequisites for this to work.

This commit changes wit-defined functions to have precisely one return
value instead of a list of return values. This matches the upstream
component-model draft specification and canonical ABI. The main fallout
here is that the spidermonkey tests stopped testing multiple-returns
since while multi-value was implemented struct lifting/lowering is not
yet implemented. Otherwise this is relatively straightforward although
there are a few gotchas here and there as some language like JS, Python,
and C don't have native tuple types and we still want to generate
reasonable-ish code.
@alexcrichton alexcrichton merged commit 2f422f8 into bytecodealliance:main Apr 22, 2022
@alexcrichton alexcrichton deleted the function-one-return branch April 22, 2022 13:58
willemneal pushed a commit to theahaco/wit-bindgen that referenced this pull request May 31, 2022
This commit changes wit-defined functions to have precisely one return
value instead of a list of return values. This matches the upstream
component-model draft specification and canonical ABI. The main fallout
here is that the spidermonkey tests stopped testing multiple-returns
since while multi-value was implemented struct lifting/lowering is not
yet implemented. Otherwise this is relatively straightforward although
there are a few gotchas here and there as some language like JS, Python,
and C don't have native tuple types and we still want to generate
reasonable-ish code.
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