Skip to content

V
V8
Switch branch/tag
  1. 01 Dec, 2020 1 commit
  3. 26 Nov, 2020 1 commit
  5. 23 Nov, 2020 3 commits
  7. 24 Oct, 2020 1 commit
    • Camillo Bruni's avatar
      Reland "[runtime] Use Isolate::ThrowAt with MessageLocation" · 447915ef
      Camillo Bruni authored 
      This is a reland of eb6b4ce1

Skip test that serializes Error which references a Script. All errors
created by ThrowAt store the current Script under the
error_script_symbol.

Original change's description:
> [runtime] Use Isolate::ThrowAt with MessageLocation
>
> Fix various missing source positions when reporting parse and compile
> errors. Namely this fixes missing source positions when having invalid
> module imports.
>
> - Use Isolate::ThrowAt with valid MessageLocation objects
> - Change public Isolate::Throw to no longer accept MessageLocation to
>   avoid misues
> - Introduce private Isolate::ThrowInternal that accepts MessageLocation
>
> Bug: v8:6513
> Change-Id: I3ee633c9fff8c9d361bddb37f56e28a50c280ec1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467839
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70623}

Bug: v8:6513
Change-Id: Icba74f74178e28fbda0fd0c237eeb7bacbc33570
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487123Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70741}
      447915ef
  9. 19 Oct, 2020 2 commits
  11. 30 Sep, 2020 1 commit
  13. 10 Jun, 2020 1 commit
  15. 29 May, 2020 1 commit
  17. 26 May, 2020 1 commit
    • Seth Brenith's avatar
      Revert "[torque][cleanup] Use more precise field types in a few classes" · 16cb2d94
      Seth Brenith authored 
      This reverts commit 4e5fabae.

Reason for revert: performance regressions chromium:1085305, chromium:1084978

Original change's description:
> [torque][cleanup] Use more precise field types in a few classes
> 
> This change updates some Torque-defined classes to include more precise
> field types where possible. It also updates those classes to use
> @generateCppClass. One field was removed because it's unused
> (PrototypeInfo::validity_cell), and two fields in StackFrameInfo
> actually became less precise because they're based on Script::name,
> which is an embedder-provided untyped Local<Value>. (Automatically
> generated accessors pointed out this bug easily.)
> 
> This change also includes a couple of minor fixes in Torque.
> 
> Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67907}

TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com

Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67972}
      16cb2d94
  19. 19 May, 2020 1 commit
  21. 13 May, 2020 1 commit
  23. 11 May, 2020 1 commit
  25. 06 May, 2020 1 commit
  27. 30 Apr, 2020 1 commit
  29. 24 Apr, 2020 1 commit
  31. 23 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      [compile] Add an UnoptimizedCompileState class · 6458a529
      Leszek Swirski authored 
      Move the persistent compilation state and Isolate inputs (such as the
allocator, shared AST constants, hash seed, logger, etc.) which survives
across both parse and compile, out of ParseInfo and into a new
UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState
for per-thread state such as stack limit and RCS.

In particular, this new state survives the ParseInfo being destructed,
which means it is available after off-thread finalization. This allows a
followup to access the PendingCompilationErrorHandler after finalization
and report errors on merge.

Bug: v8:10314
Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67329}
      6458a529
  33. 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
  35. 21 Apr, 2020 4 commits
    • 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
    • Leszek Swirski's avatar
      Reland^4 "[parser] Introduce UnoptimizedCompileFlags" · e1b93a4f
      Leszek Swirski authored 
      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/+/2157372Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67271}
      e1b93a4f
    • Sathya Gunasekaran's avatar
      Revert "Reland^3 "[parser] Introduce UnoptimizedCompileFlags"" · a709f779
      Sathya Gunasekaran authored 
      This reverts commit 313d4844.

Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/6354

Original change's description:
> Reland^3 "[parser] Introduce UnoptimizedCompileFlags"
> 
> This is a reland of 0a59e0cb
> which was a reland of 146f5375
> which was a reland of d91679bf
> 
> Initializes the BackgroundCompileTasks's language_mode in the
> constructor (previously only initialized after successful parse) in case
> the parse failed. We still need to reset it after parse in case the
> language mode changed (because we encountered "use strict").
> 
> 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: Ieee0bbfade4fe0b56de03bff47a7364959608d6a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67265}

TBR=leszeks@chromium.org

Change-Id: I90ac035caa76d4c4baf5ce207247d1ce5169fb2f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157370Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67266}
      a709f779
    • Leszek Swirski's avatar
      Reland^3 "[parser] Introduce UnoptimizedCompileFlags" · 313d4844
      Leszek Swirski authored 
      This is a reland of 0a59e0cb
which was a reland of 146f5375
which was a reland of d91679bf

Initializes the BackgroundCompileTasks's language_mode in the
constructor (previously only initialized after successful parse) in case
the parse failed. We still need to reset it after parse in case the
language mode changed (because we encountered "use strict").

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: Ieee0bbfade4fe0b56de03bff47a7364959608d6a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67265}
      313d4844
  37. 20 Apr, 2020 5 commits
    • Francis McCabe's avatar
      Revert "Reland^2 "[parser] Introduce UnoptimizedCompileFlags"" · b89397c5
      Francis McCabe authored 
      This reverts commit 0a59e0cb.

Reason for revert: Still causing UBSAN issues:

https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729


Original change's description:
> Reland^2 "[parser] Introduce UnoptimizedCompileFlags"
> 
> This is a reland of d91679bf
> which was a reland of d91679bf
> 
> Fixes missing initialization of ParserBase::allow_eval_cache_
> 
> 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=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org
> 
> Bug: v8:10314
> Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67245}

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

Change-Id: I1c5f58cc5608217a149b04aa6f50bb3d7606c26d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157657Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67250}
      b89397c5
    • Leszek Swirski's avatar
      Reland^2 "[parser] Introduce UnoptimizedCompileFlags" · 0a59e0cb
      Leszek Swirski authored 
      This is a reland of d91679bf
which was a reland of d91679bf

Fixes missing initialization of ParserBase::allow_eval_cache_

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

Bug: v8:10314
Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030Reviewed-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@{#67245}
      0a59e0cb
    • Leszek Swirski's avatar
      Revert "Reland "[parser] Introduce UnoptimizedCompileFlags"" · 9f6eb557
      Leszek Swirski authored 
      This reverts commit 146f5375.

Reason for revert: UBSan (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10726?)

Original change's description:
> Reland "[parser] Introduce UnoptimizedCompileFlags"
> 
> This is a reland of d91679bf
> 
> This reland adds initializers for the output flags.
> 
> 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}
> 
> Bug: v8:10314
> Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67241}

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

Change-Id: I204eb9e4d0a5bfaeeefeb6b0f1c82856b57cb175
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157029Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67242}
      9f6eb557
    • Leszek Swirski's avatar
      Reland "[parser] Introduce UnoptimizedCompileFlags" · 146f5375
      Leszek Swirski authored 
      This is a reland of d91679bf

This reland adds initializers for the output flags.

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}

Bug: v8:10314
Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67241}
      146f5375
    • Marja Hölttä's avatar
      [Promise.any] Add AggregateError · f5a31f0b
      Marja Hölttä authored 
      Spec: https://github.com/tc39/proposal-promise-any

Bug: v8:9808
Change-Id: I568b2444df9f00f615f2cda1268e4ecc5b36667e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2139571
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67224}
      f5a31f0b
  39. 15 Apr, 2020 1 commit
  41. 03 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Reorganize source position lookup · 3aedafbb
      Clemens Backes authored 
      Instead of two copies of the lookup code in frames.cc and wasm-debug.cc,
put one lookup method on the WasmCode. This is where it belongs really,
since the WasmCode is the main input to the function (besides the
offset).

Also refactor how source positions are computed in WasmCompiledFrame.
Avoid going through the summary, which is unneccessarily complex. This
also adds another {byte_offset} accessor which can be used for
debugging.

Bug: v8:10235
Change-Id: I5c545ee302754b86009f09bedc5ff6e39ba664f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135726Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66991}
      3aedafbb
  43. 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
  45. 18 Feb, 2020 1 commit
  47. 05 Feb, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [callprinter] Correctly point to the incorrect spread arg · 1d0693e2
      Sathya Gunasekaran authored 
      The source position is set to the function call (console.log) not the
spread (..x), in the bytecode generator, as the spread operation is
done as part of the CallWithSpread bytecode.

The CallPrinter stops at the function call and doesn't look at the
arguments as well (in CallPrinter::VisitCall) to see if the error is
from an incorrect spread operation.


With this patch, we pass some state to the CallPrinter in the
CallWithSpread error case and check that in CallPrinter::VisitCall
before returning.

For the given source string:
```
x = undefined;
console.log(1, ...x);
```

Previously, the error was -

```
test.js:2: TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
console.log(1, ...x);
        ^
TypeError: console.log is not iterable (cannot read property Symbol(Symbol.iterator))
    at test.js:2:9
```


Now, the error is -

```
_test.js:2: TypeError: x is not iterable (cannot read property undefined)
console.log(1, ...x);
                  ^
TypeError: x is not iterable (cannot read property undefined)
    at _test.js:2:9
```

Bug: v8:10038
Change-Id: I199de9997f1d949c6f9b7b4f41d51f422b8b5131
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2037431Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66131}
      1d0693e2
  49. 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
  51. 30 Jan, 2020 1 commit
  53. 22 Jan, 2020 2 commits
  55. 21 Jan, 2020 1 commit
    • Clemens Backes's avatar
      Move decoded asm.js offset table off-heap · 87f09404
      Clemens Backes authored 
      The asm.js offset table exists in two forms: Delta-encoded in a byte
array, as generated during asm translation, and decoded, for faster
lookup.
This CL moves the encoded version from the {AsmWasmData} and
{WasmModuleObject} to the {WasmModule}, and stores it off-heap in a C++
array instead of a {ByteArray}.
Also, it moves the decoded version off-heap by storing it in a C++ data
structure that makes lookup easy, instead of encoding it again in
another {ByteArray}.

This change is a nice refactoring in itself, but it also prepares adding
more information to the offset table. For reconstructing the source code
of an asm.js function, we will need to store the start and end offsets
of the whole function as well (see linked bug).

R=jkummerow@chromium.org

Bug: chromium:667678
Change-Id: I79b789c3122dd8ba803cedc6bfdcc3d4b1fa0fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011108
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65900}
      87f09404