1. 05 Oct, 2020 1 commit
  2. 01 Oct, 2020 1 commit
  3. 29 Sep, 2020 1 commit
  4. 25 Sep, 2020 1 commit
  5. 31 Aug, 2020 1 commit
  6. 22 Jun, 2020 1 commit
  7. 20 May, 2020 1 commit
  8. 13 May, 2020 1 commit
  9. 24 Apr, 2020 2 commits
    • Timothy Gu's avatar
      Reland "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 1aa51b49
      Timothy Gu authored
      This is a reland of 29c1eab9
      
      Original change's description:
      > [builtins] Clean up the use of class_name / ES5 [[Class]]
      >
      > Before ES2015, the ES spec had a [[Class]] internal slot for all
      > objects, which Object.prototype.toString() would use to figure the
      > returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      > all objects, with the @@toStringTag well-known symbol the proper way to
      > change Object.prototype.toString() output.
      >
      > At the time, spec-identical handling without the use of [[Class]] was
      > implemented in V8 for all objects other than API objects, where issues
      > with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      > @@toStringTag on API class prototypes to manage the
      > Object.prototype.toString() output, so the legacy [[Class]] handling in
      > V8 has not been necessary for the past couple of years.
      >
      > This CL removes the remaining legacy [[Class]] handling in
      > Object.prototype.toString(), JSReceiver::class_name(), and
      > GetConstructorName(). However, it does not remove the class_name field
      > in FunctionTemplateInfo, as it is still used for the `name` property of
      > created functions.
      >
      > This CL also cleans up other places in the codebase that still reference
      > [[Class]].
      >
      > This change should have minimal impact on web-compatibility. For the
      > change to be observable, a script must do one of the following:
      >
      > 1. delete APIConstructor.prototype[Symbol.toStringTag];
      > 2. Object.setPrototypeOf(apiObject, somethingElse);
      >
      > Before this CL, these changes will not change the apiObject.toString()
      > output. But after this CL, they will make apiObject.toString() show
      > "[object Object]" (in the first case) or the @@toStringTag of the other
      > prototype (in the latter case).
      >
      > However, both are deemed unlikely. @@toStringTag is not well-known
      > feature of JavaScript, nor does it get tampered much on API
      > constructors. In the second case, setting the prototype of an API object
      > would effectly render the object useless, as all its methods (including
      > property getters/setters) would no longer be accessible.
      >
      > Currently, @@toStringTag-based API object branding is not yet
      > implemented by other browsers. This V8 bug in particular has been an
      > impediment to standardizing toString behavior. Fixing this bug will
      > unblock [3] and lead to a better Web IDL spec, and better toString()
      > compatibility for all.
      >
      > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      > [3]: https://github.com/heycam/webidl/pull/357
      >
      > Bug: chromium:793406
      > Cq-Include-Trybots: luci.chromium.try:linux-rel
      > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      > Commit-Queue: Timothy Gu <timothygu@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67327}
      
      Bug: chromium:793406
      Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163881
      Auto-Submit: Timothy Gu <timothygu@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67361}
      1aa51b49
    • Bill Budge's avatar
      Revert "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 213016d6
      Bill Budge authored
      This reverts commit 29c1eab9.
      
      Reason for revert: Causes Blink test failures:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222
      
      Original change's description:
      > [builtins] Clean up the use of class_name / ES5 [[Class]]
      > 
      > Before ES2015, the ES spec had a [[Class]] internal slot for all
      > objects, which Object.prototype.toString() would use to figure the
      > returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      > all objects, with the @@toStringTag well-known symbol the proper way to
      > change Object.prototype.toString() output.
      > 
      > At the time, spec-identical handling without the use of [[Class]] was
      > implemented in V8 for all objects other than API objects, where issues
      > with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      > @@toStringTag on API class prototypes to manage the
      > Object.prototype.toString() output, so the legacy [[Class]] handling in
      > V8 has not been necessary for the past couple of years.
      > 
      > This CL removes the remaining legacy [[Class]] handling in
      > Object.prototype.toString(), JSReceiver::class_name(), and
      > GetConstructorName(). However, it does not remove the class_name field
      > in FunctionTemplateInfo, as it is still used for the `name` property of
      > created functions.
      > 
      > This CL also cleans up other places in the codebase that still reference
      > [[Class]].
      > 
      > This change should have minimal impact on web-compatibility. For the
      > change to be observable, a script must do one of the following:
      > 
      > 1. delete APIConstructor.prototype[Symbol.toStringTag];
      > 2. Object.setPrototypeOf(apiObject, somethingElse);
      > 
      > Before this CL, these changes will not change the apiObject.toString()
      > output. But after this CL, they will make apiObject.toString() show
      > "[object Object]" (in the first case) or the @@toStringTag of the other
      > prototype (in the latter case).
      > 
      > However, both are deemed unlikely. @@toStringTag is not well-known
      > feature of JavaScript, nor does it get tampered much on API
      > constructors. In the second case, setting the prototype of an API object
      > would effectly render the object useless, as all its methods (including
      > property getters/setters) would no longer be accessible.
      > 
      > Currently, @@toStringTag-based API object branding is not yet
      > implemented by other browsers. This V8 bug in particular has been an
      > impediment to standardizing toString behavior. Fixing this bug will
      > unblock [3] and lead to a better Web IDL spec, and better toString()
      > compatibility for all.
      > 
      > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      > [3]: https://github.com/heycam/webidl/pull/357
      > 
      > Bug: chromium:793406
      > Cq-Include-Trybots: luci.chromium.try:linux-rel
      > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      > Commit-Queue: Timothy Gu <timothygu@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67327}
      
      TBR=verwaest@chromium.org,timothygu@chromium.org
      
      Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:793406
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67349}
      213016d6
  10. 23 Apr, 2020 1 commit
    • Timothy Gu's avatar
      [builtins] Clean up the use of class_name / ES5 [[Class]] · 29c1eab9
      Timothy Gu authored
      Before ES2015, the ES spec had a [[Class]] internal slot for all
      objects, which Object.prototype.toString() would use to figure the
      returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      all objects, with the @@toStringTag well-known symbol the proper way to
      change Object.prototype.toString() output.
      
      At the time, spec-identical handling without the use of [[Class]] was
      implemented in V8 for all objects other than API objects, where issues
      with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      @@toStringTag on API class prototypes to manage the
      Object.prototype.toString() output, so the legacy [[Class]] handling in
      V8 has not been necessary for the past couple of years.
      
      This CL removes the remaining legacy [[Class]] handling in
      Object.prototype.toString(), JSReceiver::class_name(), and
      GetConstructorName(). However, it does not remove the class_name field
      in FunctionTemplateInfo, as it is still used for the `name` property of
      created functions.
      
      This CL also cleans up other places in the codebase that still reference
      [[Class]].
      
      This change should have minimal impact on web-compatibility. For the
      change to be observable, a script must do one of the following:
      
      1. delete APIConstructor.prototype[Symbol.toStringTag];
      2. Object.setPrototypeOf(apiObject, somethingElse);
      
      Before this CL, these changes will not change the apiObject.toString()
      output. But after this CL, they will make apiObject.toString() show
      "[object Object]" (in the first case) or the @@toStringTag of the other
      prototype (in the latter case).
      
      However, both are deemed unlikely. @@toStringTag is not well-known
      feature of JavaScript, nor does it get tampered much on API
      constructors. In the second case, setting the prototype of an API object
      would effectly render the object useless, as all its methods (including
      property getters/setters) would no longer be accessible.
      
      Currently, @@toStringTag-based API object branding is not yet
      implemented by other browsers. This V8 bug in particular has been an
      impediment to standardizing toString behavior. Fixing this bug will
      unblock [3] and lead to a better Web IDL spec, and better toString()
      compatibility for all.
      
      [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      [3]: https://github.com/heycam/webidl/pull/357
      
      Bug: chromium:793406
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      Commit-Queue: Timothy Gu <timothygu@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67327}
      29c1eab9
  11. 16 Apr, 2020 1 commit
  12. 20 Mar, 2020 2 commits
  13. 02 Mar, 2020 2 commits
  14. 21 Feb, 2020 1 commit
  15. 19 Feb, 2020 1 commit
  16. 24 Jan, 2020 1 commit
  17. 22 Jan, 2020 1 commit
  18. 21 Jan, 2020 1 commit
  19. 04 Dec, 2019 1 commit
  20. 06 Nov, 2019 2 commits
    • Simon Zünd's avatar
      Connect REPL mode to the V8 inspector · 702f2bad
      Simon Zünd authored
      There already exists a optional boolean flag 'replMode' for the
      'Runtime.evaluate' command. This CL ferries the flag from the inspector
      to DebugEvaluate::Global.
      
      The existing DebugEvaluate::GlobalREPL is removed in favor of a
      the REPLMOde enum to reduce code duplication.
      
      Bug: chromium:1018158
      Change-Id: Iafb43a3015b6876a02ac0db6cdfcac2cfa388862
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881149
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64801}
      702f2bad
    • Simon Zünd's avatar
      Introduce REPL mode · fbcc2e87
      Simon Zünd authored
      Design doc: bit.ly/v8-repl-mode
      
      This CL adds a new REPL mode that can be used via
      DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration
      of 'let' bindings at the moment. Example:
      
      REPL Input 1: let x = 21;
      REPL Input 2: let x = 42;
      
      This would normally throw a SyntaxError, but works in REPL mode.
      
      The implementation is done by:
        - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo}
          and script {Scope}.
        - Each global let declaration still gets a slot reserved in the
          respective {ScriptContext}.
        - When a new REPL mode {ScriptContext} is created, name clashes
          for let bindings are not reported as errors.
        - Declarations, loads and stores for global let in REPL mode are
          now "load/store global" instead of accessing their respective
          context slot directly. This causes a lookup in the ScriptContextTable
          where the found slot for each name is guaranteed to be the same
          (the first one).
      
      Bug: chromium:1004193, chromium:1018158
      Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64793}
      fbcc2e87
  21. 27 Sep, 2019 1 commit
  22. 11 Sep, 2019 1 commit
    • Simon Zünd's avatar
      Change debug-evaluate from a whitelist to a blacklist approach · 2e11dff7
      Simon Zünd authored
      This CL changes how variables are resolved during debug evaluate.
      We now re-parse the whole script when creating a ScopeIterator.
      This gives us accurate scope information for all parent scopes of the
      closure in which we stopped. Using this information, we build
      blacklists of stack-allocated variables. Each context on the chain
      in between the closure context up to the original native context is
      wrapped in a debug-evaluate context with such a blacklist attached.
      Variable lookup for debug-evalute contexts then works as follows:
      
        1) Look up in the materialized stack variables (stayed the same).
        2) Check the blacklist to find out whether to abort further lookup.
        3) Look up in the original context.
      
      Steps 1-3 is repeated for each debug-evaluate context, since they
      mirror the original context chain.
      
      R=ulan@chromium.org, yangguo@chromium.org
      
      Change-Id: Ied8e5786772c70566da9627ee3b7eff066fba2b4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1795354Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63666}
      2e11dff7
  23. 09 Aug, 2019 2 commits
  24. 18 Jul, 2019 1 commit
  25. 12 Jul, 2019 1 commit
  26. 11 Jul, 2019 3 commits
  27. 09 Jul, 2019 1 commit
  28. 18 Jun, 2019 1 commit
    • Z Nguyen-Huu's avatar
      Implement fastpath for proxy trap getPrototypeOf · 4e17a6be
      Z Nguyen-Huu authored
      ObjectGetPrototypeOf and ReflectGetPrototypeOf are now Torque builtins (previously CPP) and the Proxy path is implemented completely in Torque while everything else calls into runtime (and is thus a bit slower than previously).
      
      Perf improvement in micro-benchmark JSTests/Proxies
      Before:
      GetPrototypeOfWithoutTrap-Proxies(Score): 1876
      GetPrototypeOfWithTrap-Proxies(Score): 857
      
      After:
      GetPrototypeOfWithoutTrap-Proxies(Score): 2810
      GetPrototypeOfWithTrap-Proxies(Score): 3197
      
      Bug: v8:6664
      Change-Id: If60dda67d6e90c2d6f0ec743f6cb7c0fff54d607
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658717
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62256}
      4e17a6be
  29. 05 Jun, 2019 1 commit
  30. 24 May, 2019 4 commits
    • Yang Guo's avatar
      Move remaining files in src/ · f9a88acb
      Yang Guo authored
      TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org
      
      Bug: v8:9247
      Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61830}
      f9a88acb
    • Simon Zünd's avatar
      Reland "[array] Move Array#sort pre-processing to Torque" · 843b6646
      Simon Zünd authored
      This is a reland of 2b0ac2fb
      
      The layout test that caused this revert was fixed with:
      https://crrev.com/c/1627386
      
      Original change's description:
      > [array] Move Array#sort pre-processing to Torque
      >
      > This CL removes the "PrepareElementsForSort" runtime function, and
      > replaces it with a simpler version in Torque. The biggest difference
      > is that certain sparse configurations no longer have a fast-path.
      >
      > The Torque pre-processing step replaces the existing Torque mechanism that
      > copied already pre-processed elements into the "work" FixedArray. The Torque
      > compacting works as follows:
      >   - Iterate all elements from 0 to {length}
      >     - If the element is the hole: Do nothing.
      >     - If the element is "undefined": Increment undefined counter.
      >     - In all other cases, push the element into the "work" FixedArray.
      >
      > Then the "work" FixedArray is sorted as before. Writing the elements from
      > the "work" array back into the receiver, after sorting, has three steps:
      >   1. Copy the sorted elements from the "work" FixedArray to the receiver.
      >   2. Add previously counted number of "undefined" to the receiver.
      >   3. Depending on the backing store either delete properties or
      >      set them to the Hole up to {length}.
      >
      > Bug: v8:8714
      > Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61812}
      
      TBR: jgruber@chromium.org
      Bug: v8:8714
      Change-Id: If7613f6e5f37c5e0d649e8192195594bc6c32100
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627977
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Auto-Submit: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61827}
      843b6646
    • Simon Zünd's avatar
      Revert "[array] Move Array#sort pre-processing to Torque" · 70eeb22d
      Simon Zünd authored
      This reverts commit 2b0ac2fb.
      
      Reason for revert: Breaks scrollingcoordinator/non-fast-scrollable-region-nested.html layout test on https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/32241 
      
      Original change's description:
      > [array] Move Array#sort pre-processing to Torque
      > 
      > This CL removes the "PrepareElementsForSort" runtime function, and
      > replaces it with a simpler version in Torque. The biggest difference
      > is that certain sparse configurations no longer have a fast-path.
      > 
      > The Torque pre-processing step replaces the existing Torque mechanism that
      > copied already pre-processed elements into the "work" FixedArray. The Torque
      > compacting works as follows:
      >   - Iterate all elements from 0 to {length}
      >     - If the element is the hole: Do nothing.
      >     - If the element is "undefined": Increment undefined counter.
      >     - In all other cases, push the element into the "work" FixedArray.
      > 
      > Then the "work" FixedArray is sorted as before. Writing the elements from
      > the "work" array back into the receiver, after sorting, has three steps:
      >   1. Copy the sorted elements from the "work" FixedArray to the receiver.
      >   2. Add previously counted number of "undefined" to the receiver.
      >   3. Depending on the backing store either delete properties or
      >      set them to the Hole up to {length}.
      > 
      > Bug: v8:8714
      > Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61812}
      
      TBR=peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org,szuend@chromium.org
      
      Change-Id: If1c1bc07f38dfbd4bf6b6ce8f9d70714e7526877
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8714
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627976Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61814}
      70eeb22d
    • Simon Zünd's avatar
      [array] Move Array#sort pre-processing to Torque · 2b0ac2fb
      Simon Zünd authored
      This CL removes the "PrepareElementsForSort" runtime function, and
      replaces it with a simpler version in Torque. The biggest difference
      is that certain sparse configurations no longer have a fast-path.
      
      The Torque pre-processing step replaces the existing Torque mechanism that
      copied already pre-processed elements into the "work" FixedArray. The Torque
      compacting works as follows:
        - Iterate all elements from 0 to {length}
          - If the element is the hole: Do nothing.
          - If the element is "undefined": Increment undefined counter.
          - In all other cases, push the element into the "work" FixedArray.
      
      Then the "work" FixedArray is sorted as before. Writing the elements from
      the "work" array back into the receiver, after sorting, has three steps:
        1. Copy the sorted elements from the "work" FixedArray to the receiver.
        2. Add previously counted number of "undefined" to the receiver.
        3. Depending on the backing store either delete properties or
           set them to the Hole up to {length}.
      
      Bug: v8:8714
      Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61812}
      2b0ac2fb