The heuristic checks for "(function", and now it also checks for
"(async function".

BUG=v8:4230

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

This roll includes the SharedArrayBuffer tests (skipping for now)
but doesn't include the $ renaming.

This is a reland; previously, I reverted because I was confused about why
the rename of $ to $262 didn't break tests; it now seems that the
previous patch left it as an alias. This patch does not do the renaming
yet, as the renaming usage has not landed upstream yet.

R=adamk

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

Don't block on inner function compilation before competing outer function
compilation. Instead wait for the compilation to complete when the function
is called.

BUG=v8:5203

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

Removes handles from bytecode generation, instead storing
un-internalized AstValues (and other, similar values such as Scopes and
AstRawStrings) in the constant array builder.

This will allow us in the future to generate the bytecode before
internalizing the AST.

BUG=v8:5832

Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da
Reviewed-on: https://chromium-review.googlesource.com/439326
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43115}

R=jgruber@chromium.org, kozyatinskiy@chromium.org
BUG=v8:5821

Review-Url: https://codereview.chromium.org/2685483002
Cr-Original-Commit-Position: refs/heads/master@{#43049}
Committed: https://chromium.googlesource.com/v8/v8/+/1a989bdeefdc679745215ae547007773edb3d29e
Review-Url: https://codereview.chromium.org/2685483002
Cr-Commit-Position: refs/heads/master@{#43114}

When running main-thread compiler-dispatcher jobs, ensure that we enter the
correct Context. Also adds a test for compiling an extension in the compiler
dispatcher to ensure that idle tasks enter the correct context before
finalizing the compilation.

BUG=v8:5203

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

This introduces new maps to track whether we have created at most one
closure. If we have created just one closure, Turbofan will
specialize the code to its context.

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

In order to compile eager inner functions on a background thread we need to
keep the handles created during parsing and scope analysis alive until the
background compilation is complete. In order to do that, we allocate the
handles in a deferred handle scope and keep the deferred handles alive with
a shared_ptr in the ParseInfo and CompileInfo respectively.

BUG=v8:5203

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

This CL covers simple ("simple") rest param cases.

BUG=v8:5516
R=vogelheim@chromium.org

Change-Id: I254c2eb81d759eb2ea2a3d5e7c46bcdc2ccef707
Reviewed-on: https://chromium-review.googlesource.com/440984Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43106}

Revert of [arm64] A shift of 0 is not allowed in ubfx. (patchset #2 id:20001 of https://codereview.chromium.org/2685943003/ )

Reason for revert:
Reverting due to causing Word64AndWithImmediateWithWord64Sh to fail locally (but not on the bot).

BUG=v8:5956

Original issue's description:
> [arm64] A shift of 0 is not allowed in ubfx.
>
> R=bmeurer@chromium.org, v8-arm-ports@googlegroups.com
> BUG=v8:5951
>
> Review-Url: https://codereview.chromium.org/2685943003
> Cr-Commit-Position: refs/heads/master@{#43090}
> Committed: https://chromium.googlesource.com/v8/v8/+/c46ccef921ee754d60283d132b9d19f64ae7b1ff

TBR=bmeurer@chromium.org,v8-arm-ports@googlegroups.com,martyn.capewell@arm.com,ahaas@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5951

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

Alternative approach to https://codereview.chromium.org/2667983004/, which
does not depend on implicit control flow changes from
https://codereview.chromium.org/2664083002

- Remove handling for `async function` from Parser::RewriteReturn(). This functionality
is moved to BytecodeGenerator::BuildAsyncReturn(). This ensures that promise resolution
is deferred until all finally blocks are evaluated fully.

- Add a new deferred command (CMD_ASYNC_RETURN), which instructs ControlScope to
generate return code using BuildAsyncReturn rather than BuildReturn.

- Parser has a new `NewReturnStatement()` helper which determines what type of return
statement to generate based on the type of function.

BUG=v8:5896, v8:4483
R=littledan@chromium.org, neis@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, gsathya@chromium.org

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

BUG=v8:5945

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

This fixes the case where the index passed to {HMaybeGrowElements} used
to derive the new capacity for the elements backing store does not fit
into Smi range. Such an overflow would fail the capacity check and cause
growing to be skipped. Subsequent keyed stores would potentially go out
of bounds.

R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-686427
BUG=chromium:686427

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

Also make them use the helpers that I introduced recently.

BUG=v8:5636

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

Move the logic into Scope::DeclareVariable to be more robust.

BUG=v8:5636

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

This test is flaky when run with --optimize-for-size.

BUG=v8:5950

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

The use of setjmp/longjmp makes the cctests in test-run-wasm and
test-run-wasm-64 flaky on Windows, and I think that it is better not
to use it. With this CL I replace it as follows:

Similar to the setjmp/longjmp implementation we still call a C
function when a trap happens. However, instead of calling longjmp in
this C function we just set a flag which indicates that a trap
happened and then return. After we return from the C function we leave
the frame of the current wasm function and return with a RET
instruction. At the end of a test the wasm test runner checks the flag
to see if a trap happened.

Please take a special look at the LeaveFrame function on arm64.

R=titzer@chromium.org, clemensh@chromium.org, v8-arm-ports@googlegroups.com
CC=jarin@chromium.org

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

Revert of [Compiler] Enable handles created during parsing and scope analysis to be deferred. (patchset #9 id:180001 of https://codereview.chromium.org/2650883002/ )

Reason for revert:
Issue on arm64:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim/builds/5752

Original issue's description:
> [Compiler] Enable handles created during parsing and scope analysis to be deferred.
>
> In order to compile eager inner functions on a background thread we need to
> keep the handles created during parsing and scope analysis alive until the
> background compilation is complete. In order to do that, we allocate the
> handles in a deferred handle scope and keep the deferred handles alive with
> a shared_ptr in the ParseInfo and CompileInfo respectively.
>
> BUG=v8:5203
>
> Review-Url: https://codereview.chromium.org/2650883002
> Cr-Commit-Position: refs/heads/master@{#43091}
> Committed: https://chromium.googlesource.com/v8/v8/+/9346cd9b4c50466aa8d50e98c56b84ba47c2a115

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

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

NOTRY=true
R=hablich@chromium.org

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

In order to compile eager inner functions on a background thread we need to
keep the handles created during parsing and scope analysis alive until the
background compilation is complete. In order to do that, we allocate the
handles in a deferred handle scope and keep the deferred handles alive with
a shared_ptr in the ParseInfo and CompileInfo respectively.

BUG=v8:5203

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

R=bmeurer@chromium.org, v8-arm-ports@googlegroups.com
BUG=v8:5951

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

In order to allow parallel compilation of eager inner functions, we need to
seperate the zone used for parsing (which will be shared between all the
parallel compile jobs) and the zone used for compilation. This CL changes
CompilationInfo to require a zone (which can be different from the zone in
ParseInfo). We then seal the ParseInfo zone after parsing and analysis is done
to prevent any further allocation in that zone, so that it can be shared
(read-only) with the parallel compile jobs.

BUG=v8:5203

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

Add a simple benchmark for a TypedArray constructor. Run once with the
default pipeline and once with turbofan so that we can compare the
performance.

Also fixes a typo in the Regex for the result of the CopyWithin
benchmark which stopped the results showing up in the perf
dashboard.

BUG=

Change-Id: Ic2eb0bd1e02b458c1163e97130abd0e7531c2e1c
Reviewed-on: https://chromium-review.googlesource.com/440225Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43087}

This CL covers only the very simple cases.

BUG=v8:5516
R=vogelheim@chromium.org

Change-Id: Ib6ddc90cbcf1c923a7b72493cfd029cfa835462b
Reviewed-on: https://chromium-review.googlesource.com/440246Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43086}

Collecting precise invocation counts need to be explicitly
enabled. Once enabled, we disable optimization (optimized
code does not increment invocation count, and may inline
callees), and make sure feedback vectors interesting for
code coverage is not garbage-collected.

R=hpayer@chromium.org, jgruber@chromium.org
BUG=v8:5808

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

This CL includes runtime and IC parts of the tracking. It is controlled by
compile-time flag FLAG_constant_field_tracking and currently disabled.

Transition from kConst to kMutable still involves map deprecation.

BUG=v8:5495

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

http://www.ecma-international.org/ecma-262/7.0/#sec-validateandapplypropertydescriptor
says that [[DefineProperty]] should return false if the property is
already defined and it's unconfigurable (exactly speaking, the condition
in the spec is more complicated, but roughly speaking, it's when the
property is unconfigurable).

BUG=chromium:670651

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

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

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

Collect code coverage from the available invocation counts.
The granularity is at function level, and invocation counts may
be lost to GC.

Coverage::Collect returns a std::vector of Coverage::ScriptData.
Each ScriptData contains a script ID and a std::vector of
Coverage::RangeEntry.
Each RangeEntry consists of a end position and the invocation
count. The start position is implicit from the end position of
the previous RangeEntry, or 0 if it's the first RangeEntry.

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

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

R=ishell@chromium.org
TEST=mjsunit/regress/regress-5902
BUG=chromium:688837

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

Updated according to the recent spec change at
https://github.com/tc39/ecma262/pull/798.

BUG=v8:5949

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

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

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

Revert of [debugger] expose side-effect free evaluate to inspector. (patchset #3 id:40001 of https://codereview.chromium.org/2685483002/ )

Reason for revert:
Speculative revert. Seems to block the roll:
https://codereview.chromium.org/2685933005/

Original issue's description:
> [debugger] expose side-effect free evaluate to inspector.
>
> R=jgruber@chromium.org, kozyatinskiy@chromium.org
> BUG=v8:5821
>
> Review-Url: https://codereview.chromium.org/2685483002
> Cr-Commit-Position: refs/heads/master@{#43049}
> Committed: https://chromium.googlesource.com/v8/v8/+/1a989bdeefdc679745215ae547007773edb3d29e

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

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

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

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

BUG=v8:5943

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

arguments.h is one of the headers including objects-inl.h. Files needing
objects-inl.h used to innocently pull in debug.h, so that needs to be fixed now
too.

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

Change-Id: I8ce671c533ed757103ef9a3b0bf0a0509230fdd8
Reviewed-on: https://chromium-review.googlesource.com/439287Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43054}

Since the empty string is canonical HeapObject now, we can use
this fact to optimize

  - strict equality comparisons with the empty string to a
    simple ReferenceEqual operation, and
  - optimize ToBoolean to avoid instance type checks completely.

Drive-by-fix: Allow InternalizedString for Type::HeapConstant
in the type system. This is safe, since InternalizedStrings
can be compared to other heap constants by reference (except
for non-InternalizedStrings, which are excluded from the
HeapConstant type).

BUG=v8:5267
R=yangguo@chromium.org

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

R=jgruber@chromium.org, kozyatinskiy@chromium.org
BUG=v8:5821

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

R=rossberg@chromium.org,bradnelson@chromium.org
BUG=chromium:575167, chromium:690281

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

E.g.,
{ function lazy_inner(b = somevar) { let somevar; } }

If we don't produce the same scopes, PreParser thinks that the unresolved
variable inside the default parameter resolves into the variable declared inside
the function. Thus, it's not correctly recorded as a free variable.

One part is already done by https://codereview.chromium.org/2638333002 . But at
the laziness boundary, we still produced different scopes.

Unlike previously thought, this is also needed for lazy inner function
correctness, not only for "preparser scope analysis" (ie., skipping inner
functions).

BUG=v8:5938

Change-Id: I047cd43ef16478bb0f18d1f114845e7d1ab8c5f2
Reviewed-on: https://chromium-review.googlesource.com/439345
Commit-Queue: Marja Hölttä <marja@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43044}