complete source phase imports integration

Author: Guy Bedford

document/js-api/index.bs

@@ -328,13 +328,15 @@ A {{Module}} object represents a single WebAssembly module. Each {{Module}} obje
 
     * \[[Module]] : a WebAssembly [=/module=]
     * \[[Bytes]] : the source bytes of \[[Module]].
+    * \[[SourceClassName]] : the string "WebAssembly.Module"
 
 <div algorithm>
   To <dfn>construct a WebAssembly module object</dfn> from a module |module| and source bytes |bytes|, perform the following steps:
 
     1. Let |moduleObject| be a new {{Module}} object.
     1. Set |moduleObject|.\[[Module]] to |module|.
     1. Set |moduleObject|.\[[Bytes]] to |bytes|.
+    1. Set |moduleObject|.\[[SourceClassName]] to "WebAssembly.Module".
     1. Return |moduleObject|.
 </div>
 
@@ -548,6 +550,9 @@ interface Module {
 };
 </pre>
 
+Per ECMA-262 requirements for source phase import integration, the interface object for {{Module}} must have as its [[Prototype]] be %AbstractModuleSource%, created as if by ObjectCreate(%AbstractModuleSource%), instead of %ObjectPrototype%.
+In addition, the interface prototype object for {{Module}} must have as its [[Prototype]] %AbstractModuleSource.prototype%, created as if by ObjectCreate(%AbstractModuleSource%), instead of %ObjectPrototype%.
+
 <div algorithm>
   The <dfn>string value of the extern type</dfn> |type| is
     * "function" if |type| is of the form [=func=] <var ignore>functype</var>

proposals/esm-integration/README.md

@@ -1,6 +1,6 @@
 # WebAssembly/ES Module Integration
 
-This page describes  WebAssembly as an ES module. With this proposal, WebAssembly could be loaded from a JavaScript `import` statement, or a `<script type=module>` tag.
+This page describes WebAssembly as an ES module. With this proposal, WebAssembly may be loaded with a JavaScript `import` statement, or a `<script type=module>` tag.
 
 This proposal is at Stage 2 in [WebAssembly's process](https://github.com/WebAssembly/meetings/blob/master/process/phases.md).
 
@@ -71,9 +71,9 @@ These goals can be addressed by enabling WebAssembly modules to be loaded using
 
 This system has three phases:
 
-1. Fetch and parse — A module record is constructed from Module resources.
+1. Source — A module record is constructed from Module resources.
 1. Link — Exports and imports are wired up to memory locations.
-1. Evaluate — Top-level module code is run, assigning the value to exports.
+1. Evaluation — Top-level module code is run, assigning the value to exports.
 
 The work completed in these phases is defined in two different specifications:
 
@@ -82,7 +82,7 @@ The work completed in these phases is defined in two different specifications:
 
 WebAssembly fits into these steps as follows:
 
-### Fetch and Parse
+### Source Phase
 
 Fetching and parsing modules is a recursive process, which can be thought of as the following steps, defined in the host specification:
 1. Figure out what the module specifier is pointing to, and fetch the module.
@@ -97,23 +97,34 @@ In both cases, module parsing identifies the new, named exports that this module
 
 In the proposed HTML integration of WebAssembly modules, the [module name](https://webassembly.github.io/spec/core/syntax/modules.html#syntax-import) in an import is interpreted the same as a JavaScript module specifier: basically, as a URL. The [import maps](https://github.com/wicg/import-maps/) proposal adds more expressiveness to module specifiers.
 
-### Link
+#### Source Phase Imports
 
-Module records include names of imports and exports. The "link" phase checks whether the named imports correspond to things that are exported, and if so, hooking up the imports of one module to the exports of another module.
+[Source phase imports](https://github.com/tc39/proposal-source-phase-imports) expose the source phase of the module
+loading process, corresponding to a `WebAssembly.Module` source.
 
-The ECMAScript specification holds the module's export in a lexical scope, as potentially mutable variables. The importing module will have the ability to read, but not write, the variables in this lexical scope.
+For WebAssembly, the benefit of this import phase is being able to support multiple instantiation and custom
+instantiation or imports, while still utilizing the ESM integration for portable module resolution and fetching.
 
-At the end of the link phase, the variables in the module's lexical scope are generally uninitialized. From JavaScript, accessing an uninitialized import causes a ReferenceError. JavaScript function declarations are initialized during the Link phase, as part of function hoisting, but WebAssembly function exports are not initialized until the Evaluation phase.
+Source phase objects exposed by the module system must contain `AbstractModuleSource` in their prototype chain,
+therefore to support these imports for WebAssembly, the prototype of `WebAssembly.Module` is updated accordingly.
+
+#### Import Attributes
+
+[Import attributes](https://github.com/tc39/proposal-import-attributes) parameterize module imports in the module system. Currently HTML specifies a `"type"` attribute which is a requirement for CSS or JSON module imports due to their having different security privileges over full execution.
 
-#### Import Assertions
+When importing WebAssembly from JavaScript, no `"type"` should be required since they share the same security privilege level in the ESM integration and in order to ensure transparent interoperability of the formats.
 
-[Import assertions](https://github.com/tc39/proposal-import-assertions) specify linking invariants that should be verified before evaluation can proceed. Currently HTML specifies a `"type"` assertion which is a requirement for CSS or JSON module imports due to their having different security privileges over full execution.
+Future Wasm extensions may include supporting attributes for imports from WebAssembly modules.
 
-When importing WebAssembly from JavaScript, no assertion should be required since they share the same security privilege level in the ESM integration and in order to ensure transparent interoperability of the formats.
+### Link Phase
 
-Future Wasm extensions may include supporting these assertions for imports from WebAssembly modules.
+Module records include names of imports and exports. The "link" phase checks whether the named imports correspond to things that are exported, and if so, hooking up the imports of one module to the exports of another module.
+
+The ECMAScript specification holds the module's export in a lexical scope, as potentially mutable variables. The importing module will have the ability to read, but not write, the variables in this lexical scope.
+
+At the end of the link phase, the variables in the module's lexical scope are generally uninitialized. From JavaScript, accessing an uninitialized import causes a ReferenceError. JavaScript function declarations are initialized during the Link phase, as part of function hoisting, but WebAssembly function exports are not initialized until the Evaluation phase.
 
-### Evaluate
+### Evaluation Phase
 
 During evaluation, the code is evaluated to assign values to the exported bindings. In JS, this means running the top-level module code.