Stream: git-wasmtime

Topic: wasmtime / PR #12563 Implement `serde` support for `Strin...

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:16):

fitzgen opened PR #12563 from fitzgen:serde-for-string-pool to bytecodealliance:main:

Depends on https://github.com/bytecodealliance/wasmtime/pull/12562

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:16):

fitzgen requested alexcrichton for a review on PR #12563.

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:16):

fitzgen requested wasmtime-core-reviewers for a review on PR #12563.

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:20):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:20):

alexcrichton created PR review comment:

Personally I'd say that this should use ? since while postcard might provide this guarantee a future deserializer might not, so in the spirit of being relatively flexible in core data structures I think it'd be good to propagate the error instead of assert here.

I also feel like it's conventionally a bit easier to reason about "always use ?" and sometimes there's a reserve for performance. Otherwise all .expect(...) needs to be double-checked against some reserve or some other condition nearby which can be a bit confusing

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:20):

alexcrichton created PR review comment:

These can be #[derive]?

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:23):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:23):

fitzgen created PR review comment:

while postcard might provide this guarantee a future deserializer might not

It is our own implementation of Deserialize for wasmtime_core::alloc::String that provides this guarantee. Does that change the calculus for you?

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:24):

fitzgen submitted PR review.

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:24):

fitzgen created PR review comment:

I've generally been avoiding derives to avoid the compile time hit -- not worth it?

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:25):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:25):

alexcrichton created PR review comment:

I suppose a bit, but in general I still feel like I'd lean towards ?-and-forget. I don't think there's any reasonable way we can expect everyone to keep all the various constraints in their heads about reservation/capacity/etc and it's far easier to just use ? on methods. If the ? is dynamically dead that doesn't seem any worse to me than .expect("...") being dynamically dead

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:26):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Feb 10 2026 at 22:26):

alexcrichton created PR review comment:

Oh no that seems pretty reasonable yeah. There are so few derive-compatible-impls in this crate I think it's reasonable to avoid for that reason

Wasmtime GitHub notifications bot (Feb 11 2026 at 01:06):

github-actions[bot] added the label wasmtime:api on PR #12563.

Wasmtime GitHub notifications bot (Feb 11 2026 at 19:19):

fitzgen updated PR #12563.

Wasmtime GitHub notifications bot (Feb 11 2026 at 19:19):

fitzgen has enabled auto merge for PR #12563.

Wasmtime GitHub notifications bot (Feb 11 2026 at 19:32):

fitzgen added PR #12563 Implement serde support for StringPool to the merge queue

Wasmtime GitHub notifications bot (Feb 11 2026 at 19:55):

fitzgen merged PR #12563.

Wasmtime GitHub notifications bot (Feb 11 2026 at 19:55):

fitzgen removed PR #12563 Implement serde support for StringPool from the merge queue

Last updated: Feb 24 2026 at 04:36 UTC