BUG=v8:6022
Change-Id: I54205cb3ecc2dd31ed62e55726f0ec5fcd202c30
Reviewed-on: https://chromium-review.googlesource.com/446349
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43500}
This is more useful than always returning undefined.
BUG=v8:1569,v8:5978
Change-Id: Id10cf87f7865db1a85de412460eaead4e4bf3b62
Reviewed-on: https://chromium-review.googlesource.com/446846
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43498}
Since the script origin is part of the key used in the compilation
cache, this ensures that the cache never confuses a module with a
non-module script.
BUG=v8:1569,v8:5685
Review-Url: https://codereview.chromium.org/2611643002
Cr-Commit-Position: refs/heads/master@{#42490}
This is a re-land of https://codereview.chromium.org/2393303002/ with
an additional call to DisposeModuleEmbedderData() added to fix lsan failures.
Unifies the approaches used for storing the specifier -> module mapping
and the module -> directory mapping, using std::unordered_maps for both
and storing them per-Context.
This requires adding a method to the v8::Module API to get a hash code
for a Module, but allows slimming down the API in return: gone are
SetEmbedderData/GetEmbedderData, along with the fourth argument
to ResolveModuleCallback.
Besides a simpler API, this allows d8 to get closer to the HTML loader,
which requires each Realm to have a persistent module map (though this
capability is not yet exercised by any tests).
BUG=v8:1569
TBR=neis@chromium.org,jochen@chromium.org
Review-Url: https://codereview.chromium.org/2405313002
Cr-Commit-Position: refs/heads/master@{#40186}
Reason for revert:
Fails under LeakSanitizer on auto-roll fyi bot:
https://build.chromium.org/p/client.v8.fyi/builders/Auto-roll%20-%20release%20process/builds/49447
Original issue's description:
> [modules] Store Module metadata in per-Context EmbedderData
>
> Unifies the approaches used for storing the specifier -> module mapping
> and the module -> directory mapping, using std::unordered_maps for both
> and storing them per-Context.
>
> This requires adding a method to the v8::Module API to get a hash code
> for a Module, but allows slimming down the API in return: gone are
> SetEmbedderData/GetEmbedderData, along with the fourth argument
> to ResolveModuleCallback.
>
> Besides a simpler API, this allows d8 to get closer to the HTML loader,
> which requires each Realm to have a persistent module map (though this
> capability is not yet exercised by any tests).
>
> BUG=v8:1569
>
> Committed: https://crrev.com/9cf8fce74cf6e7afd6aea3f3545f6bb61572f277
> Cr-Commit-Position: refs/heads/master@{#40133}
TBR=jochen@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2406973003
Cr-Commit-Position: refs/heads/master@{#40145}
Unifies the approaches used for storing the specifier -> module mapping
and the module -> directory mapping, using std::unordered_maps for both
and storing them per-Context.
This requires adding a method to the v8::Module API to get a hash code
for a Module, but allows slimming down the API in return: gone are
SetEmbedderData/GetEmbedderData, along with the fourth argument
to ResolveModuleCallback.
Besides a simpler API, this allows d8 to get closer to the HTML loader,
which requires each Realm to have a persistent module map (though this
capability is not yet exercised by any tests).
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2393303002
Cr-Commit-Position: refs/heads/master@{#40133}
This patch gives the ability for the embedder to ask for the
module requests of a module, and to pass a ResolveCallback
into Module::Instantiate().
In d8, I've implemented a simple module_map that's used
along with this API to allow loading, compiling, instantiating,
and evaluating a whole tree of modules.
No path resolution is yet implemented, meaning that all
import paths are relative to whatever directory d8 runs
in. And no imports are linked to the exports of the
requested module.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2351113004
Cr-Commit-Position: refs/heads/master@{#39569}
Adding the line "// MODULE" to an mjsunit file will now cause
run-tests.py to prefix the test case with "--module" in the
d8 commandline.
d8 has itself been updated to treat files preceded with "--module" as
modules (that is, it compiles them with ScriptCompiler::CompileModule,
and turns on --harmony-modules).
Review URL: https://codereview.chromium.org/902263002
Cr-Commit-Position: refs/heads/master@{#26555}
This adds an "experimental" API hook (v8::ScriptCompiler::CompileModule)
allowing compilation of modules. The code gen is incredibly basic: the
module body is represented by a Block in the AST. But this at least gets
more of the pipeline working, and opens the door to writing mjsunit tests
(once d8 is modified to support module compilation).
BUG=v8:1569
LOG=n
Review URL: https://codereview.chromium.org/902093002
Cr-Commit-Position: refs/heads/master@{#26496}
