Stream: git-wasmtime

Topic: wasmtime / issue #11705 support accessing the store in `b...

Wasmtime GitHub notifications bot (Sep 17 2025 at 08:51):

anlavandier opened issue #11705:

Feature

#11628 adds support for accessing the store in bindgen!-generated import function in traits. This is great but currently even when generating with async: false this is gated behind the component-model-async feature which is itself requires std. The proposed feature would be to un-gate the improvements of the aforementioned PR #11628 for synchronous imports.

Benefit

This would allow users using wasmtime in no_std embedded systems to also access the store in their generated import functions.

Implementation

I don't know all of the implications but the discussions in #11590 suggest that un-gating the Access struct would be a start.

Alternatives

Without this feature, no_std that need/want to access the store in their imports have to do so outside of the component-model.

Wasmtime GitHub notifications bot (Sep 17 2025 at 14:21):

alexcrichton added the wasm-proposal:component-model label to Issue #11705.

Wasmtime GitHub notifications bot (Sep 17 2025 at 14:21):

alexcrichton added the wasmtime:platform-support label to Issue #11705.

Wasmtime GitHub notifications bot (Sep 17 2025 at 14:47):

anlavandier edited issue #11705:

Feature

#11628 adds support for accessing the store in bindgen!-generated import function in traits. This is great but currently even when generating with async: false this is gated behind the component-model-async feature which is itself requires std. The proposed feature would be to un-gate the improvements of the aforementioned PR #11628 for synchronous imports.

Benefit

This would allow users using wasmtime in no_std embedded systems to also access the store in their generated import functions.

Implementation

I don't know all of the implications but the discussions in #11590 suggest that un-gating the Access struct would be a start.

Alternatives

Without this feature, no_std users that need/want to access the store in their imports have to do so outside of the component-model.

Wasmtime GitHub notifications bot (Sep 22 2025 at 15:07):

anlavandier commented on issue #11705:

@alexcrichton I looked briefly at the code base and it seems like the Access struct is pretty deeply intermixed with async functionality. After some testing, making the component-model-async feature no_std compatible is also probably not happening. Do you think that coming up with an AccessSync struct that only replicates what's needed from Access to work with imports: store functions and resources could be possible ?

Wasmtime GitHub notifications bot (Sep 24 2025 at 15:40):

alexcrichton commented on issue #11705:

Code-wise it's pretty intertwined right now yeah, but conceptually there shouldn't be any need to couple the two together. I'd rather not add a new type to the preexisting matrix of types and instead work on getting Access exposed even when component-model-async is disabled.

Last updated: Dec 06 2025 at 07:03 UTC