All issues in interpreter bytecode handlers are fixed.

BUG=

Review-Url: https://codereview.chromium.org/2552883012
Cr-Commit-Position: refs/heads/master@{#41649}

Generalize Messages to include an error level.
Add a parameter to AddMessageHandler to select which error levels to receive, using a mask (default being just errors, i.e. the current behavior).

BUG=v8:4203
R=dgozman@chromium.org,machenbach@chromium.org,danno@chromium.org,bmeurer@chromium.org,jochen@chromium.org

Review-Url: https://codereview.chromium.org/2526703002
Cr-Commit-Position: refs/heads/master@{#41648}

BUG=672789
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2559113006
Cr-Commit-Position: refs/heads/master@{#41647}

BUG=

Review-Url: https://codereview.chromium.org/2562383002
Cr-Commit-Position: refs/heads/master@{#41646}

BUG=v8:5501, v8:5678

Review-Url: https://codereview.chromium.org/2539123002
Cr-Commit-Position: refs/heads/master@{#41645}

Revert of [heap] Initialize the owner on each page after lospace allocation (patchset #2 id:20001 of https://codereview.chromium.org/2565713002/ )

Reason for revert:
Tree closer: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/12409

Original issue's description:
> [heap] Initialize the owner on each page after lospace allocation
>
> The least two bits of the owner field of a Page are used to determine
> whether the Page is part of a large object. If these bits are not equal
> to 0x11, the page is part of a large object and needs special handling
> e.g. in MemoryChunk::FromAnyPointerAddress to determine which chunk it
> belongs to.
>
> This CL fixes an issue in which the store buffer overflows after
> a large object space allocation but before the object has been fully
> initialized. Store buffer overflow handling attempts to look up the
> chunk of a page, but fails to do so correctly since the page's owner
> field has not yet been initialized.
>
> This CL ensures that the owner field of all pages belonging to a large
> object allocation are initialized to a value that is interpreted
> correctly.
>
> BUG=chromium:672041
>
> Committed: https://crrev.com/9b6808bfb5366beebe3af30a06f9851edb2039d4
> Cr-Commit-Position: refs/heads/master@{#41641}

TBR=mlippautz@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:672041

Review-Url: https://codereview.chromium.org/2562273004
Cr-Commit-Position: refs/heads/master@{#41644}

BUG=673240
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2565343002
Cr-Commit-Position: refs/heads/master@{#41643}

This CL moves all methods related to scripts and eval origin (HasScript,
GetScript, IsEval, GetEvalOrigin) from JSStackFrame to StackFrameBase,
because it also applies to WasmFrames.
This makes the AppendFileLocation method append the same information to
WasmStackFrames and AsmJsWasmStackFrames than to JSStackFrames.

R=titzer@chromium.org, mstarzinger@chromium.org
BUG=v8:4203

Review-Url: https://codereview.chromium.org/2557923005
Cr-Commit-Position: refs/heads/master@{#41642}

The least two bits of the owner field of a Page are used to determine
whether the Page is part of a large object. If these bits are not equal
to 0x11, the page is part of a large object and needs special handling
e.g. in MemoryChunk::FromAnyPointerAddress to determine which chunk it
belongs to.

This CL fixes an issue in which the store buffer overflows after
a large object space allocation but before the object has been fully
initialized. Store buffer overflow handling attempts to look up the
chunk of a page, but fails to do so correctly since the page's owner
field has not yet been initialized.

This CL ensures that the owner field of all pages belonging to a large
object allocation are initialized to a value that is interpreted
correctly.

BUG=chromium:672041

Review-Url: https://codereview.chromium.org/2565713002
Cr-Commit-Position: refs/heads/master@{#41641}

The current logic in Isolate::GetLocationFromStackTrace just ignores
wasm frames, making the computed location point to the first javascript
frame, like this:

test.js:17: RuntimeError: divide by zero
module.exports.main();
               ^
RuntimeError: divide by zero
    at main (<WASM>[1]+5)
    at test.js:17:16

This CL not only fixes the location to point to the top-most wasm
frame, but also exposes to the embedder that the script of that location
is a wasm script, allowing for custom printing of wasm locations.
The Shell::ReportException method now checks for this flag, and prints
wasm locations like this:

<WASM>[0]+5: RuntimeError: divide by zero
RuntimeError: divide by zero
    at main (<WASM>[0]+5)
    at test/message/wasm-trap.js:15:16

R=titzer@chromium.org, yangguo@chromium.org
BUG=chromium:613110

Review-Url: https://codereview.chromium.org/2563673002
Cr-Commit-Position: refs/heads/master@{#41640}

This only happens if there is a asm.js-wasm-frame on top of the stack
trace, which was not covered by our tests so far. The regression test
create a stack overflow in asm.js code, triggering this case.

R=mstarzinger@chromium.org
CC=titzer@chromium.org, bradnelson@chromium.org
BUG=chromium:673241

Review-Url: https://codereview.chromium.org/2562333002
Cr-Commit-Position: refs/heads/master@{#41639}

BUG=673240
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2568773002
Cr-Commit-Position: refs/heads/master@{#41638}

Review-Url: https://codereview.chromium.org/2558283002
Cr-Commit-Position: refs/heads/master@{#41637}

Add the operator in preparation for actual perf work. The operator is replaced
by the same runtime call as before, during lowering.

The CallConstructWithSpreadParameters is a bit silly at the moment, but will
hold more once we add feedback.

BUG=v8:5659

Review-Url: https://codereview.chromium.org/2561103003
Cr-Commit-Position: refs/heads/master@{#41636}

For generator-based functions (e.g. async functions) we force variables to be
context-allocated.  Due to a bug in the parser, this didn't always work
correctly.  For instance, in "async function foo([a]) { ... }" the variable "a"
could become stack-allocated due to context allocation being forced on the wrong
scope.

Besides fixing this, I'm also cleaning up some related code in the async parsing
setup and adding some guards.

R=adamk@chromium.org, littledan@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2561093002
Cr-Commit-Position: refs/heads/master@{#41635}

BUG=chromium:673244

Review-Url: https://codereview.chromium.org/2568053002
Cr-Commit-Position: refs/heads/master@{#41634}

The evaluation order of this argument was accidentally changed when the
special-case was added for super calls with a final spread argument.

Review-Url: https://codereview.chromium.org/2563423002
Cr-Commit-Position: refs/heads/master@{#41633}

Review-Url: https://codereview.chromium.org/2566933002
Cr-Commit-Position: refs/heads/master@{#41632}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/15a6efa..7321edc

Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/dda089a..73e2473

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

Review-Url: https://codereview.chromium.org/2569653002
Cr-Commit-Position: refs/heads/master@{#41631}

BUG=

Review-Url: https://codereview.chromium.org/2565093003
Cr-Commit-Position: refs/heads/master@{#41630}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/ca0069e..15a6efa

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/707aaac..19565fd

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

Review-Url: https://codereview.chromium.org/2562213002
Cr-Commit-Position: refs/heads/master@{#41629}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/50196c9..ca0069e

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/0b7222f..707aaac

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

Review-Url: https://codereview.chromium.org/2560373002
Cr-Commit-Position: refs/heads/master@{#41628}

--asan test config passes --omit-quit which breaks this test on
  failure.

Review-Url: https://codereview.chromium.org/2546093002
Cr-Commit-Position: refs/heads/master@{#41627}

Port d4f01b8a

Original Commit Message:

    Add fast paths for holey smi and object arrays to
    Function.prototype.apply, Reflect.apply and Reflect.construct.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Review-Url: https://codereview.chromium.org/2566793002
Cr-Commit-Position: refs/heads/master@{#41626}

Forcing finalization after reaching allocation limit regresses gc pause
time in benchmarks as we have to do a lot of non-incremental marking work.

This patch allows overshoot of the limit by some margin.

BUG=chromium:670675,chromium:671994
TBR=mlippautz@chromium.org

Review-Url: https://codereview.chromium.org/2554423005
Cr-Commit-Position: refs/heads/master@{#41625}

BUG=672785
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2566683002
Cr-Commit-Position: refs/heads/master@{#41624}

This fixes the corner-case where the method in question failed to lookup
the very last deoptimization bailout without subsequent entries within
the relocation info. Also enable a test covering this.

R=tebbi@chromium.org
TEST=cctest/test-cpu-profiler/CollectDeoptEvents

Review-Url: https://codereview.chromium.org/2565733002
Cr-Commit-Position: refs/heads/master@{#41623}

Because the parser optimizes !123 -> false,
we allow booleans in expressions (but not parameter annotations).
Allow this in asm-wasm-builder.
Turn on an early out case in asm-typer that is fine.

BUG=672784
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2561193003
Cr-Commit-Position: refs/heads/master@{#41622}

R=bradnelson@chromium.org, ahaas@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2568493002
Cr-Commit-Position: refs/heads/master@{#41621}

Thanks for pointing this out to me!

R=clemensh@chromium.org
BUG=v8:5731

Review-Url: https://codereview.chromium.org/2565743002
Cr-Commit-Position: refs/heads/master@{#41620}

Logging for --perf-prof is not GC safe. Now, we are going to
emit source position info for optimized code when we are
profiling, logging, or debugging, and under the same condition,
pre-compute the line ends array for line number computation.

R=tebbi@chromium.org
BUG=v8:5730

Review-Url: https://codereview.chromium.org/2562973002
Cr-Commit-Position: refs/heads/master@{#41619}

NOTRY=True
NOPRESUBMIT=True
TBR=machenbach@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2567513004
Cr-Commit-Position: refs/heads/master@{#41618}

We should really think about having a static analysis to check for
such errors, and a bot executing it regularly.
This is not the first time I encounter declared functions that are
never defined.

R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2561333002
Cr-Commit-Position: refs/heads/master@{#41617}

By now the predicate in question is an exact negation of %IsAsmWasmCode
as the name intuitively implies. The need for two separate test methods
no longer exists and one of the two can be removed.

R=bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2562003002
Cr-Commit-Position: refs/heads/master@{#41616}

Review-Url: https://codereview.chromium.org/2559723002
Cr-Commit-Position: refs/heads/master@{#41615}

By now the compiler pipeline will not produce optimized code for asm.js
functions unless validation failed (even when --always-opt is enabled).
The related workaround in the testing predicate can be removed.

R=rmcilroy@chromium.org

Review-Url: https://codereview.chromium.org/2549463002
Cr-Commit-Position: refs/heads/master@{#41614}

In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").

This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
  operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
  table, but two (one for the call, one for the parent which does the
  type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
  two calls in the WASM_TO_JS wrapper (only if the module origin is
  asm.js).
- the StackFrame::State struct now also holds the callee_pc_address,
  which is set in ComputeCallerState. The WASM frame uses this
  information to determine whether the callee frame is WASM_TO_JS, and
  whether that frame is at the ToNumber conversion call.
- the same information is also stored in the FrameArray which is used
  to reconstruct the stack trace later.

R=titzer@chromium.org, bradnelson@chromium.org
CC=jgruber@chromium.org
BUG=v8:4203,v8:5724

Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
Review-Url: https://codereview.chromium.org/2555243002
Cr-Original-Commit-Position: refs/heads/master@{#41599}
Cr-Commit-Position: refs/heads/master@{#41613}

Too many crashes in Canary.

Review-Url: https://codereview.chromium.org/2554423004
Cr-Commit-Position: refs/heads/master@{#41612}

The deserialization of the {Scope::asm_module} predicate relies on a
context being present for such modules. This ensures we always allocate
such a context, even in cases where no variables are allocated in it.

R=neis@chromium.org
TEST=cctest/test-parsing/AsmModuleFlag
BUG=v8:5653

Review-Url: https://codereview.chromium.org/2561103004
Cr-Commit-Position: refs/heads/master@{#41611}

R=jgruber@chromium.org
BUG=v8:5510

Review-Url: https://codereview.chromium.org/2557043005
Cr-Commit-Position: refs/heads/master@{#41610}