dyslexicsteak opened PR #15025 from dyslexicsteak:compose-in-memory to bytecodealliance:main:
Compose the main Wasm and its compile-time builtins directly with
wasm_compose::graph::CompositionGraphinstead of writing them to a temporary directory and running the file-basedComponentComposer. Only builtins registered on theCodeBuildercan be composed in.This also skips composition when the main Wasm imports no builtin, and drops the
tempfiledependency of thecompile-time-builtinsfeature.This resolves a security issue and fixes various filesystem path related bugs and also adds tests with more realistic name inputs.
Fixes #15024.
dyslexicsteak removed the review request for wasmtime-core-reviewers from PR #15025.
dyslexicsteak requested wasmtime-core-reviewers for a review on PR #15025.
dyslexicsteak requested dicej for a review on PR #15025.
github-actions[bot] added the label wasmtime:api on PR #15025.
:memo: fitzgen submitted PR review:
Thanks! Overall looks good, but a few things we should address before merging below.
:speech_balloon: fitzgen created PR review comment:
This comment seems like it belongs on top of
let label = ...below, rather than here.
:speech_balloon: fitzgen created PR review comment:
This seems unnecessary?
:speech_balloon: fitzgen created PR review comment:
I think this means that we will define and instantiate every builtin, even if it isn't used, which I believe would be a regression from our current behavior, and matters since it might make a component grow past the configured limits for number of memories or whatnot in the pooling allocator, for example.
Instead, we should figure out which builtins are needed by the program, and then only include and instantiate those.
:speech_balloon: fitzgen created PR review comment:
I don't think we want to enable all features here. Instead, we want to get the feature set from the
wasmtime::Config, which is accessible from thewasmtime::Engineand so should also be accessible from aCodeBuilder: https://github.com/bytecodealliance/wasmtime/blob/48c6579c9a1eaee45a5062b2e07ab3b5a69bae9b/crates/wasmtime/src/config.rs#L2585
fitzgen removed the review request for dicej from PR #15025.
dyslexicsteak updated PR #15025.
:memo: dyslexicsteak submitted PR review.
:speech_balloon: dyslexicsteak created PR review comment:
Right, good catch.
:memo: dyslexicsteak submitted PR review.
:speech_balloon: dyslexicsteak created PR review comment:
Yep, moved.
:memo: dyslexicsteak submitted PR review.
:speech_balloon: dyslexicsteak created PR review comment:
It was there for the
moveclosure but a plainfordoes fine here.
:memo: dyslexicsteak submitted PR review.
:speech_balloon: dyslexicsteak created PR review comment:
Only builtins the main Wasm imports get added because the loop goes over the main Wasm’s instance imports and only takes builtins found under those names, same as before.
dyslexicsteak commented on PR #15025:
Thanks! Overall looks good, but a few things we should address before merging below.
The feedback has got me thinking, actually, and maybe this requires an issue to discuss and a 2nd PR, but what if builtins resolved transitively? Like, say an embedder splits builtins into layers that build upon each other, with "ns:host/buffers" and "ns:host/strings" building on "ns:host/memory", as it stands right now, if a guest uses the higher-level builtins on their own then the lower level "ns:host/memory" won't get composed in because it's not a direct guest import. If they resolved transitively then it just works for any import anywhere and works fine based on my local testing.
:memo: fitzgen submitted PR review.
:speech_balloon: fitzgen created PR review comment:
D'oh I missed that this was already looping over the main component's imports.
fitzgen commented on PR #15025:
The feedback has got me thinking, actually, and maybe this requires an issue to discuss and a 2nd PR, but what if builtins resolved transitively? Like, say an embedder splits builtins into layers that build upon each other, with "ns:host/buffers" and "ns:host/strings" building on "ns:host/memory", as it stands right now, if a guest uses the higher-level builtins on their own then the lower level "ns:host/memory" won't get composed in because it's not a direct guest import. If they resolved transitively then it just works for any import anywhere and works fine based on my local testing.
This seems reasonable, but yeah should be a dedicated follow up.
:thumbs_up: fitzgen submitted PR review:
Thanks!
fitzgen added PR #15025 Compose compile-time builtins in memory to the merge queue.
github-merge-queue[bot] removed PR #15025 Compose compile-time builtins in memory from the merge queue.
dyslexicsteak updated PR #15025.
dyslexicsteak commented on PR #15025:
The tempfile change triggered a lint in the merge queue on a misplaced tempfile dependency in
component-async-teststhat was originally hidden somehow, maybe by checking the build graph and seeing if it would have been included anyway. I moved it to be a dev dependency as the lint suggested.
dyslexicsteak edited a comment on PR #15025:
The tempfile change triggered a lint in the merge queue on a misplaced tempfile dependency in
component-async-teststhat was originally hidden somehow, maybe by Cargo checking the build graph and seeing if it would have been included anyway. I moved it to be a dev dependency as the lint suggested.
:thumbs_up: fitzgen submitted PR review.
fitzgen has enabled auto merge for PR #15025.
fitzgen added PR #15025 Compose compile-time builtins in memory to the merge queue.
:check: fitzgen merged PR #15025.
fitzgen removed PR #15025 Compose compile-time builtins in memory from the merge queue.
Last updated: Oct 31 2026 at 23:03 UTC