Support direct global bindings #104
Conversation
guybedford
force-pushed
the
module-bindings
branch
from
d13bd74 to
1fd242e
Compare
|
I've significantly simplified the approach here by removing the extra spec work added for resolving cyclic bindings, to instead discuss any possible cycle support separately. |
guybedford
force-pushed
the
module-bindings
branch
2 times, most recently
from
1834063 to
e46cfcc
Compare
guybedford
force-pushed
the
module-bindings
branch
from
e46cfcc to
fd68140
Compare
| 1. Let |resolutionInstance| be |resolution|.\[[Module]].\[[Instance]]. | ||
| 1. If |resolutionInstance| is ~empty~ then, | ||
| 1. Throw a {LinkError} exception. | ||
| 1. Let |resolutionModule| be |resolution|.\[[Module]].\[[ModuleSource]].\[[Module]]. |
There was a problem hiding this comment.
(this is confusing, I thought [[Module]] was the Module Record corresponding to [[ModuleSource]] rather than a WebAssembly module, but I don't think we can improve it anyway)
| 1. [=list/Append=] |externval| to |imports|. | ||
| 1. Otherwise, | ||
| 1. Let |env| be |resolution|.\[[Module]].\[[Environment]]. | ||
| 1. Let |v| be [=?=] |env|.GetBindingValue(|resolution|.\[[BindingName]], true). |
There was a problem hiding this comment.
What if [[BindingName]] is NAMESPACE? e.g. if I import foo from a module that does export * as foo from "./bar.js".
| 1. Note: The condition above leaves unsupported JS values as uninitialized in TDZ and therefore as a reference error on | ||
| access. When integrating with shared globals, they may be excluded here similarly to v128 above. | ||
| 1. Perform [=!=] |record|.\[[Environment]].InitializeBinding(|name|, [=ToJSValue=](|global_value|)). | ||
| 1. If |mut| is [=var=], then associate all future mutations of |globaladdr| with the ECMA-262 binding record for |name| in |
There was a problem hiding this comment.
Fwiw, https://tc39.es/ecma262/#sec-createimportbinding is similarly vague.
| 1. Note: The condition above leaves unsupported JS values as uninitialized in TDZ and therefore as a reference error on | ||
| access. When integrating with shared globals, they may be excluded here similarly to v128 above. |
There was a problem hiding this comment.
Why do we do this instead of simply not exposing them, making it a linking error?
This updates the specification to provide the unwrapping of
WebAssembly.Globalvalues in the exports of WebAssembly module instances, while fully retaining the existing support of Wasm to Wasm global binding and ensuring constant and mutable globals are only ever fulfilled by their same corresponding type.This was originally discussed in the early stages of this proposal, and then brought up recently again in #103.
With this change,
import { exportVal } from './mod.wasm'wheremod.wasmexports a mutable global, can reflect the live direct JS value forexportValin JS of that mutable global without requiring theexportVal.valueaccessor normally needed for instances ofWebAssembly.Global. We effectively get live direct bindings on exports, and also for imports to other Wasm modules, while continuing to have snapshotted bindings on non-Wasm imports.Live bindings for JS modules are supported for Wasm mutable globals due the infallible nature of
ToJSValue()allowing us to create an association between the JS environment record and the Wasm global.The way we handle Wasm to Wasm imports is to store the
[[Instance]]on the WebAssembly module record, so that we can access the original global address from the instance when resolving to another WebAssembly Module record. All other types retain their existing handling. Since Wasm to Wasm imports no longer have the wrapping and unwrapping through JS which relied on implicit subtyping, we instead directly perform the same extern subtype checks of the WebAssembly value imports, using the corresponding core definition for this.It would be great to discuss this one one last time before we more widely ship the current integration.