Skip to content

V
V8
Switch branch/tag
  1. 12 Apr, 2021 1 commit
  3. 19 Mar, 2021 2 commits
  5. 15 Mar, 2021 1 commit
  7. 11 Mar, 2021 1 commit
  9. 18 Feb, 2021 1 commit
  11. 11 Feb, 2021 1 commit
  13. 09 Feb, 2021 1 commit
  15. 29 Jan, 2021 1 commit
  17. 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
  19. 19 Jan, 2021 2 commits
  21. 18 Jan, 2021 1 commit
  23. 13 Jan, 2021 1 commit
  25. 07 Jan, 2021 1 commit
  27. 15 Dec, 2020 2 commits
  29. 01 Dec, 2020 1 commit
  31. 26 Nov, 2020 1 commit
  33. 12 Nov, 2020 1 commit
  35. 03 Nov, 2020 3 commits
  37. 02 Nov, 2020 1 commit
  39. 24 Sep, 2020 1 commit
  41. 23 Sep, 2020 1 commit
  43. 18 Sep, 2020 2 commits
  45. 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
  47. 04 Aug, 2020 1 commit
  49. 30 Jul, 2020 1 commit
  51. 13 Jul, 2020 1 commit
  53. 22 Jun, 2020 1 commit
  55. 03 Jun, 2020 1 commit
  57. 02 Jun, 2020 2 commits
  59. 11 May, 2020 1 commit
  61. 23 Apr, 2020 1 commit
  63. 22 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      Reland^5 "[parser] Introduce UnoptimizedCompileFlags" · a3228bfc
      Leszek Swirski authored 
      This is a reland of e1b93a4f
which was a reland of 313d4844
which was a reland of 0a59e0cb
which was a reland of 146f5375
which was a reland of d91679bf

Give up on using C++ bitfields, go back to having base::BitField and
getters/setters.

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,szuend@chromium.org

Bug: v8:10314
Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67309}
      a3228bfc
  65. 21 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      Revert "Reland^4 "[parser] Introduce UnoptimizedCompileFlags"" · 33ea5e55
      Leszek Swirski authored 
      This reverts commit e1b93a4f.

Reason for revert: MSVC failing https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/13274

Original change's description:
> Reland^4 "[parser] Introduce UnoptimizedCompileFlags"
> 
> This is a reland of 313d4844
> which was a reland of 0a59e0cb
> which was a reland of 146f5375
> which was a reland of d91679bf
> 
> Manually zero out flags with memset, since GCC appears not to initialize
> the bitfield values to zero even with a default constructor.
> 
> 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,szuend@chromium.org,rmcilroy@chromium.org
> 
> Bug: v8:10314
> Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67271}

TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org

Change-Id: I0f41e847d4edae67e131cc6d0f782137ab73bac2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157377Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67275}
      33ea5e55