1. 07 Feb, 2022 1 commit
  2. 10 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [parser] Split AstRawString and Parser zones · ef0b2aab
      Leszek Swirski authored
      This allows us to reuse AstValueFactory's string table across multiple
      parsers, while still releasing memory after each individual parse.
      
      This is mild overkill for all the single parses that don't reuse
      AstValueFactories, but there at least the AstRawStrings now end up
      grouped together in memory, so that might have mild cache benefits.
      
      Change-Id: I0b378760b601fa4ec6559a0dca5d7ed6f895e992
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322764Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78338}
      ef0b2aab
  3. 04 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move to full SFI keying · 14097e62
      Leszek Swirski authored
      Remove the concept of JobId from LazyCompileDispatcher, and make SFIs
      the canonical id for these jobs.
      
      This has several consequences:
      
        * We no longer split enqueing a job and registering a SFI with that
          job. We did this previously because we could not allocate SFIs in
          the Parser -- now with LocalHeap we can, so we do.
        * We remove the separate Job vector, and make the SFI IdentityMap
          hold pointers to Jobs directly. This requires a small amount of
          extra care to deallocate Jobs when removing them from the map,
          but it means not having to allocate new global handles for jobs.
        * The SFI is passed into the BackgroundCompileTask instead of the
          script, so our task finalization doesn't need the SFI anymore.
        * We no longer need to iterate ParallelTasks after compiling (to
          register SFIs), so we can get rid of ParallelTasks entirely and
          access the dispatcher directly from the parser.
      
      There are a few drive-bys since we're touching this code:
      
        * Jobs are move to have a "state" variable rather than a collection
          of bools, for stricter DCHECKing.
        * There's no longer a set of "currently running" jobs, since this
          was only used to check if a job is running, we can instead inspect
          the job's state directly.
        * s/LazyCompilerDispatcher/LazyCompileDispatcher/g
      
      Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77712}
      14097e62
  4. 18 Jun, 2021 1 commit
  5. 26 Apr, 2021 1 commit
  6. 29 Jan, 2021 1 commit
  7. 28 Jan, 2021 1 commit
    • Marja Hölttä's avatar
      Revert "Reland [super] Store home object in Context instead of JSFunction" · 12f8ac47
      Marja Hölttä authored
      This reverts commit f6450b97.
      
      Reason for revert: ClusterFuzz bugs
      
      Original change's description:
      > Reland [super] Store home object in Context instead of JSFunction
      >
      > 1) Computed property keys (esp functions in them) shouldn't be inside
      > the object literal scope.
      >
      > 2) I was using an imprecise "maybe uses super" and storing it to
      > preparse data. This won't fly, since it pollutes sister scopes and
      > leads to confusion wrt whether an object literal needs a home object
      > or not. Made it precise (mostly cancelling changes in the original CL).
      >
      > 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
      > this_function (which made it used) -> inconsistent scopes between
      > parsing and preparsing.
      >
      > 4) MultipleEntryBlockContextScope was messing up the accumulator
      >
      > Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
      >
      > This saves memory (the home object doesn't need to be stored for each
      > method, but only once per class) and hopefully makes the home object
      > a constant in the optimized code.
      >
      > Detailed documentation of the changes:
      > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
      >
      > Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
      > Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Marja Hölttä <marja@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72169}
      
      TBR=marja@chromium.org,leszeks@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9237
      Bug: chromium:1167918
      Bug: chromium:1167981
      Bug: chromium:1167988
      Bug: chromium:1168055
      Bug: chromium:1171195
      Bug: chromium:1171600
      Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72391}
      12f8ac47
  8. 19 Jan, 2021 2 commits
  9. 18 Jan, 2021 1 commit
  10. 07 Dec, 2020 1 commit
  11. 16 Nov, 2020 1 commit
  12. 12 Nov, 2020 1 commit
    • Daniel Clark's avatar
      Sort import assertions by code point order of the keys · 73f8a710
      Daniel Clark authored
      Per https://tc39.es/proposal-import-assertions/#sec-assert-clause-to-assertions,
      import assertions should be sorted by the import assertion [[Key]]s,
      in order to prevent hosts from relying on a changing order of the
      assertions to determine behavior.
      
      Prior to this change, the assertions were being sorted by pointer. With
      this CL, the keys are sorted using a code point ordering so that the
      order of the assertions received by the host will be stable and
      non-surprising.
      
      This CL also switches the SourceTextModuleDescriptor's ModuleRequestMap,
      RegularExportMap, and RegularImportMap to use the code point order
      comparison rather than their former shortlex sort.  This change will not
      be externally visible, but it seems best to make these consistent.
      
      In order to avoid #including the fairly large ast-value-factory.h
      into ast/modules.h, I changed ImportAssertions into a separate class
      definition rather than keeping it as a typedef.  The alternative would
      be to define a common AstRawStringComparer in ast-value-factory.h and
      then #include ast-value-factory.h in both ast/modules.h and
      parsing/parser.h so that the ImportAssertions typedef would have a
      full, shared definition of the AstRawStringComparer type.
      
      Bug: v8:10958
      Change-Id: I29c9544aa0a4340c56e1ee631be6cabb2a2eb921
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2533038
      Commit-Queue: Dan Clark <daniec@microsoft.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71165}
      73f8a710
  13. 11 Nov, 2020 1 commit
  14. 26 Oct, 2020 1 commit
  15. 15 Oct, 2020 1 commit
  16. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored
      This patch introduces a new LocalIsolate and LocalFactory, which use
      LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
      us to remove those classes, as well as the related OffThreadSpace,
      OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
      OffThreadLogger becomes LocalLogger.
      
      LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
      us to additionally remove the concept of "Finish" and "Publish" that the
      OffThreadIsolate had, and allows us to internalize strings directly with
      the newly-concurrent string table (where the implementation can now move
      to FactoryBase).
      
      This patch also removes the off-thread support from the deserializer
      entirely, as well as removing the LocalIsolateWrapper which allowed
      run-time distinction between Isolate and OffThreadIsolate. LocalHeap
      doesn't support the reservation model used by the deserializer, and we
      will likely move the deserializer to use LocalIsolate unconditionally
      once we figure out the details of how to do this.
      
      Bug: chromium:1011762
      
      Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  17. 10 Jul, 2020 1 commit
  18. 08 May, 2020 1 commit
  19. 06 May, 2020 2 commits
    • Leszek Swirski's avatar
      [offthread] Unify compiler.cc finalization logic · 58b12f63
      Leszek Swirski authored
      This patch unfies the finalization logic between the various unoptimized
      compilation paths in compiler.cc, taking the various post-processings and
      fixups needed for off-thread finalization and performing them in the same
      order for the other finalizations.
      
      It also unifies the general compilation path between streaming script
      compilation, main-thread script compilation, and main-thread lazy
      compilation, making the main-thread paths both use an iterative execution
      and finalization, and making all three use the same job helper methods
      and overall finalization helper.
      
      Bug: chromium:1011762
      Change-Id: Ibe56f6d2f75a2deffbe9e0b600ded8a02293b722
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172790
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67609}
      58b12f63
    • Leszek Swirski's avatar
      [parser] Move Compiler::Analyze into Parser · 65d738d4
      Leszek Swirski authored
      Move rewriting, scope analysis, and internalization, to be unconditional
      operations done after parsing rather than a separate compile phase. This
      removes some of the complexity about rememberering when to call
      Compiler::Analyze, and makes these paths a bit more uniform.
      
      Also, forbid allocating any more AST strings after AstValueFactory
      internalization, by nulling out the Zone. Add an InternalizePartial
      method which doesn't null out the zone for those cases where we do want
      to be able to allocate after internalizing (e.g. internalization before
      scope analysis).
      
      Change-Id: Id444246d8362a1d169baf664fc37657d9576fd96
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182458Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67608}
      65d738d4
  20. 02 Mar, 2020 1 commit
  21. 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
  22. 04 Feb, 2020 1 commit
    • 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
  23. 30 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [ast] Allocate cons strings on-demand · ddca3606
      Leszek Swirski authored
      Remove AstConsString "internalization", and instead make the conversion
      to heap String be on-demand with an Allocate method. We never actually
      need the heapified cons string more than once, so there's no need to do
      the internalization walk or do the next/string union dance in the
      AstConsString class.
      
      This also allows us to specify how we want to allocate the String at the
      call site. In particular, it allows us to allocate a flat SeqString rather
      rather than a ConsString. This allows us to avoid allocating ConsStrings
      which will just be passed to a flatten call, and especially avoid
      allocating dead ConsStrings in the off-thread old space.
      
      Bug: chromium:1011762
      Bug: chromium:1043168
      Change-Id: Id851f2f7529d92ad7e5388eb22823fd6d1959cd0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020953Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66042}
      ddca3606
  24. 17 Jan, 2020 1 commit
  25. 16 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored
      Add support for internalizing an AstValueFactory using the off-thread
      factory. Includes adding ConsString support to OffThreadFactory.
      
      This introduces a Handle union wrapper, which is used in locations that
      can store a Handle or an OffThreadHandle. This is used in this patch for
      the internalized "string" field of AST strings, and will be able to be
      used for other similar fields in other classes (e.g. the ScopeInfo
      handle in Scope, object boilerplate descriptor handles, the inferred
      name handle on FunctionLiterals, etc.). It has a Factory-templated
      getter which returns the appropriate handle for the factory, and a
      debug-only tag to make sure the right getter is used at runtime. This
      union wrapper currently decomposes implicitly to a Handle if the getter
      is not called, to minimise code changes, but this implicit conversion
      will likely be removed for clarity.
      
      Bug: chromium:1011762
      Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  26. 08 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      Revert "[ast] Add a Flatten method for AstConsString" · 4765addf
      Leszek Swirski authored
      This reverts commit 7a0ae73b.
      
      Reason for revert: Not useful after all, no tests, we can reland if we
      do end up needing it.
      
      Original change's description:
      > [ast] Add a Flatten method for AstConsString
      > 
      > This allows off-thread flattening.
      > 
      > Bug: chromium:1011762
      > Change-Id: If83f7bbcbf74165987a4c157184f5b92dc554971
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924437
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65075}
      
      TBR=leszeks@chromium.org,verwaest@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:1011762
      Change-Id: Ia72e5abdc9b6149a337565576806427dcd1d11c2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991484Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65638}
      4765addf
  27. 10 Dec, 2019 1 commit
  28. 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
  29. 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
  30. 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
  31. 20 Nov, 2019 2 commits
  32. 24 May, 2019 1 commit
  33. 22 May, 2019 1 commit
  34. 15 May, 2019 1 commit
  35. 13 May, 2019 1 commit
  36. 10 May, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[class] implement private method declarations" · bf07d790
      Ross McIlroy authored
      This reverts commit b9191bd3.
      
      Reason for revert: Clusterfuzz bugs
      BUG=chromium:961507,chromium:961508
      
      Original change's description:
      > [class] implement private method declarations
      >
      > This patch implements the declarations of private methods, the access
      > of private methods would be left to a future patch.
      > When a private methods declaration is encountered, we now:
      >
      > - Create a brand symbol during class evaluation and store it in the
      >   context.
      > - Create the closures for the private methods
      > - Load the brand from the context and store it in the instance in the
      >   constructor.
      >
      > Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
      >
      > Bug: v8:8330
      > Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61387}
      
      TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com
      
      Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8330
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61406}
      bf07d790
  37. 09 May, 2019 1 commit