You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initial support for handling import and export statements in the Chakra
parser. It is gated behind a config flag (-ES6Module).
We are treating the import and export keywords like a tag for declarations
or identifier references which should be physically stored in a special
slot array which we need to build up at module link time (or, at least
before bytecode generation time). The array is not built up as part of
this change but we are collecting all the exports, imports, and referenced
modules such that building that array should be possible. Once we build
this array, accesses to identifiers which are created via an import
keyword will load from that slot array and accesses to identifiers
declared via an export keyword will load and store from the same slot
array.
Currently, we are not hooking up export declarations to their imported
usages. If you import a binding from another module and access it, we will
only guarantee that the binding exists. The value of the binding will
always be undefined.
We are keeping track of exports, imports, and referenced modules in the
top-level ParseNode of the parser (which is subsequently handed-off to the
ByteCodeGenerator). When parsing a module we set a flag (fscrIsModuleCode)
which also causes us to create the root ParseNode as a knopModule type
node. That is in turn used to allocate the ParseNode itself as a PnModule
node, which derives from PnProg but adds the lists for imports, exports,
and referenced modules. We are still treating the top-level ParseNode as a
knopProg (which is to say, we reset the nop to knopProg after allocating
it) because we handle the case of knopProg everywhere and we don't need to
complicate things by also needing to handle knopModule. Instead we just
use the PnModule extensions when we are in a module-specific parsing path
and otherwise treat the node as if it was a PnProg ParseNode anyway. Note
that import and export statements do not themselves have special ParseNode
types.
This change adds an experimental method to Jsrt (JsExperimentalRunModule)
and a ch.exe hook (WScript.LoadModuleFile) for loading a module from a
file. Loading a module via this hook acts similarly to including a module
in a script tag like <script type="module">. The experimental method is
subject to change as the feature evolves.
A couple of points about module code. Module code is always strict code.
Import and export statements may only occur as statements at global scope
- they may not be located inside functions or inside eval'd code.
For more information about ES6 modules, please see the spec
http://tc39.github.io/ecma262/#sec-modules.
0 commit comments