gcc requires the <algorithm> header for compiling std::sort. This issue
is not present when using Clang.

Change-Id: Ief7bfd6152754f71194c784b09dce39e357ddd5c
Reviewed-on: https://chromium-review.googlesource.com/c/1496280Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59973}

TBR=ulan@chromium.org

Change-Id: Ic886973633b3631a336b5e549bb4c910d82fe57e
Notry: true
Reviewed-on: https://chromium-review.googlesource.com/c/1495988
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59972}

NOTRY=true

Bug: chromium:933093
Change-Id: I0945adb70bcecb7542281eae39ce55929ad002ed
Reviewed-on: https://chromium-review.googlesource.com/c/1495985Reviewed-by: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59971}

This CL moves the following builtins from CSA to Torque:

TypedArray.prototype.forEach
TypedArray.prototype.reduce
TypedArray.prototype.reduceRight

A space-saving decision was made in the design -- instead of emitting
versions of the central loop for each ElementsKind, a function
pointer which knows how to read from the appropriate TypedArray
ElementsKind is constructed at the outset, and passed into the
loop. This enormously reduces codesize for the TypedArray builtins.
We'll have to see if the overhead of the builtin call affects
performance too adversely.

BUG: v8:8906
Change-Id: I808cd70f58ddbde18f85e5b2a9be0b883a3f6647
Reviewed-on: https://chromium-review.googlesource.com/c/1484292Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59970}

R=mathias@chromium.org

Bug: v8:8880
Change-Id: I6954ede6669f19d970ad4257fa4699da2db62fd3
Reviewed-on: https://chromium-review.googlesource.com/c/1495982Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59969}

Instead of accessing JsonValue struct fields directly, typed
accessors check that the tag matches with the type access.

Drive-by: The factory methods are now static methods on the JsonValue
type itself, making call-sites more readable.

R=tebbi@chromium.org

Bug: v8:8880
Change-Id: I49b37b3ba8eaf1153b8aa93ea08913077c923fdc
Reviewed-on: https://chromium-review.googlesource.com/c/1495559
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59968}

Change-Id: Ie8109300ce134f3f9d0c1619f1375c29af2c8fa6
Reviewed-on: https://chromium-review.googlesource.com/c/1494758Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59967}

R=clemensh@chromium.org

Change-Id: I1dec320464f5bc80e248cdf0b31b4a095bc54994
Reviewed-on: https://chromium-review.googlesource.com/c/1495981Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59966}

The interpreter is set up specially in cctests to allow more direct
testing. This requires sometimes to write special testing code in the
interpreter which is different than production code. This CL fixes one
instance of testing code which deals with indirect calls.

In production code, indirect calls go through the indirect function
table which can change over time. In cctests, however, the indirect
function table is not set up completely. In cctests the interpreter
uses information from the module instead to acquire the target of an
indirect call. In that testing code, calls to imported JS functions
were not handled. This handling gets added with this CL.


CC=fgm@chromium.org
R=titzer@chromium.org

Bug: v8:7431
Change-Id: I3b90d4ea8fec2633c010dd8359814440c7988509
Reviewed-on: https://chromium-review.googlesource.com/c/1495560Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59965}

The performance regression comes from the extra time of
ExtractHandlerContext called by TriggerPromiseReaction,
On the previous code, it takes the current Context from Isolate,
and on the typical case of the new code, the Context is taken from
the promise reaction function, that adds a few memory read ops and
a few conditional branches.

This CL adds Label::kDeferred to non-typical cases of
ExtractHandlerContext, so that newly added instructions have smaller
impact under the speculative execution.
On a local benchmark, this fixes half of the regression.

Bug: chromium:936717
Change-Id: I34ce858f77d7d604dd596711a239160ed8dac383
Reviewed-on: https://chromium-review.googlesource.com/c/1496774
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59964}

update the missing file in a2d9924c.
see https://chromium-review.googlesource.com/c/1470129

port 591408cb to mips.
see https://chromium-review.googlesource.com/c/1482915

Update the missing file in a4b19dcc.
see https://chromium-review.googlesource.com/c/1460474

Update the missing file in ad3546ab.
see https://chromium-review.googlesource.com/c/1434036

Fix compiler warnings.

Change-Id: Ie47b1d5aaa3c7f558def92255ce135b0fc0406ec
Reviewed-on: https://chromium-review.googlesource.com/c/1490995
Commit-Queue: Michael Hablich <hablich@chromium.org>
Reviewed-by: Predrag Rudic <prudic@wavecomp.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59963}

The {AsyncCompileJob} can now always be deleted when initial
compilation finished. The previous conditions are redudant, since
{baseline_compilation_finished()} is always true when calling
{FinishModule()}.

R=ahaas@chromium.org

Bug: v8:8689
Change-Id: I95c0cf83943630b83216c83db0edbabdfbd71284
Reviewed-on: https://chromium-review.googlesource.com/c/1494008Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59962}

After python3 migration, the new print usage started causing leftover character
issues.

This CL fixes the print usage.

R=clemensh@chromium.org,neis@chromium.org
CC=machenbach@chromium.org

Bug: v8:8918
Change-Id: Ibee06677c3bae3e1141579693aa16a539309a566
Reviewed-on: https://chromium-review.googlesource.com/c/1495558
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59961}

Design Doc: https://goo.gl/9G9d9k

The initial prototype consists of a few parts:

The VS Code extension is now built using TypeScript. The build artifact
is checked-in along side the extension. The extension now starts up
the language server when it is activated. The path to the LS
executable is configurable via VS Code settings.

The language server is a separate executable. It adds a light-weight
object model on top of a Json Parser for reading/writing LSP requests
and responses. The current server is very much bare-bones featurewise:
    - Tell the client that the server can handle "goto definition"
    - Recompile when Torque files change
    - Goto definition support for Macros/Builtins, local variables
      and arguments.

R=mathias@chromium.org, mvstanton@chromium.org, tebbi@chromium.org

Bug: v8:8880
Change-Id: Ie9b433e64ee63e9aa757b6bf71e5d52beb15b079
Reviewed-on: https://chromium-review.googlesource.com/c/1494354Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59960}

This pooling introduces severe lock contention for Liftoff compilation,
since each compilation uses its own Zone which does at least one
segment allocation.
It's also unclear whether pooling improves performance, since {malloc}
should implement a similar pooling mechanism, but better optimized for
multithreaded uses.

Feel free to revert if this introduces significant regressions.

R=verwaest@chromium.org

Bug: v8:8916
Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Change-Id: Iaf988bed898e35700f5f7f3310df8e01918de4c9
Reviewed-on: https://chromium-review.googlesource.com/c/1491632
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59959}

The original was reverted for breaking webkit layout tests:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8-Blink%20Linux%2064/30270

It also caused the following clusterfuzz failures:

chromium:935832
This was a correctness bug due to not properly handling the case of arrays with prototypes other
than Array.prototype. Accesses that were TheHole were not being handled property, both in bounds
holes in holey arrays and out of bounds on either holey or packed arrays. Handling was incorrect
both in access-assembler and in Turbofan.

chromium:935932
This bug was that there was no handling for Has checks on the global object. Turbofan was emitting
code for a store (the 'else' condition on 'access_mode == AccessMode::kLoad'). It hit a DCHECK in
debug builds but in release could show up in different places. This is the bug that caused the
webkit layout test failure that led to the revert.

Both bugs are fixed by in CL, and tests are added for those cases.

Bug: v8:8733, chromium:935932, chromium:935832
Change-Id: Iba0dfcfce6e15d2c0815a7670ece67bc13ba1925
Reviewed-on: https://chromium-review.googlesource.com/c/1493132Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Matt Gardner <magardn@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#59958}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/325e95d..04fc46b

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/827da84..9950df1

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/fe34723..a6d41e2

Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/960f195..8c67416

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/a287525..257c91c

TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org

Change-Id: I19df61991d87ab439d3dd2c88368081dc5632be3
Reviewed-on: https://chromium-review.googlesource.com/c/1495899Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#59957}

... to b13e24ccee66d7e0590ce1266db9c906e3648561

to support UTF16 strings with binary protocol (v8).

Original review here:
https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/1493312

Change-Id: I401c5d52d233805dc681bb23b40df99f2ea14992
Reviewed-on: https://chromium-review.googlesource.com/c/1493291
Commit-Queue: Johannes Henkel <johannes@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59956}

Assembler::AbortedCodeGeneration() is defined in assembler-arm64.h, but it calls
into Constant::Clear() which is defined in assembler-arm64.cc. This introduces
dependency to v8_base component when including assembler-arm64.h which is not
always possible like for V8 unittests target. To fix this, we could define both
in the same file, like Assembler::IsConstPoolEmpty() calls Constant::Clear() and
both are defined in assembler-arm64.h, so it works fine.

Bug: chromium:893460
Change-Id: I895cf0147950fca20142ea5ed18bcd020c1ab866
Reviewed-on: https://chromium-review.googlesource.com/c/1493293Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59955}

This provides a single point where read-only space sharing will be
controlled. Eventually ReadOnlyDeserializer will take ReadOnlyHeap
instead of Isolate, first steps include
https://chromium-review.googlesource.com/c/v8/v8/+/1483054

Bug: v8:7464
Change-Id: I213819aeca6fca335235025c9195edf474230eda
Reviewed-on: https://chromium-review.googlesource.com/c/1489087
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59954}

Change-Id: I4d774452e4537ba507bab87ac0a197d17a2f2862
Reviewed-on: https://chromium-review.googlesource.com/c/1494759Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59953}

This changes DebugObjectCache to be a vector of Handles rather than
tagged pointers, meaning it's not GC-safe.

This will allow PrintStack to allocate memory if required (if for
instance source positions must be regenerated).

Bug: v8:8834, v8:8510
Change-Id: Ieec9a827af9abbcb9b5b237d79984eedf0cdcc57
Reviewed-on: https://chromium-review.googlesource.com/c/1494755Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59952}

Rather than manually tracking basic blocks in the bytecode array builder,
use the existing dead code elimination to generate an implicit return iff
the block ending the bytecode is not dead by the time all statements have
been visited.

Change-Id: I9520486a523ec4e01bc203e9a847eb1f57b130b6
Reviewed-on: https://chromium-review.googlesource.com/c/1494756Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59951}

1) Rename {size()} to {total_size()} because
   {size() != end() - start()}.
2) Avoid undefined behaviour when creating segments, i.e. construct
   them via a constructor.
3) Minor drive-by cleanups.

R=mstarzinger@chromium.org

Bug: v8:8834
Change-Id: I3de47b2a775cf277e2f01ba5482afbd400acd06c
Reviewed-on: https://chromium-review.googlesource.com/c/1493926
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59950}

Avoid atomicops, use std::atomic instead.

R=ishell@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
Bug: v8:8834, v8:8926
Change-Id: I07bc7bbe079fc4a138feb4d8fda91eb57046846d
Reviewed-on: https://chromium-review.googlesource.com/c/1491609Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59949}

This is a reland of 35269f77

Switches on an expression that unconditionally throws would have all their
case statements dead, causing a DCHECK error in the SwitchBuilder. This
fixes up the DCHECK to allow dead labels.

Original change's description:
> [ignition] Skip binding dead labels
>
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
>
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
>
> As a drive-by, remove the unused Bind(target,label) function.
>
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}

TBR=rmcilroy@chromium.org

Bug: chromium:934166
Change-Id: If6eab4162106717ce64a2dc477000c6a76354cb4
Reviewed-on: https://chromium-review.googlesource.com/c/1494535Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59948}

This reverts commit 35269f77.

Reason for revert: Fuzzer unhappy: https://ci.chromium.org/p/v8/builders/ci/V8%20Fuzzer/29792

Original change's description:
> [ignition] Skip binding dead labels
> 
> BytecodeLabels for forward jumps may create a dead basic block if their
> corresponding jump was elided (due to it dead code elimination). We can
> avoid generating such dead basic blocks by skipping the label bind when
> no corresponding jump has been observed. This works because all jumps
> except JumpLoop are forward jumps, so we only have to special case one
> Bind for loop headers to bind unconditionally.
> 
> Since Binds are now conditional on a jump existing, we can no longer rely
> on using Bind to get the current offset (e.g. at the beginning of a try
> block). Instead, we now expose the current offset in the bytecode array
> writer. Conveniently, this means that we can be a bit smarter about basic
> blocks around these statements.
> 
> As a drive-by, remove the unused Bind(target,label) function.
> 
> Bug: chromium:934166
> Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
> Reviewed-on: https://chromium-review.googlesource.com/c/1488763
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59942}

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

Change-Id: I8118e54e0afa5e08b0a0a874c952f8a01f1c3242
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:934166
Reviewed-on: https://chromium-review.googlesource.com/c/1494534Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59947}

We sometimes store function indexes and number of functions as {size_t}
and sometimes as {int}. Unify a few places to be {int}.

R=ahaas@chromium.org

Change-Id: I1d204cbd9388245f97f291a469b32743457ab2c0
Reviewed-on: https://chromium-review.googlesource.com/c/1491607Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59946}

Bug: v8:8562
Change-Id: I1ad6d2febc9327e2ef93f0409f6fddf1cebb4834
Reviewed-on: https://chromium-review.googlesource.com/c/1494012Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Cr-Commit-Position: refs/heads/master@{#59945}

Since the performance implications of the patch
"[Torque] Reduce code size by combining FixedArray/FixedDoubleArray paths"
are negligible, I'll extend the pattern to all the array builtins,
providing a savings of about 20% per builtin.

Bug: v8:7672
Change-Id: Ib9aace4da38369842154065f5b4bcfb3ce2355d7
Reviewed-on: https://chromium-review.googlesource.com/c/1488768
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59944}

Some array builtins used branch hints for loop bounds checks,
causing all code after the inlined builtin to become deferred
code. This is detrimental for performance. This CL removes the
hints, which improves code scheduling a lot, on the micro
benchmark from the linked bug by 3x.

Bug: v8:8922
Change-Id: I64faaf763a385c80d80b8be5a4fb8e75dd731693
Reviewed-on: https://chromium-review.googlesource.com/c/1494011Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59943}

BytecodeLabels for forward jumps may create a dead basic block if their
corresponding jump was elided (due to it dead code elimination). We can
avoid generating such dead basic blocks by skipping the label bind when
no corresponding jump has been observed. This works because all jumps
except JumpLoop are forward jumps, so we only have to special case one
Bind for loop headers to bind unconditionally.

Since Binds are now conditional on a jump existing, we can no longer rely
on using Bind to get the current offset (e.g. at the beginning of a try
block). Instead, we now expose the current offset in the bytecode array
writer. Conveniently, this means that we can be a bit smarter about basic
blocks around these statements.

As a drive-by, remove the unused Bind(target,label) function.

Bug: chromium:934166
Change-Id: I532aa452fb083560d07b90da99caca0b1d082aa3
Reviewed-on: https://chromium-review.googlesource.com/c/1488763
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59942}

This CL introduces a new contextual 'LanguageSererData'. Its purpose
is to hold all the eagerly calculated data needed to answer
language server requests. The first thing collected are the
definitoins of some IdentifierExpresisons and macro/builtin
call-sites.

Collecting this data is not necessary for normal compilation, so it
is disabled by default and can be enabled via a Torque compiler
option. Since the holder class is a contextual for which no scope
exists during normal compilation, accidental collection of
unnecessary language server data *should* be prevented.

R=tebbi@chromium.org

Bug: v8:7793
Change-Id: Iffcebad4c420a0a51b1ed3c37a37c3475c6ab2e8
Reviewed-on: https://chromium-review.googlesource.com/c/1491594Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59941}

after previous change, which moved icons to .png format and
to subdirectory img/.

Bug: v8:7327
Notry: true
Change-Id: Iebbbe175cc65ed1f2e505084344a2b55864732e7
Reviewed-on: https://chromium-review.googlesource.com/c/1494009
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59940}

Change-Id: I19abd54f3c7825a99cbebd370092259cf8c21945
Notry: true
Bug: v8:7327
Reviewed-on: https://chromium-review.googlesource.com/c/1494007Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59939}

This lets foozzie call d8 with sanity output before doing the actual
correctness comparisons. This will make clusterfuzz dedupe cases on
the difference found in the sanity checks.

Also adding missing OWNERS file.

NOTRY=true

Bug: chromium:933076
Change-Id: I4229183726064cc0ad76da8fe432e1dbb601a7ba
Reviewed-on: https://chromium-review.googlesource.com/c/1491221
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59938}

This is a reland of b2f8280e, fixing
asan and msan invocations to use {Segment::capacity()} instead of
{Segment::size()}.

Original change's description:
> [zone] Teach ASan about the zone segment pool
>
> This adds proper poisoning/unpoisoning to segments put into the segment
> pool of an accounting allocator, and also marks a segment uninitialized
> when returning it from the pool. This gives ASan a better chance at
> catching use-after-free and others.
>
> Drive-by: Fix type check in ASAN_POISON_MEMORY_REGION
>
> R=mstarzinger@chromium.org
>
> Change-Id: Iadbdd7c0a0c80da8e7b9bb8f3399209715436073
> Reviewed-on: https://chromium-review.googlesource.com/c/1489086
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59932}

Change-Id: I3150a7f96fefd94bd96af2fdc24c302a4a5d0ea3
Reviewed-on: https://chromium-review.googlesource.com/c/1493866Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59937}

The SourceRangeAstVisitor has custom logic for blocks ending with a
statement that has a continuation range. In these cases, the trailing
continuation is removed which makes the reported coverage ranges a bit
nicer.

throw Error('foo') consists of an ExpressionStatement, with a
Throw expression stored within the statement. The source range itself
is stored with the Throw, not the statement.

We now properly extract the correct AST node for trailing throw
statements.

R=jgruber@chromium.org, neis@chromium.org, yangguo@chromium.org

Bug: v8:8691
Change-Id: Ibcbab79fbe54719a8993045040349c863b139011
Reviewed-on: https://chromium-review.googlesource.com/c/1480632
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59936}

Remove another use of atomicops.

R=mstarzinger@chromium.org

Bug: v8:8834
Change-Id: Ide1aa87f4bb4cdc4346fe7b1bf78b8118592c7ae
Reviewed-on: https://chromium-review.googlesource.com/c/1491603
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59935}

This reverts commit b2f8280e.

Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/25509

Original change's description:
> [zone] Teach ASan about the zone segment pool
> 
> This adds proper poisoning/unpoisoning to segments put into the segment
> pool of an accounting allocator, and also marks a segment uninitialized
> when returning it from the pool. This gives ASan a better chance at
> catching use-after-free and others.
> 
> Drive-by: Fix type check in ASAN_POISON_MEMORY_REGION
> 
> R=​mstarzinger@chromium.org
> 
> Change-Id: Iadbdd7c0a0c80da8e7b9bb8f3399209715436073
> Reviewed-on: https://chromium-review.googlesource.com/c/1489086
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59932}

TBR=mstarzinger@chromium.org,clemensh@chromium.org

Change-Id: Iacf322d04822382ea8e1f5abe1d5e72758adc399
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1493055Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59934}