|
Lines 1-3
a/Source/JavaScriptCore/ChangeLog_sec1
|
|
|
1 |
2016-12-27 Yusuke Suzuki <utatane.tea@gmail.com> |
| 2 |
|
| 3 |
[JSC] Prototype dynamic-import |
| 4 |
https://bugs.webkit.org/show_bug.cgi?id=165724 |
| 5 |
|
| 6 |
Reviewed by NOBODY (OOPS!). |
| 7 |
|
| 8 |
In this patch, we implement stage3 dynamic-import proposal[1]. |
| 9 |
This patch adds a new special operator `import`. And by using it, we can import |
| 10 |
the module dynamically from modules and scripts. Before this feature, the module |
| 11 |
is always imported statically and before executing the modules, importing the modules |
| 12 |
needs to be done. And especially, the module can only be imported from the module. |
| 13 |
So the classic script cannot import and use the modules. This dynamic-import relaxes |
| 14 |
the above restrictions. |
| 15 |
|
| 16 |
The typical dynamic-import form is the following. |
| 17 |
|
| 18 |
import("...").then(function (namespace) { ... }); |
| 19 |
|
| 20 |
You can pass any AssignmentExpression for the import operator. So you can determine |
| 21 |
the importing modules dynamically. |
| 22 |
|
| 23 |
import(value).then(function (namespace) { ... }); |
| 24 |
|
| 25 |
And previously the module import declaration is only allowed in the top level statements. |
| 26 |
But this import operator is just an expression. So you can use it in the function. |
| 27 |
And you can use it conditionally. |
| 28 |
|
| 29 |
async function go(cond) |
| 30 |
{ |
| 31 |
if (cond) |
| 32 |
return import("..."); |
| 33 |
return undefined; |
| 34 |
} |
| 35 |
await go(true); |
| 36 |
|
| 37 |
Currently, this patch just implements this feature only for the JSC shell. |
| 38 |
JSC module loader requires a new hook, `importModule`. And the JSC shell implements |
| 39 |
this hook. So, for now, this dynamic-import is not available in the browser side. |
| 40 |
If you write this `import` call, it always returns the rejected promise. |
| 41 |
|
| 42 |
import is implemented like a special operator similar to `super`. |
| 43 |
This is because import is context-sensitive. If you call the `import`, the module |
| 44 |
key resolution is done based on the caller's running context. |
| 45 |
|
| 46 |
For example, if you are running the script which filename is "./ok/hello.js", the module |
| 47 |
key for the call`import("./resource/syntax.js")` becomes `"./ok/resource/syntax.js"`. |
| 48 |
But if you write the completely same import form in the script "./error/hello.js", the |
| 49 |
key becomes "./error/resource/syntax.js". So exposing this feature as the `import` |
| 50 |
function is misleading: this function becomes caller's context-sensitive. That's why |
| 51 |
dynamic-import is specified as a special operator. |
| 52 |
|
| 53 |
To resolve the module key, we need the caller's context information like the filename of |
| 54 |
the caller. This is provided by the SourceOrigin implemented in r210149. |
| 55 |
In the JSC shell implementation, this SourceOrigin holds the filename of the caller. So |
| 56 |
based on this implementation, the module loader resolve the module key. |
| 57 |
In the near future, we will extend this SourceOrigin to hold more information needed for |
| 58 |
the browser-side import implementation. |
| 59 |
|
| 60 |
[1]: https://tc39.github.io/proposal-dynamic-import/ |
| 61 |
|
| 62 |
* builtins/ModuleLoaderPrototype.js: |
| 63 |
(importModule): |
| 64 |
* bytecompiler/BytecodeGenerator.cpp: |
| 65 |
(JSC::BytecodeGenerator::emitGetTemplateObject): |
| 66 |
(JSC::BytecodeGenerator::emitGetGlobalPrivate): |
| 67 |
* bytecompiler/BytecodeGenerator.h: |
| 68 |
* bytecompiler/NodesCodegen.cpp: |
| 69 |
(JSC::ImportNode::emitBytecode): |
| 70 |
* jsc.cpp: |
| 71 |
(GlobalObject::moduleLoaderImportModule): |
| 72 |
* parser/ASTBuilder.h: |
| 73 |
(JSC::ASTBuilder::createImportExpr): |
| 74 |
* parser/NodeConstructors.h: |
| 75 |
(JSC::ImportNode::ImportNode): |
| 76 |
* parser/Nodes.h: |
| 77 |
(JSC::ExpressionNode::isImportNode): |
| 78 |
* parser/Parser.cpp: |
| 79 |
(JSC::Parser<LexerType>::parseMemberExpression): |
| 80 |
* parser/SyntaxChecker.h: |
| 81 |
(JSC::SyntaxChecker::createImportExpr): |
| 82 |
* runtime/JSGlobalObject.cpp: |
| 83 |
(JSC::JSGlobalObject::init): |
| 84 |
* runtime/JSGlobalObject.h: |
| 85 |
* runtime/JSGlobalObjectFunctions.cpp: |
| 86 |
(JSC::globalFuncImportModule): |
| 87 |
* runtime/JSGlobalObjectFunctions.h: |
| 88 |
* runtime/JSModuleLoader.cpp: |
| 89 |
(JSC::JSModuleLoader::importModule): |
| 90 |
(JSC::JSModuleLoader::getModuleNamespaceObject): |
| 91 |
* runtime/JSModuleLoader.h: |
| 92 |
* runtime/ModuleLoaderPrototype.cpp: |
| 93 |
(JSC::moduleLoaderPrototypeGetModuleNamespaceObject): |
| 94 |
|
| 1 |
2016-12-26 Yusuke Suzuki <utatane.tea@gmail.com> |
95 |
2016-12-26 Yusuke Suzuki <utatane.tea@gmail.com> |
| 2 |
|
96 |
|
| 3 |
Use variadic templates in JSC Parser to clean up |
97 |
Use variadic templates in JSC Parser to clean up |