1. 19 Mar, 2020 2 commits
    • Leszek Swirski's avatar
      Revert "[parser] Introduce UnoptimizedCompileFlags" · fabea6af
      Leszek Swirski authored
      This reverts commit d91679bf.
      
      Reason for revert: Seems to cause UBSan errors
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      > 
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      > 
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      > 
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
      
      Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10314
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66783}
      fabea6af
    • Leszek Swirski's avatar
      [parser] Introduce UnoptimizedCompileFlags · d91679bf
      Leszek Swirski authored
      UnoptimizedCompileFlags defines the input flags shared between parse and
      compile (currently parse-only). It is set initially with some values, and
      is immutable after being passed to ParseInfo (ParseInfo still has getters
      for the fields, but no setters).
      
      Since a few of the existing flags were output flags, ParseInfo now has a
      new output_flags field, which will eventually migrate to a ParseOutputs
      structure.
      
      Bug: v8:10314
      Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66782}
      d91679bf
  2. 18 Mar, 2020 1 commit
  3. 10 Mar, 2020 3 commits
    • Leszek Swirski's avatar
      [parser] Set script id on ParseInfo creation · b4712802
      Leszek Swirski authored
      Rather than having an optional script id during ParseInfo creation (which
      is either selected lazily on script creation, or eagerly if based on an
      existing Script), always eagerly get either the desired script id (either
      from the Script or Isolate::GetNextScriptId()).
      
      This has the side-effect that we will currently no longer need to get the
      script id on background threads, but I'm not reverting the thread-safety
      of Isolate::GetNextScriptId in case it's needed again in the future.
      
      Bug: v8:10314
      Change-Id: I8f2dd962d3652b1a84a5d704a099e57a1679aba5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096616
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66649}
      b4712802
    • Leszek Swirski's avatar
      [parser] Remove ParseInfo flag setting after script creation · e68b5941
      Leszek Swirski authored
      Previously, ParseInfo would create a script (with CreateScript) based on
      its flags, and then set its own flags based on that created script. This
      created a weird circular dependency for some of those flags, and
      sometimes we would have valid flags before script creation (main thread
      compile), while other times not (streaming compile).
      
      Now we set the ParseInfo flags manually and uniformly before script
      creation, and check that they match the created script after it has been
      created.
      
      Bug: v8:10314
      Change-Id: Ife886c77727cd228c944a4f97369a3e6365d8219
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093433
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66648}
      e68b5941
    • Leszek Swirski's avatar
      [parser] Move ParseInfo wrapped argument setup · 4f3b0990
      Leszek Swirski authored
      Change wrapped argument set-up to be closer to where it's needed: setting
      up a top-level SFI, or initializing a ParseInfo from a top-level SFI.
      
      This is a generally cleaner use of the interface, avoids splitting the
      setting of the funciton syntax kind and wrapped arguments (including
      checking script.is_wrapped() in two places for the same behaviour), plus
      it avoids unnecessarily creating wrapped_argument handles for functions
      inside a wrapped script.
      
      As a drive-by, rename ParseInfo::SetFlagsFromScript to a clearer
      
      ParseInfo::SetFlagsForFunctionInScript, to differentiate between flags
      from a script for top-level vs. non-top-level.
      
      Bug: v8:10314
      Change-Id: Ibdaad957558c13a1528dcc3da1ba8f262f357e48
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093509
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66643}
      4f3b0990
  4. 09 Mar, 2020 1 commit
  5. 03 Mar, 2020 2 commits
    • Joyee Cheung's avatar
      [class] maintain private brand information on SFI · 0753cbea
      Joyee Cheung authored
      When an empty class is nested inside a class with private instance
      methods, like this:
      
        class Outer {
          constructor() {}
          #method() {}
          factory() {
            class Inner {
              constructor() {  }
            }
            return Inner;
          }
          run(obj) {
            obj.#method();
          }
        }
      
      The bytecode generator previously generate private brand
      initialization for the constructor of Inner by mistake,
      because during scope chain serialization/deserialization,
      the outer scopes of Inner and factory() are not allocated
      or serialized (as they are empty). In the eyes of the bytecode
      generator, it then appeared as if Outer is the direct outer
      scope of Inner's constructor.
      
      In order to work around this information loss, in this patch
      we rely on SharedFunctionInfo instead of the Context/ScopeInfo
      chain to maintain the information about private brand initialization.
      This is done by shrinking expected_nof_properties to 8 bits and
      freeing 8 bits for a second bitfield on the SFI.
      
      Design doc: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit#
      Bug: v8:9839, v8:8330, v8:10098
      
      Change-Id: I4370a0459bfc0da388052ad5a91aac59582d811d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056889
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66575}
      0753cbea
    • Leszek Swirski's avatar
      [offthread] Allow off-thread bytecode finalization · 455cb6c0
      Leszek Swirski authored
      Add the remaining missing templatizations to allow an initial wiring in
      of the off-thread factory into streaming compilation finalization.
      
      The off-thread finalization is behind a flag, disabled by default:
          --finalize-streaming-on-background
      
      When the flag is enabled, background tasks will perform perform the
      finalization during their background execution, and will release the
      parser and compilation jobs once they are no longer needed.
      
      The implementation is complete enough for performance testing, but not
      enough for launch. Notably, there is no support for:
      
        * Class boilerplates (the code is marked unreachable),
        * Exceptions during finalization, i.e. parse/compile warnings/errors,
        * Allocation sampling,
        * Logging,
        * Asm.js,
        * Parallel complication tasks
        * Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()")
      
      This patch also adds some tracing events for the various stages of the
      off-thread finalization (including the main-thread merge) for further
      performance improvements.
      
      Bug: chromium:1011762
      Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66566}
      455cb6c0
  6. 02 Mar, 2020 1 commit
  7. 24 Feb, 2020 1 commit
  8. 18 Feb, 2020 1 commit
  9. 13 Feb, 2020 1 commit
  10. 12 Feb, 2020 2 commits
  11. 11 Feb, 2020 1 commit
  12. 10 Feb, 2020 1 commit
    • Michael Achenbach's avatar
      Make using natives for fuzzing more permissive · cf05e4ca
      Michael Achenbach authored
      This makes creating whitelisted runtime functions more permissive on
      fuzzers (when --allow-natives-for-fuzzing is passed).
      
      - Runtime functions with too few arguments are replaced with undefined.
      - Superfluous arguments are ignored.
      
      This reduces syntax-error rate on fuzzers. Also prevents
      dcheck errors when fuzzing debug builds and fuzzers use too many
      arguments for runtime functions.
      
      Bug: chromium:1044942
      Change-Id: I23b45398421c50bc82d1e8bfdf019f565253db96
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039352
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66202}
      cf05e4ca
  13. 07 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [ast] Cache allocated AstConsString · 7fa19160
      Leszek Swirski authored
      Allow caching the result of allocating AstConsStrings, to allow
      sharing of inferred names between functions.
      
      This is a partial revert of https://crrev.com/c/2020953, with
      the observation that *some* AstConsStrings are always flattened,
      while others are only ever used as ConsStrings, so we want to
      allow the allocation to be lazy while still caching the result.
      
      As a drive-by, cleanup the old AstConsString linked list fields.
      
      Bug: chromium:1011762
      Bug: chromium:1048082
      Change-Id: Icc14342eb3f6f97359596b42b2c296cbc49fd791
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042093
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66168}
      7fa19160
  14. 04 Feb, 2020 2 commits
    • Leszek Swirski's avatar
      [offthread] Add an OffThreadIsolate · 7a20b6b9
      Leszek Swirski authored
      The Factory/OffThreadFactory allows us to cleanly separate object
      construction behaviour between main-thread and off-thread in a
      syntactically consistent way (so that methods templated on the factory
      type can be made to work on both).
      
      However, there are cases where we also have to access the Isolate, for
      handle creation or exception throwing. So far we have been pushing more
      and more "customization points" into the factories to allow these
      factory-templated methods to dispatch on this isolate behaviour via
      these factory methods. Unfortunately, this is an increasing layering
      violation between Factory and Isolate, particularly around exception
      handling.
      
      Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
      way as OffThreadFactory is analogous to Factory. All methods which were
      templated on Factory are now templated on Isolate, and methods which
      used to take an Isolate, and which were recently changed to take a
      templated Factory, are changed/reverted to take a templated Isolate.
      OffThreadFactory gets an isolate() method to match Factory's.
      
      Notably, FactoryHandle is changed to "HandleFor", where the template
      argument can be either of the Isolate type or the Factory type (allowing
      us to dispatch on both depending on what is available).
      
      Bug: chromium:1011762
      Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66101}
      7a20b6b9
    • Toon Verwaest's avatar
      [modules] Setup module exports in Runtime_DeclareModuleExports · 24c83d49
      Toon Verwaest authored
      This changes how we setup modules from being entirely bytecode based to a
      single fixed array with metadata that's passed into a runtime function
      DeclareModuleExports, similar to DeclareGlobals. This is preperatory work to
      replace the bytecode that calls those functions with explicit calls before we
      even start running the code. In the case of modules that will obviate the need
      for modules to be generators.
      
      Change-Id: Ibf1c913a9dc78041e3001b174c66ab89226d9c8e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030733
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66097}
      24c83d49
  15. 31 Jan, 2020 1 commit
  16. 30 Jan, 2020 1 commit
  17. 28 Jan, 2020 1 commit
  18. 22 Jan, 2020 2 commits
  19. 16 Jan, 2020 2 commits
  20. 13 Jan, 2020 1 commit
  21. 08 Jan, 2020 1 commit
  22. 07 Jan, 2020 1 commit
  23. 27 Dec, 2019 1 commit
    • Daniel Clifford's avatar
      Port bitfield ScopeFlags to Torque · 7e8a197c
      Daniel Clifford authored
      In the process:
      
      * Rework the Torque definition of ScopeInfo to enable direct
        field-style access of ScopeFlags, removing some dead code in
        the process.
      * Allow implicit FromConstexpr conversion from subtypes of
        'constexpr A' to other types. This makes it possible/easy to
        convert constexpr versions of enums to other types, since the
        constexpr version of the enum isn't addressable. It's namespace
        isn't a valid namespace and is an implementation detail anyway.
      * Cleanup LanguageMode: Language mode is now an enum and directly
        mirrors the C++-side definition rather than being a Smi. With
        the changes above, a new type LanguageModeSmi is introduced
        that is the Smi representation of LanguageMode that can be
        implicitly casted from constexpr LanguageMode values.
      
      Change-Id: I190412f95e02905f445d149883fbf1f2b8ed757b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1977159
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65561}
      7e8a197c
  24. 19 Dec, 2019 1 commit
    • Shu-yu Guo's avatar
      Remove per-parameter position var scope · 1b450a17
      Shu-yu Guo authored
      The spec was normatively changed to simplify var scopes for parameter
      expressions. Previously there was a per-parameter var scope in sloppy
      mode so direct evals could introduce vars that did not escape the
      parameter position. That semantics is complex both for the programmer
      and implementation and has resulted in bugs in the past. Furthermore, it
      has never been fully interoperable (with Safari in particular). The spec
      was instead changed to be simpler: to have a single var scope for
      sloppy evals in parameters that encloses the parameter scope and body
      scope.
      
      This simplification lets us remove expression-scope-reparenter.
      
      Drive-by removal of stale reference to PatternRewriter.
      
      Bug: v8:7532
      Change-Id: Iade5594abe0009f7f3f6a1adad18628b17e1e779
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962471Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65517}
      1b450a17
  25. 18 Dec, 2019 1 commit
    • Simon Zünd's avatar
      Store JSMessageObject on rejected promises · b15c02d0
      Simon Zünd authored
      When V8 throws an uncaught exception, we store a JSMessageObject
      with a stack trace and source positions on the isolate itself.
      The JSMessageObject can be retrieved by a TryCatch scope
      and is used by the inspector to provide additional information to the DevTools
      frontend (besides the exception).
      
      Introducing top-level await for REPL mode causes all thrown exceptions
      to be turned into a rejected promise. The implicit catch block that does this
      conversion clears the JSMessageObject from the isolate as to not leak memory.
      
      This CL preserves the JSMessageObject when the debugger is active and stores
      the JSMessageObject on the rejected promise itself. The inspector is changed
      to retrieve the JSMessageObject in the existing catch handler and pass the
      information along to the frontend.
      
      Drive-by: This CL removes a inspector test that made assumptions when a promise
      is cleaned up by the GC. These assumptions no longer hold since we hold on to
      the promise longer.
      
      Bug: chromium:1021921
      Change-Id: Id0380e2cf3bd79aca05191bc4f3c616f6ced8db7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1967375
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65497}
      b15c02d0
  26. 06 Dec, 2019 1 commit
    • Simon Zünd's avatar
      Reland "Implement top-level await for REPL mode" · f96f9312
      Simon Zünd authored
      This is a reland of 5bddc0e1
      
      The original CL was speculatively reverted as it was suspected to
      cause failures on the non-determinism bot. This was ultimately
      confirmed to not be the case, so this CL is safe to reland as-is.
      
      Original change's description:
      > Implement top-level await for REPL mode
      >
      > Design doc: bit.ly/v8-repl-mode
      >
      > This CL allows the usage of 'await' without wrapping code in an async
      > function when using REPL mode in global evaluate. REPL mode evaluate
      > is changed to *always* return a Promise. The resolve value of the
      > promise is the completion value of the REPL script.
      >
      > The implementation is based on two existing mechanisms:
      >   - Similar to async functions, the content of a REPL script is
      >     enclosed in a synthetic 'try' block. Any thrown error
      >     is used to reject the Promise of the REPL script.
      >
      >   - The content of the synthetic 'try' block is also re-written the
      >     same way a normal script is. This is, artificial assignments to
      >     a ".result" variable are inserted to simulate a completion
      >     value. The difference for REPL scripts is, that ".result" is
      >     used to resolve the Promise of the REPL script.
      >
      >   - ".result" is not returned directly but wrapped in an object
      >     literal: "{ .repl_result: .result}". This is done to prevent
      >     resolved promises from being chained and resolved prematurely:
      >
      >     > Promse.resolve(42);
      >
      >     should evaluate to a promise, not 42.
      >
      > Bug: chromium:1021921
      > Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65273}
      
      TBR: yangguo@chromium.org,verwaest@chromium.org
      Bug: chromium:1021921
      Change-Id: I95c5dc17593161009a533188f91b4cd67234c32f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1954388Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65360}
      f96f9312
  27. 04 Dec, 2019 1 commit
    • Maya Lekova's avatar
      Revert "Implement top-level await for REPL mode" · 99005f33
      Maya Lekova authored
      This reverts commit 5bddc0e1.
      
      Reason for revert: Possible culprit for https://bugs.chromium.org/p/chromium/issues/detail?id=1029863
      
      Original change's description:
      > Implement top-level await for REPL mode
      > 
      > Design doc: bit.ly/v8-repl-mode
      > 
      > This CL allows the usage of 'await' without wrapping code in an async
      > function when using REPL mode in global evaluate. REPL mode evaluate
      > is changed to *always* return a Promise. The resolve value of the
      > promise is the completion value of the REPL script.
      > 
      > The implementation is based on two existing mechanisms:
      >   - Similar to async functions, the content of a REPL script is
      >     enclosed in a synthetic 'try' block. Any thrown error
      >     is used to reject the Promise of the REPL script.
      > 
      >   - The content of the synthetic 'try' block is also re-written the
      >     same way a normal script is. This is, artificial assignments to
      >     a ".result" variable are inserted to simulate a completion
      >     value. The difference for REPL scripts is, that ".result" is
      >     used to resolve the Promise of the REPL script.
      > 
      >   - ".result" is not returned directly but wrapped in an object
      >     literal: "{ .repl_result: .result}". This is done to prevent
      >     resolved promises from being chained and resolved prematurely:
      > 
      >     > Promse.resolve(42);
      > 
      >     should evaluate to a promise, not 42.
      > 
      > Bug: chromium:1021921
      > Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65273}
      
      TBR=yangguo@chromium.org,leszeks@chromium.org,verwaest@chromium.org,szuend@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:1021921
      Change-Id: I9eaea584e2e09f3dffcbbca3d75a3c9bcb0a1adf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948719Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65333}
      99005f33
  28. 02 Dec, 2019 1 commit
    • Simon Zünd's avatar
      Implement top-level await for REPL mode · 5bddc0e1
      Simon Zünd authored
      Design doc: bit.ly/v8-repl-mode
      
      This CL allows the usage of 'await' without wrapping code in an async
      function when using REPL mode in global evaluate. REPL mode evaluate
      is changed to *always* return a Promise. The resolve value of the
      promise is the completion value of the REPL script.
      
      The implementation is based on two existing mechanisms:
        - Similar to async functions, the content of a REPL script is
          enclosed in a synthetic 'try' block. Any thrown error
          is used to reject the Promise of the REPL script.
      
        - The content of the synthetic 'try' block is also re-written the
          same way a normal script is. This is, artificial assignments to
          a ".result" variable are inserted to simulate a completion
          value. The difference for REPL scripts is, that ".result" is
          used to resolve the Promise of the REPL script.
      
        - ".result" is not returned directly but wrapped in an object
          literal: "{ .repl_result: .result}". This is done to prevent
          resolved promises from being chained and resolved prematurely:
      
          > Promse.resolve(42);
      
          should evaluate to a promise, not 42.
      
      Bug: chromium:1021921
      Change-Id: I00a5aafd9126ca7c97d09cd8787a3aec2821a67f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1900464Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65273}
      5bddc0e1
  29. 26 Nov, 2019 1 commit
  30. 25 Nov, 2019 1 commit
  31. 15 Nov, 2019 1 commit
  32. 14 Nov, 2019 1 commit