1. 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
  2. 30 Nov, 2020 1 commit
  3. 20 Nov, 2020 1 commit
  4. 10 Nov, 2020 1 commit
  5. 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
  6. 08 Oct, 2020 1 commit
  7. 07 Oct, 2020 2 commits
  8. 23 Sep, 2020 1 commit
  9. 12 Feb, 2020 1 commit
  10. 25 Nov, 2019 1 commit
  11. 16 Oct, 2019 1 commit
  12. 16 Sep, 2019 1 commit
  13. 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
  14. 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
  15. 09 Jul, 2019 1 commit
  16. 27 Jun, 2019 1 commit
  17. 19 Jun, 2019 1 commit
  18. 11 Jun, 2019 1 commit
  19. 23 May, 2019 3 commits
  20. 22 May, 2019 1 commit
  21. 17 May, 2019 1 commit
  22. 16 May, 2019 2 commits
  23. 10 May, 2019 1 commit
  24. 28 Jan, 2019 1 commit
  25. 22 Jan, 2019 1 commit
  26. 26 Dec, 2018 1 commit
  27. 18 Dec, 2018 1 commit
  28. 17 Dec, 2018 1 commit
  29. 08 Dec, 2018 1 commit
  30. 28 Nov, 2018 1 commit
  31. 21 Sep, 2018 1 commit
    • Jakob Kummerow's avatar
      Fix building with GCC 7.x and 8.x · 9ed4b965
      Jakob Kummerow authored
      GCC 7.x doesn't like it (-Werror=subobject-linkage) when a class
      either derives from a class or has a member field of a type that
      was declared in an anonymous namespace.
      It is also opposed (-Werror=attributes) to visibility attributes
      being defined at explicit template instantiations.
      GCC 8.x further has reservations (-Werror=class-memaccess) about
      letting memset/memcpy modify areas within non-POD objects.
      
      Change-Id: Ic5107bb5ee3af6233e3741e3ef78d03a0a84005a
      Reviewed-on: https://chromium-review.googlesource.com/1208306
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56106}
      9ed4b965
  32. 11 Sep, 2018 1 commit
  33. 09 Aug, 2018 1 commit
  34. 23 Jul, 2018 1 commit
  35. 20 Jul, 2018 1 commit