1. 26 Jan, 2021 1 commit
  2. 25 Jan, 2021 1 commit
  3. 14 Jan, 2021 1 commit
  4. 16 Dec, 2020 1 commit
    • Daniel Clark's avatar
      [modules][api] Implement HostGetSupportedImportAssertions · 8ae4dc40
      Daniel Clark authored
      Implement the HostGetSupportedImportAssertions, whose purpose
      is to filter the list of import assertions exposed to the embedder to
      only those assertion with keys that the embedder recognizes. See
      https://tc39.es/proposal-import-assertions/#sec-hostgetsupportedimportassertions.
      
      This change doesn't actually implement it as a callback, but instead
      passes the supported assertions during creation of the Isolate via
      CreateParams. This expresses clearly the requirement that the supported
      assertions must never change for the lifetime of the Isolate.
      
      Note that we still need to maintain all assertions in a map
      while parsing the import assertions clause, because duplicate keys for
      an unsupported assertion still needs to be detected as a parse error. So,
      the filtering is done later during
      SourceTextModuleDescriptor::AstModuleRequest::Serialize.
      
      The actual filtering algorithm simply iterates the assertions and the
      supported assertion keys in a nested loop. There's currently only one
      assertion in use ("type"), so there should be no reason to get too
      clever here unless at least several more assertions are generally
      supported.
      
      Bug: v8:10958
      Change-Id: I9a2d965e9d452718d0ddfe9dca55b7b4ed963019
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2572173Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Dan Clark <daniec@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71776}
      8ae4dc40
  5. 07 Dec, 2020 1 commit
    • Daniel Clark's avatar
      Allow casting to Primitive types from Data · a8f6c061
      Daniel Clark authored
      Although every Primitive is a Data, the Cast operations for the
      subclasses of Primitive do not allow casting directly from Data to the
      subclasses without first going through Value.  Because of this,
      Primitives extracted from a V8::FixedArray require two casts to get to
      the "real" type.
      
      Thus, as a convenience to embedders, this change makes it possible to
      cast directly from Data to all the subtypes of Primitive.
      
      Also, this change makes the parameter names in the declarations match
      those in the definitions, though there does not seem to be a universally
      followed convention regarding these.
      
      Bug: v8:10958
      Change-Id: I18dc3fbb9a9bccb2cb3b75efd829af64d46d8eb9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2573816Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Commit-Queue: Dan Clark <daniec@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71649}
      a8f6c061
  6. 30 Nov, 2020 1 commit
  7. 28 Nov, 2020 1 commit
  8. 24 Nov, 2020 2 commits
  9. 03 Nov, 2020 1 commit
  10. 07 Oct, 2020 1 commit
  11. 16 Mar, 2020 1 commit
  12. 25 Feb, 2020 1 commit
  13. 19 Feb, 2020 1 commit
  14. 05 Dec, 2019 1 commit
  15. 25 Nov, 2019 1 commit
  16. 24 Sep, 2019 1 commit
  17. 17 Sep, 2019 1 commit
  18. 16 Sep, 2019 1 commit
  19. 11 Sep, 2019 2 commits
    • Joshua Litt's avatar
      Revert "[top-level-await] Implement top-level-await in V8" · 93a29bdc
      Joshua Litt authored
      This reverts commit 591d1c9d.
      
      Reason for revert: breaks blink
      
      Original change's description:
      > [top-level-await] Implement top-level-await in V8
      > 
      > Implements AsyncModules in SourceTextModule. However, there is no
      > support in the parser or D8 for actually creating / resolving
      > AsyncModules. Also adds a flag '--top-level-await,' but the only
      > external facing change with the flag enabled is that Module::Evaluate
      > returns a promise.
      > 
      > Bug: v8:9344
      > Change-Id: Idc722efc1e2aa780d04bdb985bb7920ab969d34e
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728037
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63686}
      
      TBR=ulan@chromium.org,adamk@chromium.org,neis@chromium.org,joshualitt@chromium.org
      
      Change-Id: I6ceeb3a293a948af04bf200ab784ceb03386a3fd
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9344
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1797656Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63692}
      93a29bdc
    • Joshua Litt's avatar
      [top-level-await] Implement top-level-await in V8 · 591d1c9d
      Joshua Litt authored
      Implements AsyncModules in SourceTextModule. However, there is no
      support in the parser or D8 for actually creating / resolving
      AsyncModules. Also adds a flag '--top-level-await,' but the only
      external facing change with the flag enabled is that Module::Evaluate
      returns a promise.
      
      Bug: v8:9344
      Change-Id: Idc722efc1e2aa780d04bdb985bb7920ab969d34e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728037Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63686}
      591d1c9d
  20. 24 May, 2019 1 commit
  21. 08 Jan, 2018 1 commit
  22. 22 Dec, 2017 1 commit
    • Georg Neis's avatar
      [modules] Implement recent ES revisions. · a067281d
      Georg Neis authored
      - Instantiation errors are no longer recorded. If instantiation fails,
        the module(s) are reset to "uninstantiated". When instantiation is
        re-attempted, the thrown exception will be fresh.
      - Instantiation can succeed even where there are modules in the graph
        that previously failed evaluation.
      
      Bug: v8:1569
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I429f616918afe5f8ab1a956024f0a22f464b8c44
      Reviewed-on: https://chromium-review.googlesource.com/763369
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50301}
      a067281d
  23. 28 Jun, 2017 1 commit
  24. 21 Jun, 2017 1 commit
  25. 29 May, 2017 1 commit
  26. 19 Apr, 2017 1 commit
  27. 28 Feb, 2017 2 commits
  28. 19 Jan, 2017 1 commit
  29. 11 Oct, 2016 2 commits
    • adamk's avatar
      [modules] Store Module metadata in per-Context EmbedderData · 9d2051fc
      adamk authored
      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}
      9d2051fc
    • adamk's avatar
      Revert of [modules] Store Module metadata in per-Context EmbedderData... · 12779889
      adamk authored
      Revert of [modules] Store Module metadata in per-Context EmbedderData (patchset #7 id:120001 of https://codereview.chromium.org/2393303002/ )
      
      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}
      12779889
  30. 10 Oct, 2016 1 commit
    • adamk's avatar
      [modules] Store Module metadata in per-Context EmbedderData · 9cf8fce7
      adamk authored
      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}
      9cf8fce7
  31. 22 Sep, 2016 1 commit
  32. 20 Sep, 2016 1 commit
    • adamk's avatar
      [modules] Expand API to allow linking and use it in d8 · cf127e81
      adamk authored
      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}
      cf127e81
  33. 10 Feb, 2015 1 commit
    • adamk's avatar
      Enable compiling mjsunit tests as ES6 modules · a18b797f
      adamk authored
      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}
      a18b797f
  34. 06 Feb, 2015 1 commit
    • adamk's avatar
      Add basic compilation support for modules · 70079dab
      adamk authored
      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}
      70079dab