Update docs and tests for recent changes in the spec for unicode escapes
in capture group names.

https://github.com/tc39/proposal-regexp-named-groups/issues/23

BUG=v8:5437

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

Change-Id: If074bb297201470d688ecd7b01e5e9ce9bab464e
Reviewed-on: https://chromium-review.googlesource.com/469730
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44473}

The WebIDL spec expects iterator objects from interfaces that declare pair
iterators to ultimately inherit from %IteratorPrototype%. Expose the
intrinsic object in the public API so we can use it in Blink's bindings
code.

BUG=chromium:689576
R=caitp@igalia.com,jkummerow@chromium.org,jochen@chromium.org

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

References to invalid names (i.e. not specified as a named group in the
pattern) throw a SyntaxError. Unmatched groups are still replaced by the
empty string.

See https://github.com/tc39/proposal-regexp-named-groups/issues/14.

BUG=v8:5437

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

This gives us more precise type information, so we can avoid some type
guards to refine the type information back.

The motivation for this is to help escape analysis by not introducing
redundant type guards (which escape analysis cannot handle yet even
though it could and should do).

Motivating example:

In the example below, the out-of-object property array for properties
fld5 and fld6 gets type Any when it is created by "o.fld5 = 5" (for
object literals, we store 4 properties in-objeca, the rest goes out
of object).

When we run load elimination for the load the out-of-object property
array (to store 6 into o.fld6), load elimination inserts TypeGuard to
enforce the Type::Internal() type. This makes escape analysis bail out
on this object, and we do not eliminate the object creation.

function f() {
  var o = {};
  o.fld1 = 1;
  o.fld2 = 2;
  o.fld3 = 3;
  o.fld4 = 4;
  o.fld5 = 5;
  o.fld6 = 6;
}

f();
f();
%OptimizeFunctionOnNextCall(f);
f();

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

Revert of [profiler] reduce incorrectly unaccounted ticks. (patchset #4 id:60001 of https://codereview.chromium.org/2799603005/ )

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/8247/steps/Check%20%28flakes%29/logs/CollectOptimizedTople..

Original issue's description:
> [profiler] reduce incorrectly unaccounted ticks.
>
> No longer invalidate the tick sample if there is no JS frame or only one
> non-interpreted JS frame on the stack.
>
> R=jarin@chromium.org
>
> Review-Url: https://codereview.chromium.org/2799603005
> Cr-Commit-Position: refs/heads/master@{#44465}
> Committed: https://chromium.googlesource.com/v8/v8/+/57bef9a1e2621555f70b9258593ae4a4235307ef

TBR=jarin@chromium.org,cbruni@chromium.org,yangguo@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

FinishCompilationUnits used the assumption that FinishCompilationUnit
only return null if there is no compilation unit left to be finished.
This assumption was wrong though, because also a compilation error can
cause the result to be null. Therefore I switched to use the function
index as a new indicator.

BUG=chromium:709174

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

See https://github.com/tc39/ecma262/pull/303.

BUG=v8:5937,v8:6201

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

This ensures that capture names containing surrogate pairs are parsed
correctly even in non-unicode RegExp patterns by introducing a new
scanning mode which unconditionally combines surrogate pairs.

BUG=v8:5437,v8:6192

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

No longer invalidate the tick sample if there is no JS frame or only one
non-interpreted JS frame on the stack.

R=jarin@chromium.org

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

Port of http://crrev.com/2805613002 in TurboFan to Crankshaft.

We have a weird performance cliff, where using an object literal for
allocation is way slower than using a constructor function, or starting
from the empty object literal and using transitioning stores. The reason
is that we limit the inlining of object literal nodes into Crankshaft
to max. 8 fast properties. So as soon as you get above 8, you'll get a
runtime function call to %CreateObjectLiteral, which is a lot slower
than the inlined allocation and initialization. Still not ideal, but
less unpredictable (hopefully).

TBR=jarin@chromium.org
BUG=v8:6211

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/2a0adf9..1314c9a

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/80a58af..e650872

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/5bc7c5e..70cd354

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

Change-Id: Ie57670e0de37c1a91b19973c57ff4ff61d8885e7
Reviewed-on: https://chromium-review.googlesource.com/471006Reviewed-by: v8 autoroll <v8-autoroll@chromium.org>
Commit-Queue: v8 autoroll <v8-autoroll@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44463}

TBR=jbudorick@chromium.org
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true

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

R=bmeurer@chromium.org

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

This patch fixes build error for 64bit platforms introduces in
https://codereview.chromium.org/2793323002
Error message from MIPS64 buildbot: error: implicit conversion loses
integer precision: 'long' to 'int' [-Werror,-Wshorten-64-to-32]

BUG=

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

Revert of [heap] Remove size specializations in static object visitors. (patchset #4 id:60001 of https://codereview.chromium.org/2763413007/ )

Reason for revert:
Speculative revert due to canary crashes.

BUG=chromium:708339,chromium:707790

Original issue's description:
> [heap] Remove size specializations in static object visitors.
>
> Apart from that this patch adds kVisitJSObjectFast for JSObjects that
> do not have any unboxed double fields and can be visited without
> run-time layout check.
>
> BUG=chromium:694255
>
> Review-Url: https://codereview.chromium.org/2763413007
> Cr-Commit-Position: refs/heads/master@{#44237}
> Committed: https://chromium.googlesource.com/v8/v8/+/dbb1cbe3a85d5c5528ce876d905e78d2ab35f00b

TBR=mlippautz@chromium.org,hpayer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:694255

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

This fixes behavior for HeapNumber {index} arguments passed to
AdvanceStringIndex.

Previously, we'd blindly treat {index} as a Smi. Passing a HeapNumber instead
would result in a Smi addition on the tagged HeapNumber pointer.

BUG=chromium:709015

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

The original CL: https://chromium-review.googlesource.com/c/469610/

R=clemensh@chromium.org

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

In predictable mode DoSync and DoAsync are only normal
function calls. Therefore I had to do some adjustments
to async compilation to make it work with --predictable:
* I moved all calls to DoSync and DoAsync out of
  DisallowHandleAllocation and DisallowHeapAllocation
  scopes.
* I turned off the use of the semaphore which
  synchronizes the background compilation tasks with
  the main thread. It caused a deadlock.
* Adjust when the AsyncCompileJob is deleted, namely
  after the start function and not after the execution
  of the last compilation task. The reason is that in
  predictable mode all previous tasks are still on the
  stack after the last compilation task.


Bug:

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

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

Bug:

Change-Id: Iddd693d12e55a7a423eb3236006f3c22b41d1f83
Reviewed-on: https://chromium-review.googlesource.com/469829Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44454}

The actual value was always &-ed with 0 so technically correct. ASAN
rightfully complains when allocating an external bitmap though.

BUG=chromium:651354
R=ulan@chromium.org

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

Why not?

Bug: v8:6215
Change-Id: I29f3731cbd0d03af6858eb475a1df8b8988cb89f
Reviewed-on: https://chromium-review.googlesource.com/469848Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44452}

This CL fixes two more cases in which a regexp could unintentionally transition
to slow mode while on the fast path, leading to possible OOB accesses of
lastIndex.

In both cases, the fix is to re-check the shape and possibly bail to runtime.

BUG=chromium:708247,v8:6210

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

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

Drive-by: Fix some getters.

BUG=chromium:651354

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

This reverts commit 9461fe24.

Reason for revert: Breaks a test in Node.js: 
 parallel/test-util-inspect

=== release test-util-inspect ===                                              
Path: parallel/test-util-inspect
#
# Fatal error in , line 0
# unreachable code
#

==== C stack trace ===============================


Original change's description:
> [builtins] don't inline calls for common Promise ops in async builtins
> 
> InternalResolvePromise, InternalPromiseReject and
> InternalPerformPromiseThen generate quite a lot of code.
> 
> This change adds 3 new TF stubs which inline calls to these builtins.
> These stubs are invoked rather than inlining those operations listed
> above directly. This is done for Async Iteration builtins, as well as
> Async Function builtins. Promise builtins are left as they were, and
> continue to inline these calls.
> 
> This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
> release build.
> 
> BUG=v8:5855
> R=​gsathya@chromium.org, jgruber@chromium.org
> 
> Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
> Reviewed-on: https://chromium-review.googlesource.com/461269
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44445}

TBR=mstarzinger@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,v8-reviews@googlegroups.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5855

Change-Id: Iabcdf8b025cc9b053a858f8e74389638ac000ba0
Reviewed-on: https://chromium-review.googlesource.com/469946Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44448}

Currently we initialize the allocated buffer to be full of 0s, which
adds significant overhead.

TypedArrayConstructByArrayLike will always either fully initialize the
buffer, or throw an exception, in which case the buffer will not be
leaked to user code.

The length of the new TypedArray (and thus the buffer) is derived from
the length of the source Array/TypedArray, so we know that we will
always set every byte of the new buffer, or throw trying.

Bug:v8:5977

Change-Id: I8ceaa883cfad85f8708a5bdaada3ce463d97e007
Reviewed-on: https://chromium-review.googlesource.com/469348Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44447}

To avoid running infinitely or hitting the stack size limit, bound the
number of steps to execute in the interpreter to 16k.

R=ahaas@chromium.org
BUG=chromium:708457

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

InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.

This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.

This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.

BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org

Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
Reviewed-on: https://chromium-review.googlesource.com/461269
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44445}

Doing so will increase the likelyhood of getting the interesting code objects
into the mindump.

Change-Id: I6c6d06bbfe7ab8649139b1146bda0f9b3d679064
Reviewed-on: https://chromium-review.googlesource.com/468967
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44444}

The Run() method ran in chunks of {kRunSteps} steps till completion or
breakpoint, while Step() executed exactly one step.
This CL removes the {kRunSteps} concept, and instead allows to pass the
number of steps to run to the Run() method. Step() just calls Run(1).

R=ahaas@chromium.org
BUG=chromium:708457,v8:5822

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

This is used by streams in
https://streams.spec.whatwg.org/commit-snapshots/1375e266b2fe8246bd95cb9d8a49876ba9359dc9/#rs-pipe-through

This also fixes an omission in a6e635d6
that did not properly update the
%OptimizeObjectForAddingMultipleProperties call in prologue.js.

BUG=chromium:668951
R=gsathya@chromium.org,littledan@chromium.org

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

It's not necessary at finalization, and may be obtained from
the shared, native object.

BUG=

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

Make Ignition collect BinaryOperationFeedback on ToNumber, using the
shared type feedback slot with the following Inc/Dec bytecode, and use
this feedback in TurboFan to turn the ToNumber(x) operation into a
SpeculativeNumberMultiply(x,1) with the feedback hint.

R=jarin@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:6214,v8:5267

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

Bug: v8/6024
Change-Id: Iff8a1b7a75e9f8f18ac24f31a5275e91aa16a272
Reviewed-on: https://chromium-review.googlesource.com/469347
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44439}

Change-Id: Ie84fbc26a3f3782564f3d0734c284f19a75853f3
Reviewed-on: https://chromium-review.googlesource.com/469826Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44438}

Remove the restriction that we cannot reuse code objects generated for
OSR from Ignition to TurboFan.

R=jarin@chromium.org, mstarzinger@chromium.org, rmcilroy@chromium.org
BUG=v8:4764

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

BUG=v8:5402
R=mstarzinger@chromium.org

Change-Id: I8ce43504fee83dcb6859418a526b2c7aea52e778
Reviewed-on: https://chromium-review.googlesource.com/468968
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44436}

R=ahaas@chromium.org
BUG=v8:6204

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