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.

Sign up for GitHub

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

Jump to bottom

feat: add support for stream with no <T> #1130

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

feat: add support for stream with no <T> #1130

wants to merge 3 commits into from

Conversation

rvolosatovs
Copy link
Member

@rvolosatovs rvolosatovs mentioned this pull request Jan 17, 2025
Draft
@rvolosatovs
build: update wasm-tools
7a8f757 
Signed-off-by: Roman Volosatovs <[email protected]>
@rvolosatovs rvolosatovs marked this pull request as ready for review January 17, 2025 16:05
@rvolosatovs
Copy link
Member Author

I'm not sure what the policy on pulling in bleeding-edge changes from https://github.com/bytecodealliance/wasm-tools is, I feel like I'll probably have to wait for a new release, but I'm also not sure how soon that would happen, so marking the PR ready for review with the git deps

@alexcrichton
Copy link
Member

Ah yes to merge this it'll need to be a crates.io-based dependency. There's some documentation on releases for wasm-tools but the tl;dr; is that it's on-demand.

I personally prefer to spread out releases where possible, so if it's ok I'd prefer that this were integrated into other in-development systems first to make sure it works and then once it's reasonably confident no major changes are needed here the cranks can be turned.

@dicej
Copy link
Collaborator

dicej commented Jan 17, 2025

@rvolosatovs I'm about to update my Wasmtime async branch to use both wasm-tools and wit-bindgen main branches to pull in other fixes, so we can use that branch as a staging area to make sure everything works together before we cut crates.io releases.

@dicej
Copy link
Collaborator

dicej commented Jan 17, 2025

@rvolosatovs I'm about to update my Wasmtime async branch to use both wasm-tools and wit-bindgen main branches to pull in other fixes, so we can use that branch as a staging area to make sure everything works together before we cut crates.io releases.

Actually, I'll use the wasm-tools main branch plus your wit-bindgen branch, since I'll need these changes to line up with the wasm-tools changes.

@dicej
Copy link
Collaborator

dicej commented Jan 17, 2025

@rvolosatovs I'm about to update my Wasmtime async branch to use both wasm-tools and wit-bindgen main branches to pull in other fixes, so we can use that branch as a staging area to make sure everything works together before we cut crates.io releases.

Actually, I'll use the wasm-tools main branch plus your wit-bindgen branch, since I'll need these changes to line up with the wasm-tools changes.

Actually, actually, I used the feat/stream-unit branch on my fork, which rebases your changes onto main so as to include #1129. And I've updated my async branch to support unit streams.

dicej added a commit to dicej/wasmtime that referenced this pull request Jan 17, 2025
@dicej
async/stream/future support for wasmtime-wit-bindgen
b52eddd 
I've split this out of bytecodealliance#9582 to make review easier.

This patch adds async/stream/future/error-context support to the host binding
generator, along with placeholder type and function definitions in the
`wasmtime` crate which the generated bindings can refer to.  See
https://github.com/dicej/rfcs/blob/component-async/accepted/component-model-async.md#componentbindgen-updates
for the design and rationale.

Note that I've added temporary `[patch.crates-io]` overrides in Cargo.toml until
bytecodealliance/wit-bindgen#1130 and
bytecodealliance/wasm-tools#1978 have been released.

Also note that we emit a `T: 'static` bound for `AsContextMut<Data = T>` when
generating bindings with `concurrent_imports: true`.  This is only because
`rustc` insists that the closure we're passing to
`LinkerInstance::func_wrap_concurrent` captures the lifetime of `T` despite my
best efforts to convince it otherwise.  Alex and I suspect this is a limitation
in the compiler, and I asked about it on the rust-lang Zulip, but we haven't
been able to determine a workaround so far.

Signed-off-by: Joel Dice <[email protected]>
@dicej dicej mentioned this pull request Jan 17, 2025
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees

@rvolosatovs rvolosatovs

Labels
None yet
Projects
Ship WASIp3
Status: In review
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@rvolosatovs @alexcrichton @dicej