Skip to content

Conversation

@ricochet
Copy link
Contributor

@ricochet ricochet commented Jan 6, 2026

Update wasmtime's WASI implementation from version
0.3.0-rc-2025-09-16 to 0.3.0-rc-2026-01-06, using wkg for WIT vendoring.

This involves API changes in clocks and HTTP.

By using wkg here, we are also now pointing at the WASI monorepo (closes #9419).

@ricochet ricochet requested review from a team as code owners January 6, 2026 19:17
@ricochet ricochet requested review from fitzgen and removed request for a team January 6, 2026 19:17
@alexcrichton alexcrichton requested review from alexcrichton and removed request for fitzgen January 6, 2026 19:44
@ricochet ricochet force-pushed the p3-rc-01-6 branch 2 times, most recently from eba6502 to 71eaef5 Compare January 8, 2026 18:59
@alexcrichton
Copy link
Member

I did some splicing/editing/editorializing in #12327. I'm happy to land that (tried to make sure to perserve your authorship) but if you'd prefer to morph those changes back in here I'm happy to merge this as well. Whatever's easiest for you, let me know!

ricochet and others added 3 commits January 13, 2026 07:31
Update wasmtime's WASI implementation from version
0.3.0-rc-2025-09-16 to 0.3.0-rc-2026-01-06, using wkg for WIT vendoring.

This involves API changes in clocks and HTTP.
This can have a loss in precision so this shuffles around some types to
ensure that `try_into` and friends are always used instead of `as`. This
changes the source-of-truth for timestamps to be `i64` seconds so WASIp2
is the odd-one-out that can't represent negative timestamps.
@alexcrichton
Copy link
Member

If you don't mind @ricochet I did some merging/rebasing of this after #12327 landed and I've also handled some other thoughts I had related to the i64 switch for datetime.

@alexcrichton
Copy link
Member

Assuming @ricochet is ok with the changes I've made here, @pchickey would you also be ok for reviewing the changes I made? I don't want to self-approve my changes related to clocks.

Copy link
Contributor Author

@ricochet ricochet left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I debated making the as change myself since without that fix, we risk the conversion of seconds as i64 to silently truncate values, and a potential overflow in system_clock::Instant conversion.

Body of the changes LGTM although I see CI is failing.

@github-actions github-actions bot added the wasi Issues pertaining to WASI label Jan 13, 2026
* Rename `proxy` module to `service` to reflect the WIT world.
* Adjust the middleware test to using the `middleware` world.
@alexcrichton alexcrichton requested review from pchickey and removed request for alexcrichton January 13, 2026 19:45
@alexcrichton
Copy link
Member

Actually, apologies for the notification overload Pat, I realized that due to the WASIp3 adjacent things @dicej would be a good candidate too, so I'm going to switch to Joel to confirm I didn't get anything wrong here

@alexcrichton alexcrichton requested review from dicej and removed request for pchickey January 13, 2026 20:00
Copy link
Contributor

@dicej dicej left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM; just one question inline.

wit_bindgen::StreamResult,
};

wit_bindgen::generate!({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reason for generating the bindings locally here? I.e. what changed such that using the bindings generated in test_programs/src/p3/mod.rs is no longer feasible?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I tried that initially but it's a wit-bindgen bug. The way the exported macros are generated, namespaced, etc, means that you can't generate, even in separate modules in the same crate, two worlds where the worlds overlap in exports. The middleware/service worlds overlap in their export of wasi:http/handler meaning that putting the two in the same crate would clash. I'll file a bug over on the wit-bindgen side of things for this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifically, this issue

@alexcrichton alexcrichton added this pull request to the merge queue Jan 13, 2026
Merged via the queue into bytecodealliance:main with commit 1cc0bcf Jan 13, 2026
45 checks passed
alexcrichton added a commit to alexcrichton/wasmtime that referenced this pull request Jan 14, 2026
* feat(p3)!: vendor 0.3.0-rc-2026-01-06

Update wasmtime's WASI implementation from version
0.3.0-rc-2025-09-16 to 0.3.0-rc-2026-01-06, using wkg for WIT vendoring.

This involves API changes in clocks and HTTP.

* Handle some review comments

* Update WASI implementations to avoid `as`

This can have a loss in precision so this shuffles around some types to
ensure that `try_into` and friends are always used instead of `as`. This
changes the source-of-truth for timestamps to be `i64` seconds so WASIp2
is the odd-one-out that can't represent negative timestamps.

* Flag expected WASI failures

* Get wasi:http tests working again

* Rename `proxy` module to `service` to reflect the WIT world.
* Adjust the middleware test to using the `middleware` world.

---------

Co-authored-by: Alex Crichton <alex@alexcrichton.com>
alexcrichton added a commit that referenced this pull request Jan 14, 2026
* Switch to using `wkg` for most WIT vendoring (#12327)

* feat(p3)!: vendor 0.3.0-rc-2026-01-06

Update wasmtime's WASI implementation from version
0.3.0-rc-2025-09-16 to 0.3.0-rc-2026-01-06, using wkg for WIT vendoring.

This involves API changes in clocks and HTTP.

* ci: install wkg in monolith_checks

* Revert back to original WIT versions

Also refactor the script a bit to avoid too bash-isms and hopefully make
it a bit more straightforward what's happening.

---------

Co-authored-by: Bailey Hayes <bailey@cosmonic.com>

* feat(p3)!: vendor 0.3.0-rc-2026-01-06 (#12250)

* feat(p3)!: vendor 0.3.0-rc-2026-01-06

Update wasmtime's WASI implementation from version
0.3.0-rc-2025-09-16 to 0.3.0-rc-2026-01-06, using wkg for WIT vendoring.

This involves API changes in clocks and HTTP.

* Handle some review comments

* Update WASI implementations to avoid `as`

This can have a loss in precision so this shuffles around some types to
ensure that `try_into` and friends are always used instead of `as`. This
changes the source-of-truth for timestamps to be `i64` seconds so WASIp2
is the odd-one-out that can't represent negative timestamps.

* Flag expected WASI failures

* Get wasi:http tests working again

* Rename `proxy` module to `service` to reflect the WIT world.
* Adjust the middleware test to using the `middleware` world.

---------

Co-authored-by: Alex Crichton <alex@alexcrichton.com>

* Update wit-bindgen (#12329)

Keeping up-to-date and looking to unblock #12327

---------

Co-authored-by: Bailey Hayes <bailey@cosmonic.com>
Co-authored-by: Bailey Hayes <ricochet@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasi Issues pertaining to WASI

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Using wkg to manage wit dependencies

3 participants