Skip to content

V
V8
Switch branch/tag
  1. 07 Dec, 2021 1 commit
  3. 06 Dec, 2021 1 commit
  5. 30 Nov, 2021 2 commits
  7. 15 Nov, 2021 1 commit
  9. 27 Oct, 2021 1 commit
  11. 27 Sep, 2021 1 commit
  13. 09 Aug, 2021 1 commit
  15. 05 Aug, 2021 1 commit
  17. 10 Feb, 2021 1 commit
    • Daniel Clark's avatar
      Fix top-level await crash from synthetic module being evaluated twice · f033e2a1
      Daniel Clark authored 
      With top-level await, when Evaluate is performed on an already-evaluated
synthetic module, Module::InnerEvaluate returns undefined.  This breaks
top-level await's assumption that the returned value is always a
promise.

In order to make SyntheticModule's behavior consistent with
SourceTextModule, the top_level_capability field is moved up to Module
and SyntheticModule::Evaluate places the promise returned from the
host's evaluation steps in that field.  Now SourceTextModule and
SyntheticModule can share the same code to handle the case where the
module is either kErrored or kEvaluated, so the code for this
is moved up to Module.

Thus, SyntheticModule is now guaranteed to return the
promise from the evaluation steps even on subsequent Evaluate() calls.

Unfortunately Node hasn't yet updated their EvaluationStepsCallback
to return a Promise, so we can't yet assume that the returned value
is a Promise without breaking Node.  So, this change also adds a clause
to check for this condition and create a new resolved Promise if one
was not provided by the callback steps.  This could eventually be
removed once Node's callback steps are updated for top-level await.

Change-Id: I2d6ae918abfeba9e3a757838502d4df92946edaa
Bug: v8:11398
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673794Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#72629}
      f033e2a1
  19. 30 Nov, 2020 1 commit
  21. 20 Nov, 2020 1 commit
  23. 10 Nov, 2020 1 commit
  25. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored 
      This CL splits the class definitions per .tq file, to realize the
following relationship:
A class defined in src/objects/foo.tq has a C++ definition in
src/objects/foo.h. Torque then generates:

- torque-generated/src/objects/foo-tq.inc
  An include file (no proper header) to be included in src/objects/foo.h
  containing the Torque-generated C++ class definition.

- torque-generated/src/objects/foo-tq-inl.inc
  An include file (no proper header) to be included in
  src/objects/foo-inl.h containing inline function definitions.

- torque-generated/src/objects/foo-tq.cc
  A source file including src/objects/foo-inl.h that contains non-inline
  function definitions.

Advantages of this approach:
- Avoid big monolithic headers and preserve the work that went into
  splitting objects.h
- Moving a definition to Torque keeps everything in the same place
  from a C++ viewpoint, including a fully Torque-generated C++ class
  definition.
- The Torque-generated include files do not need to be independent
  headers, necessary includes or forward declarations can just be added
  to the headers that include them.

Drive-by changes:
A bunch of definitions and files had to be moved or created to realize
a consistent 1:1 relationship between .tq files and C++ headers.


Bug: v8:7793
TBR: hpayer@chromium.org
Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  27. 08 Oct, 2020 1 commit
  29. 07 Oct, 2020 2 commits
  31. 23 Sep, 2020 1 commit
  33. 12 Feb, 2020 1 commit
  35. 25 Nov, 2019 1 commit
  37. 16 Oct, 2019 1 commit
  39. 16 Sep, 2019 1 commit
  41. 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
  43. 24 Jul, 2019 1 commit
    • Daniel Clark's avatar
      Move potentially reentrant allocation out of the middle of Module::Reset · 61e2b67e
      Daniel Clark authored 
      During Module::Reset(), the module is in an unstable state between the
change to SourceTextModule::code and Module::status.  Any reentrancy
between these points is problematic because the normal invariants about
the value of SourceTextModule::code in relation to Module::status do not
hold.

An allocation of the exports hash table in the middle of Module::Reset()
was causing reentrancy during this problematic time.  This change fixes
the issue by moving the allocation earlier in Reset() before any fields
are modified.

Bug: v8:9522
Change-Id: Ia941af60a0b31f05a6d8da610b9a270e7f79dac2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1712449Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Dan Clark <daniec@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#62902}
      61e2b67e
  45. 09 Jul, 2019 1 commit
  47. 27 Jun, 2019 1 commit
  49. 19 Jun, 2019 1 commit
  51. 11 Jun, 2019 1 commit
  53. 23 May, 2019 3 commits
  55. 22 May, 2019 1 commit
  57. 17 May, 2019 1 commit
  59. 16 May, 2019 2 commits
  61. 10 May, 2019 1 commit
  63. 28 Jan, 2019 1 commit
  65. 22 Jan, 2019 1 commit
  67. 26 Dec, 2018 1 commit