feat(api): let embedders grow a shared memory without a store

[Arshia001]

Replaces the whole chore: bump napi stack (#6819, #6820, #6821, #6822, #6823, #6825, #6829, #6844, #6845, #6850) with a single PR. Nine of those ten were pure lib/napi submodule bumps; the napi pin here is a descendant of every one of them, so this subsumes the lot. The tenth, #6822, is the only one that carried code, and it is reworked below.

The problem with #6822

#6822 added SharedMemory::vm_shared_memory() -> &VMSharedMemory so wasmer-napi's GuestHeap could grow guest linear memory from host code running on V8's GC threads. That accessor was the wrong seam:

• It returns a type callers cannot name. mod vm in lib/api/src/lib.rs is private and re-exported nowhere, so wasmer::vm::VMSharedMemory has no public path. The consumer had to write one unbreakable expression, shared.vm_shared_memory().unwrap_sys_ref().clone(), because the intermediate can never be bound.
• unwrap_sys_ref() panics on a v8 or js memory — a "sys backend only" contract expressed nowhere in the type.
• It broke cargo doc off the sys feature. The doc comment linked wasmer_vm::LinearMemory::grow, but wasmer-vm is optional and the crate has #![deny(rustdoc::broken_intra_doc_links)], so cargo doc --no-default-features --features v8 failed. (Copilot flagged this on GuestHeap: SharedMemory accessor + napi bump + Cargo.lock (ECO-416) #6822; reproduced, and it was the only error in that build.) The mismatch was a symptom: the docs described the sys type while the signature returned the backend enum.
• The motivation was already met. SharedMemory is a clonable, Send + Sync, store-free handle — there's a test asserting it. The actual gap was that it had no store-free grow.

This PR instead

Three store-free methods on SharedMemory, all keeping the VM types encapsulated:

method	notes
grow(&self, delta) -> Result<Pages, MemoryError>	&self, not &mut self: a shared memory is an Arc<RwLock<..>> internally and any clone can already grow it, so &mut would be a distinction the type can't defend
data_ptr(&self) -> Option<*mut u8>	the same pointer MemoryView::data_ptr already returns publicly, minus the store
style(&self) -> Option<MemoryStyle>	MemoryStyle is already public API; lets a caller confirm the mapping is reserved up front before caching data_ptr

data_ptr and style are needed together because growth is not always base-stable — WasmMmap::grow remaps a dynamic heap ("it's a dynamic heap and it can move"). A caller caching the base must confirm a MemoryStyle::Static bound covering the maximum and re-check the base after each grow. Both are now possible without reaching into the VM layer; previously the second required an unsafe deref of VMMemoryDefinition.

Only sys supports any of this store-free. v8 and js return MemoryError::UnsupportedOperation / None instead of panicking.

Also carries the offset-allocator / nonmax Cargo.lock entries that #6822 introduced for the GuestHeap allocator.

Testing

• cargo check -p wasmer --features sys — green.
• cargo check -p wasmer --no-default-features --features v8 — green.
• cargo doc -p wasmer --no-default-features --features v8 --no-deps — green (fails on GuestHeap: SharedMemory accessor + napi bump + Cargo.lock (ECO-416) #6822).
• cargo test -p wasmer --features sys --lib — the existing ensure_shared_memory_handles_are_send_and_sync test passes.
• cargo test -p wasmer-napi --lib — 38/38.
• End-to-end with a napi-v8 CLI built from this branch: payload load test, 20 rounds / 3.91 GiB verified byte-for-byte, per-round retention flat.

Paired napi change: wasmerio/napi#54 (stacked on wasmerio/napi#53). The submodule here points at #54's head, so #53 and #54 need to merge first.

[Copilot]

Pull request overview

This PR extends the public SharedMemory API to support store-free operations needed by embedders (notably growing shared linear memory and inspecting its host mapping) while keeping VM-layer types encapsulated, and folds in the associated dependency lockfile updates.

Changes:

• Add store-free SharedMemory::{grow,data_ptr,style} APIs, returning UnsupportedOperation/None on non-sys backends.
• Add VM-internal helpers on VMSharedMemory to implement grow / base pointer / style queries per backend.
• Update Cargo.lock to include offset-allocator and nonmax entries (and wire offset-allocator into the relevant package dependencies).

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 3 comments.

File	Description
lib/api/src/vm/impls.rs	Adds VMSharedMemory::{grow,data_ptr,style} with backend-specific behavior.
lib/api/src/entities/memory/shared.rs	Exposes new public store-free SharedMemory methods that delegate to VMSharedMemory.
Cargo.lock	Adds lock entries for nonmax / offset-allocator and updates dependency list accordingly.

Suppressed comments (1)

lib/api/src/vm/impls.rs:117

• Same issue as the v8 branch: the \ continuation plus indentation inserts extra spaces into the rendered error message.

            Self::Js(_) => Err(wasmer_types::MemoryError::UnsupportedOperation {
                message: "growing a shared memory without a store is not supported by the js \
                          backend"
                    .into(),
            }),

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Arshia001]

Valid — fixed in b0931ee.

Reproduced with cargo doc -p wasmer --features sys --no-deps --document-private-items:

error: unresolved link to `MemoryError::UnsupportedOperation`
  --> lib/api/src/vm/impls.rs:88:25

It slipped past my earlier plain cargo doc check because mod vm is private and rustdoc skips private modules — but make build-docs passes --document-private-items, so it would have bitten there. Now fully qualified as crate::MemoryError, which resolves in every configuration since wasmer-types is a mandatory dependency and the re-export at lib.rs is unconditional. Verified: zero impls.rs diagnostics under that flag now.

[Arshia001]

Valid — added in b0931ee, three tests in a #[cfg(feature = "sys")] submodule that builds a shared Memory, detaches it with as_shared, and then:

• grow_returns_previous_size_and_is_shared_across_clones — grow returns the size the memory had beforehand, the growth is visible through an independent clone of the handle (the whole point of the API being &self), and it refuses to exceed the declared maximum.
• data_ptr_is_available_and_stable_across_grow — data_ptr is Some and non-null, and does not move across a grow when style reports a Static bound covering the maximum. That is the invariant that makes caching the base sound, and it is exactly what wasmer-napi's GuestHeap relies on, so it is worth pinning here rather than only downstream.
• style_is_reported — style is Some on the sys backend.

4/4 green (including the pre-existing Send/Sync test).

[syrusakbary]

I need to revisit this fully. I'm not convinced to not take one store handle for it at least. But it may work. I'm concerning of having a path that will work for sys, but not v8.

[Arshia001]

TBH, me too. I'm going back to this, seeing if we can't come up with something cleaner.