1. 21 May, 2021 1 commit
  2. 30 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debugger] Don't attach source positions to implicit returns. · 379331b7
      Benedikt Meurer authored
      Previously we'd attach source positions to implicit returns that are
      generated when leaving an async function with a promise rejection. This
      was due to the use of `kNoSourcePosition` on the `end_position` in the
      `ReturnStatement` nodes as indicator to pick the return position from
      the function literal, instead of really not putting a source position on
      that specific `Return` bytecode.
      
      This CL adds a dedicated marker to `ReturnStatement` to express that the
      `BytecodeGenerator` should put the return position from the function
      literal there instead of overloading the meaning of `kNoSourcePosition`.
      
      Bug: chromium:901819, chromium:782461
      Fixed: chromium:1199919, chromium:1201706
      Change-Id: I3647e0c3d711e9c3d6ae44606b70ec92ad82e1cf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859945
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74301}
      379331b7
  3. 26 Apr, 2021 1 commit
  4. 19 Mar, 2021 2 commits
  5. 18 Feb, 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 Jan, 2021 1 commit
  11. 03 Nov, 2020 1 commit
  12. 02 Nov, 2020 1 commit
  13. 22 Oct, 2020 1 commit
  14. 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
  15. 10 Aug, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [ast] Store correct source position on ThisExpression · 8a9e3f64
      Sathya Gunasekaran authored
      Previously, all ThisExpression's had kNoSourcePositions leading to
      incorrect error messages like this:
      
        ➜ d8 -e "function t() { for (const x of this) {} } t();"
        unnamed:1: TypeError: undefined is not a function
        function t() { for (const x of this) {} } t();
                  ^
        TypeError: undefined is not a function
            at t (unnamed:1:11)
            at unnamed:1:43
      
      
      This patch allows creation of a ThisExpression with a source position,
      leading to a better error message:
      
        ➜ d8  -e "function t() { for (const x of this) {} } t();"
        unnamed:1: TypeError: this is not iterable
        function t() { for (const x of this) {} } t();
                                       ^
        TypeError: this is not iterable
            at t (unnamed:1:32)
            at unnamed:1:43
      
      
      This patch does not remove the existing cached version of
      ThisExpression and instead creates a new one when required.
      
      Bug: v8:6513
      Change-Id: Idee4fe8946a9b821d06ff4a5e7eaefe54874ec59
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345226Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69300}
      8a9e3f64
  16. 06 Aug, 2020 1 commit
    • Bill Budge's avatar
      Reland "[torque] Port some constructor builtins to Torque." · 83e4c8b1
      Bill Budge authored
      This is a reland of ce249dbb
      
      As it's unchanged,
      TBR=leszeks@chromium.org,tebbi@chromium.org
      
      Original change's description:
      > [torque] Port some constructor builtins to Torque.
      >
      > - FastNewFunctionContextEval
      > - FastNewFunctionContextFunction
      > - CreateEmptyLiteralObject
      > - CreateRegExpLiteral
      > - CreateEmptyArrayLiteral
      > - CreateShallowArrayLiteral
      > - CreateShallowObjectLiteral
      > - NumberConstructor
      > - ObjectConstructor
      > - GenericLazyDeoptContinuation
      >
      > Bug: v8:9891
      >
      > Change-Id: Idd4bf035d8dbeec03b9ef727e1bfb80eab4bc43c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2311411
      > Commit-Queue: Bill Budge <bbudge@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69082}
      
      Bug: v8:9891
      Change-Id: I566d4167c02488ef6a9a1c73015af5e2f484a31d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330382
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69281}
      83e4c8b1
  17. 30 Jul, 2020 1 commit
  18. 27 Jul, 2020 2 commits
  19. 13 Jul, 2020 1 commit
  20. 10 Jul, 2020 1 commit
  21. 08 Jul, 2020 1 commit
  22. 25 May, 2020 1 commit
  23. 08 May, 2020 1 commit
  24. 06 May, 2020 1 commit
    • 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
  25. 21 Apr, 2020 1 commit
  26. 09 Mar, 2020 1 commit
  27. 03 Mar, 2020 1 commit
    • 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
  28. 02 Mar, 2020 1 commit
  29. 20 Feb, 2020 1 commit
  30. 18 Feb, 2020 1 commit
  31. 13 Feb, 2020 1 commit
  32. 12 Feb, 2020 2 commits
  33. 11 Feb, 2020 1 commit
  34. 10 Feb, 2020 1 commit
  35. 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
  36. 06 Feb, 2020 1 commit