Do not allow that holey properties are defined in Array sort.
Throw a type error if the array is not extensible and there are holey
properties in the middle of the array.

BUG=v8:4888

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

R=neis@chromium.org

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

This patch removes the implication from --harmony to --harmony-tailcalls.

R=ishell@chromium.org
BUG=v8:4698

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/9d467bb..0d29448

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/df42e55..a6b2121

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

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

BUG=none
R=pfeldman@chromium.org

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

If a job was already enqueued, EnqueueAndStep would still step the job one
more step. However, since it didn't take the job out of the
pending_background_jobs pool, the job could get picked up by a background
thread which would try to step it, but it the job is now at a step which
can't be run on the background.

BUG=v8:5203,chromium:685515

Change-Id: I2cee2a33625ba455aca49a8037601be9ff8bb73f
Reviewed-on: https://chromium-review.googlesource.com/441084
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43121}

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}

We have different modes of tracing: recording, event callback and
filtering. The cpu profiler should not be enabled when tracing is
enabled with filtering mode.

BUG=688651

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

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}

Since preparser creates different scopes than the parser, the invariant "at most one rest parameter" doesn't hold when the rest param is a destructuring param.

No new tests added; the problem is visible w/ existing tests with FLAG_lazy_inner_functions on.

R=​vogelheim@chromium.org
BUG=chromium:690919

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

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}

The --ignition-filter hasn't worked properly for a while due to some functions
only being supported by Ignition. Remove it and add a --print-bytecode-filter
to allow the main use-case of limiting bytecode printing to a particular
function.

BUG=chromium:685476,v8:5203

Change-Id: Id41eeb3083ae9f713433d3a30227cd4c5d0d47dd
Reviewed-on: https://chromium-review.googlesource.com/441047Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43113}

Avoid reinserting the ast constant string values into the string_table_ of
each AstValueFactory that is created, instead clone an initial copy created
in AstStringConstants.

BUG=686658

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

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}

Port 79570f87

Original Commit Message:

    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=ahaas@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

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

Port b8c7870c

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

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

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}

Change-Id: I91bedd8d30e32f270fb528d0d8bbfed45074878f
Reviewed-on: https://chromium-review.googlesource.com/440065Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43103}

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}

This works around a compiler bug that leads to incorrect masking of
the semantic_ field in TruncatingUseInfoFromRepresentation.

Patch from bulach@google.com

BUG=

Review-Url: https://codereview.chromium.org/2669113003
Cr-Original-Commit-Position: refs/heads/master@{#42925}
Committed: https://chromium.googlesource.com/v8/v8/+/8c7fc377fd5c03e30cbf767cd22aba59178e0143
Review-Url: https://codereview.chromium.org/2669113003
Cr-Commit-Position: refs/heads/master@{#43099}

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}

R=gsathya@chromium.org
TBR=adamk@chromium.org
BUG=

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

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}

BUG=

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

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}

This was broken by https://codereview.chromium.org/2663803002.

BUG=

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

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}