fix(plugin): avoid importing __free from env#11908
Conversation
🦋 Changeset detectedLatest commit: b3ed437 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a145755e0b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| [ | ||
| ("__free", free_bytes), | ||
| ( | ||
| "__set_transform_plugin_core_pkg_diagnostics", | ||
| set_plugin_core_pkg_diagnostics, |
There was a problem hiding this comment.
Keep the legacy __free import shim
Plugins compiled while swc_plugin_proxy declared #[link(wasm_import_module = "env")] fn __free still have an env::__free import whenever they use host-returned values (metadata/comments/source maps). Since both Wasmtime and Wasmer instantiate with exactly the names returned from this import object, dropping this entry makes those otherwise schema-compatible plugins fail during runtime.init before the compatibility handshake can run. Keeping the shim is harmless for newly fixed plugins that no longer import it, and preserves loading for artifacts built with the previous release.
Useful? React with 👍 / 👎.
Merging this PR will not alter performance
Comparing Footnotes
|
Description:
__freein plugin memory interop as the linked allocator symbol fromswc_plugin::allocation, not anenvhost import.env::__freefrom the Wasm plugin runtime import object.rustctonightly-2026-04-10#11783 where__freewas accidentally treated like a dynamic host import.Related issue:
Related to #11783.
[email protected]are yanked #11907