wasmtime / PR #10760 Add `T: 'static` to `Store<T> · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #10760 Add `T: 'static` to `Store<T>

Wasmtime GitHub notifications bot (May 09 2025 at 21:59):

alexcrichton requested pchickey for a review on PR #10760.

Wasmtime GitHub notifications bot (May 09 2025 at 21:59):

alexcrichton opened PR #10760 from alexcrichton:add-static-bound to bytecodealliance:main:

Since the beginning the T type parameter on Store<T> has had no bounds on it. This was intended for maximal flexibility in terms of what embedders place within a Store<T> and I've personally advocated that we need to keep it this way. In the development of the WASIp3 work, however, I've at least personally reached the conclusion that this is no longer tenable and proceeding will require adding a 'static bound to data within a store.

Wasmtime today [already] carries unsafe transmutes to work around this lack of 'static bound, and while the number of unsafe parts is relatively small right now we're still fundamentally lying to the compiler about lifetime bounds internally. With the WASIp3 async work this degree of "lying" has become even worse. Joel has written up some examples [on Zulip] about how the Rust compiler is requiring 'static bounds in surprising ways. These patterns are cropping up quite frequently in the WASIp3 work and it's becoming particularly onerous maintaining all of the unsafe and ensuring that everything is in sync.

In the WASIp3 repository I've additionally [prototyped a change] which would additionally practically require T: 'static in more locations. This change is one I plan on landing in Wasmtime in the near future and while its main motivations are for enabling WASIp3 work it is also a much nicer system than what we have today, in my opinion.

Overall the cost of not having T: 'static on Store<T> is effectively becoming quite costly, in particular with respect to WASIp3 work. This is coupled with all known embedders already using T: 'static data within a Store<T> so the expectation of the impact of this change is not large. The main downside of this change as a result is that when and where to place 'static bounds is sort of a game of whack-a-mole with the compiler. For example I changed Store<T> to require 'static here, but the rest of the change is basically "hit compile until rustc says it's ok". There's not necessarily a huge amount of rhyme-or-reason to where 'static bounds crop up, which can be surprising or difficult to work with for users.

In the end I feel that this change is necessary and one we can't shy away from. If problems crop up we'll need to figure out how to thread that needle at that time, but I'm coming around to thinking that T: 'static is just a fundamental constraint we'll have to take on at this time. Maybe a future version of Rust that fixes some of Joel's examples (if they can be fixed, we're not sure of that) we could consider relaxing this but that's left for future work.

[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611
[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072
[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158

Wasmtime GitHub notifications bot (May 09 2025 at 21:59):

alexcrichton requested wasmtime-core-reviewers for a review on PR #10760.

Wasmtime GitHub notifications bot (May 09 2025 at 21:59):

alexcrichton requested wasmtime-default-reviewers for a review on PR #10760.

Wasmtime GitHub notifications bot (May 09 2025 at 22:00):

alexcrichton updated PR #10760.

Wasmtime GitHub notifications bot (May 09 2025 at 22:09):

alexcrichton updated PR #10760.

Wasmtime GitHub notifications bot (May 09 2025 at 22:13):

dicej submitted PR review.

Last updated: Dec 06 2025 at 06:05 UTC