Support direct global bindings

[guybedford]

This updates the specification to provide the unwrapping of WebAssembly.Global values 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' where mod.wasm exports a mutable global, can reflect the live direct JS value for exportVal in JS of that mutable global without requiring the exportVal.value accessor normally needed for instances of WebAssembly.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.

This PR was raised at the WasmCG, and obtained 6 votes for, 15 neutral and 1 against.

Concern from the 1 vote against, was subsequently resolved in #108 which was also landed into this PR after discussion in #107, allowing for a new WebAssembly.namespaceInstance function for obtaining the instance from a given namespace:

import * as wasmModNs from './mod.wasm';
const instance = WebAssembly.namespaceInstance(wasmModNs);
instance instanceof WebAssembly.Instance; // true

As a WebIDL function taking a ModuleNamespace, this is also refactored with an associated WebIDL PR in whatwg/webidl#1483.

[guybedford]

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.

[nicolo-ribaudo]

(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)

[guybedford]

Yes it's unfortunate we have [[Module]] on both a resolve binding record and a WebAssembly.Module module object. Perhaps resolve binding records could refactor at some point to use [[ResolvedModule]] or something like that to ensure clarity in this kind of scenario.

I've split out resolutionModule and resolutionName and also added some assertions to make the relationships clearer.

[nicolo-ribaudo]

What if [[BindingName]] is NAMESPACE? e.g. if I import foo from a module that does export * as foo from "./bar.js".

[guybedford]

We are reading directly from the environment record here, so NAMESPACE cannot be a value in an environment record in ECMA-262, you'd get the namespace object representation instead.

[nicolo-ribaudo]

Fwiw, https://tc39.es/ecma262/#sec-createimportbinding is similarly vague.

[nicolo-ribaudo]

Why do we do this instead of simply not exposing them, making it a linking error?

[guybedford]

This is a great point and thanks for spotting this. The reason is that we need these bindings to work when Wasm modules import other Wasm modules. That is, while these values are not expressible in JS, they should still be exposed as exports to other Wasm. TDZ is therefore a useful way to represent this property.

[nicolo-ribaudo]

Spec text looks good