This CL turns on trap-if by default, and it changes the tests so that
traps in the cctests are also tested without trap-if.

R=titzer@chromium.org, clemensh@chromium.org, bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2647323002
Cr-Original-Commit-Position: refs/heads/master@{#42603}
Committed: https://chromium.googlesource.com/v8/v8/+/01c87ebe70fb569205432597f3105c708bba0fef
Review-Url: https://codereview.chromium.org/2647323002
Cr-Commit-Position: refs/heads/master@{#42688}

The reference map was only recorded when a frame was entered for the
runtime call, but it is also needed when the frame already exists.

R=titzer@chromium.org

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

Disabled until clusterfuzz issues are sorted.

BUG=v8:5203, v8:5215, chromium:685515, chromium:685476

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

- Declaring a variable called "this" for preparsed functions was unnecessary;
  DeclarationScope ctor already adds the variable.

- "arguments" for preparsed scopes need to be declared after parsing the
  function, like it's done in the parser.

- Now arguments_ can be the dummy variable, so adapted code to it.

- A previous refactoring CL ( https://codereview.chromium.org/2638333002 ) was
  incomplete; it had added ParserBase::ParseFunctionBody but
  PreParser::ParseFunction didn't call it. This CL completes that work. This is
  needed for getting "arguments" declared properly for preparsed functions.

- AllocateVariablesRecursively is already called for preparsed scopes (without
  this CL, that is), and it bails out early. However, before the bailout it used
  to dcheck num_stack_slots_ == 0; that is no longer true since we've done scope
  analysis for preparsed scopes.

- Test fix: we cannot have any lazy inner functions in the test, except the
  topmost lazy inner function. Such functions would also be lazy in the parser
  case, and the parser would just throw away their variables. Then the test
  tries to verify the preparsed data against the scopes without variables and fails.

- Disabled a test w/ a sloppy block function, will get that working again in the
  upcoming CLs.

BUG=v8:5516

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

The InterpreterTester class cobbles together a JSFunction from
a manually created bytecode and feedback vector. However it's
fragile against design changes in the way literal arrays and
feedback vectors are handled. It's better to let it hand in
a feedback vector metadata object, and allow the system to
create the vector from that.

BUG=v8:5456

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

First issue I found with my local fuzzing.

R=titzer@chromium.org
BUG=v8:5884

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

With creation frame we can show additional information with description of each async stack trace, which could help user to understand where promises were chained.
At least in case of Promise.resolve().then(foo1).then(foo2) we would be able to show following stack trace for break in foo2 callback:

foo2 (test.js:14:2)
-- Promise.resolve (test.js:29:14)--
-- Promise.resolve (test.js:28:14)--
promiseThen (test.js:30:2)

More details: https://docs.google.com/document/d/1u19N45f1gSF7M39mGsycJEK3IPyJgIXCBnWyiPeuJFE

BUG=v8:5738
R=dgozman@chromium.org,gsathya@chromium.org

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

Revert of [regexp] Create property on result for each named capture (patchset #9 id:160001 of https://codereview.chromium.org/2630233003/ )

Reason for revert:
Some heap tests are broken leading to failures on nosnap builds:

https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/3677

Reverting again until tests are fixed to keep bots green.

Original issue's description:
> [regexp] Store named captures on the regexp result
>
> This implements storing named captures on the regexp result object.
> For instance, /(?<a>.)/u.exec("b") will return a result such that:
>
> result.group.a  // "b"
>
> https://tc39.github.io/proposal-regexp-named-groups/
>
> BUG=v8:5437
>
> Review-Url: https://codereview.chromium.org/2630233003
> Cr-Original-Original-Commit-Position: refs/heads/master@{#42532}
> Committed: https://chromium.googlesource.com/v8/v8/+/70000946eb2a9155679528702a766219a1fcf154
> Review-Url: https://codereview.chromium.org/2630233003
> Cr-Original-Commit-Position: refs/heads/master@{#42570}
> Committed: https://chromium.googlesource.com/v8/v8/+/ee94fa11ed63477393c6534c352ebac6e502396c
> Review-Url: https://codereview.chromium.org/2630233003
> Cr-Commit-Position: refs/heads/master@{#42676}
> Committed: https://chromium.googlesource.com/v8/v8/+/8bf52534f6bf86821a1589dcbcb7335052c1f94f

TBR=yangguo@chromium.org,littledan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5437

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

We turn a JSCallFunction node for

  f.apply(receiver, arguments)

into a JSCallForwardVarargs node, when the arguments refers to the
arguments of the outermost optimized code object, i.e. not an inlined
arguments, and the apply method refers to Function.prototype.apply,
and there's no other user of arguments except in frame states.

We also replace the arguments node in the graph with a marker for
the Deoptimizer similar to Crankshaft to make sure we don't materialize
unused arguments just for the sake of deoptimization. We plan to replace
this with a saner EscapeAnalysis based solution soon.

R=jarin@chromium.org
BUG=v8:5267,v8:5726

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

This makes sure that the deoptimizer preserves the exact bit pattern of
floating-point values (both 32-bit and 64-bit) up to the point where a
potential {HeapNumber} is allocated. It in turn allows us to correctly
recognize the {hole_nan_value} when stored into a {FixedDouleArray}.

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-684208
BUG=chromium:684208

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

Also show size when --trace-asm-time is on.

BUG=
R=mtrofin@chromium.org

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

In practice, Emscripten seems to emit cond?+a:+b type return
expressions. This is not allowed by the spec or errata, but we need
to support it for compatibility.

Similar patterns with ints / signed, do not seem to be supported.

BUG=v8:5891
R=mtrofin@chromium.org,aseemgarg@chromium.org

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

This implements storing named captures on the regexp result object.
For instance, /(?<a>.)/u.exec("b") will return a result such that:

result.group.a  // "b"

https://tc39.github.io/proposal-regexp-named-groups/

BUG=v8:5437

Review-Url: https://codereview.chromium.org/2630233003
Cr-Original-Original-Commit-Position: refs/heads/master@{#42532}
Committed: https://chromium.googlesource.com/v8/v8/+/70000946eb2a9155679528702a766219a1fcf154
Review-Url: https://codereview.chromium.org/2630233003
Cr-Original-Commit-Position: refs/heads/master@{#42570}
Committed: https://chromium.googlesource.com/v8/v8/+/ee94fa11ed63477393c6534c352ebac6e502396c
Review-Url: https://codereview.chromium.org/2630233003
Cr-Commit-Position: refs/heads/master@{#42676}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/24cce87..6f17189

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/8e94621..a7cc7a3

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/68adbeb..017f4e5

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

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

- Adds Int16x8, Int8x16 types.
- Adds neg, abs unary ops.
- Adds add, sub, mul, and signed / unsigned min / max, comparison ops.

LOG=N
BUG=v8:4124

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

BUG=

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

BUG=chromium:683335
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

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

Changes output from
CALL RUNTIME (context function) code = 0x3e9ea90a2049 at -1
to
CALL RUNTIME async_function_promise_create code = 0x3e9ea90a2049 at -1

This makes the ast more useful. I didn't annotate all the runtime calls,
only some for now. We can annotate others if necessary.

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

This action was used by inspector for blackboxing and isn't needed with new blackboxing implementation inside V8.

BUG=none
R=yangguo@chromium.org,clemensh@chromium.org
TBR=bmeurer@chromium.org

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

List of items:
  1. Avoid zero-extending for subsequent 32-bit operations if current operation does not change upper 32-bit or does zero-extending.
  2. Match complex address mode for binary operation where possible (eg. use Add R,MEM).
  3. Detect instruction forms in selector. Eg. kAllowRRR, kAllowRM
  4. Optimize sequence for Int32MulWithOverflow, Int32Div, etc.
  5. Remove Not32/Not64 which is the same as XOR

R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com
BUG=

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

Current state and proposed changes for blackboxing: https://docs.google.com/document/d/1hnzaXPAN8_QC5ENxIgxgMNDbXLraM_OXT73rAyijTF8/edit?usp=sharing

BUG=v8:5842,chromium:583193
R=yangguo@chromium.org,dgozman@chromium.org,alph@chromium.org

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

Enable enqueueing of eager inner function compilation onto the compiler
dispatcher. This enables these tasks to be performed in parallel to
compilation of the outer functio (only for Ignition functions).
We currently synchronize to ensure all inner function compilations
 are complete before executing the outer function - future work will
allow outer function execution to happenin parallel to inner function
compilation.

BUG=v8:5203,v8:5215

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

BUG=chromium:682521

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

Cr-Commit-Position: refs/heads/master@{#42665}

Cr-Commit-Position: refs/heads/master@{#42664}

R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com
BUG=

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

Because it was confusing seeing U8(negative value).

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

BUG=

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

Adds CSA::Print(const char* s), which generates a runtime call to
Runtime::kGlobalPrint with a line-terminated ASCII string constant,
and CSA::DebugPrint(const char* prefix, Node* tagged_value), which
emits a runtime call to Runtime::kDebugPrint() with the tagged
value, optionally prefixed by an ascii string constant.

These simplify debugging TF builtins by providing a tool to easily
observe the contents of values at arbitrary points in a program,
without stepping endlessly through assembly in a debugger, and to
easily observe the path taken through a TF builtin.

These methods do not generate code in release builds.

BUG=v8:5268
R=ishell@chromium.org, danno@chromium.org, bmeurer@chromium.org

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

Also tidy some JS style in the file.

BUG=chromium:673246
NOTRY=true

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

R=titzer@chromium.org, clemensh@chromium.org

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

We did not smi-check the spread argument here, meaning we tried to take the map
of a smi, resulting in segfaults which clusterfuzz found.

Also added tests that exercise this path.

BUG=685086

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

[parser]: Skipping inner funcs / initial implemetation of storing scope analysis data from preparsed scopes.

The data produced at the moment only contains information about scope type +
positions, and only the most trivial tests pass.

Upcoming CLs will extend the data to contain information about variables (once
PreParser can produce it) and add more test cases.

BUG=v8:5516

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

R=rossberg@chromium.org
BUG=

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

After decoding an invalid function name (e.g. OOB), we stored the parsed
offset and length into the WasmFunction anyway, resulting in a runtime
CHECK failure later on.
This CL fixes this, and adds a regression test.

R=titzer@chromium.org
CC=mtrofin@chromium.org, bradnelson@chromium.org
BUG=chromium:684858

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/dbe38ca..24cce87

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/58fecbe..68adbeb

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

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

BUG=v8:5887

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

R=rossberg@chromium.org
BUG=

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

The default stack size of a background thread is 512KB on MacOSX. We default to
1MB stack checks when compiling JS code, so we need to increase this limit
to enable compilation of JS code onto background threads.

Corresponding Chromium CL is https://codereview.chromium.org/2640803002/

BUG=v8:5203

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

It's a common pattern to create a Variable and immediately initialize
it. This adds a new constructor to make that pattern more natural.

BUG=

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