let/const declarations in "standard" C-style for-loops have
some complex desugaring to accommodate the case where loop
loop variables may be captured. This slows down the baseline
performance of for-loops with let variables.

This change attempts to avoid this desugaring if it's known that
the loop variable is not captured at any point. A side effect of
this change is that let/const loop variables, when not captured
within the loop body, are not necessarily shown in the debugger,
similar to other stack-allocated vars.

BUG=v8:4762, v8:5460
R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org

Change-Id: I8dbe545a12c086f675972bdba60c94998268311a
Reviewed-on: https://chromium-review.googlesource.com/472247
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44731}

This patch retires runtime.js:
  - Removes some dead code from runtime.js (ToPositiveInteger, ToIndex),
  - Moves Array.prototype initialization to prologue.js
  - Moves SpeciesConstructor to the only file that calls it (typedarray.js)
  - Renames the remainder to reflect its only inhabitants ({Max,Min}Simple)

Change-Id: If9048a30c4f6b86396bfd647bb637b4175880fc3
Reviewed-on: https://chromium-review.googlesource.com/478579Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44730}

When asked for a module that previously failed to compile or
instantiate, the embedder necessarily has to signal failure.  In this
case, we expect an exception to be scheduled, which we will rethrow.

BUG=v8:1569

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

- Reserves q15 (d30,d31) as a scratch register for NEON operations.
- Rewrites CodeGenerator::AssembleSwap to use it.

LOG=N
BUG=v8:6020

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

Move JSOrdinaryHasInstance lowering to JSNativeContextSpecialization,
which was previously mostly done in JSTypedLowering (for no reason).
Add new logic to the lowering to constant-fold OrdinaryHasInstance
checks when the map of the left-hand side and the "prototype" of the
right-hand side is known. This address the performance issue with the
(base) class constructors generated by Babel, i.e.:

  function _classCallCheck(instance, Constructor) {
    if (!(instance instanceof Constructor)) {
      throw new TypeError("Cannot call a class as a function");
    }
  }

  var C = function C() { _classCallCheck(this, C); };

for

  class C {}

Also ensure that a known constructor being used inside an instanceof
get's a proper initial map on-demand.

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

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

When adding or overwriting properties of an object, the generic
keyed store stub must check if that property's name might have
an associated protector (e.g. the ArraySpeciesProtector) and
take the slow path if so to ensure that the protector is updated
as needed.

BUG=v8:6269

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

This uses the common macro lists instead of duplicating the list of
available math functions and values in {AsmJs::IsStdlibValid}.

R=rossberg@chromium.org
BUG=v8:6127

Change-Id: Ic480d74bb0b5f0f425d1e601e5128fa6f466bea1
Reviewed-on: https://chromium-review.googlesource.com/481260Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44725}

1) Function recording conditions need to be consistent (this same condition is used above)

2) byte is not wide enough for storing the backing store size.

Bugs uncovered by the existing tests with the flag on.

BUG=v8:5516

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

BUG=v8:6093

Change-Id: I4572fcb4258c9a6ee6e5d5ed18e3567460c90211
Reviewed-on: https://chromium-review.googlesource.com/481300Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#44723}

This includes a fastpath in the ElementsAccessor for the source
array being a JSArray with FastSmi or FastDouble packed kinds. This
is probably a pretty common usage, where an array is passed in as
a way of initializing the TypedArray at creation (as there is not other
syntax to do this). e.g. new Float64Array([1.0, 1.0, 1.0]) for some
sort of vector application.

BUG= v8:5977

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

R=rossberg@chromium.org
BUG=v8:6127

Change-Id: I1ed8f22eecd3ee674c909ae511bbba4460bcdd17
Reviewed-on: https://chromium-review.googlesource.com/481759Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44721}

When accessing the "prototype" property of a known JSFunction in
TurboFan, we can automatically create the initial map if it hasn't been
instantiated so far. This happens with hand-grown inheritance mechanisms
where the base classes might not be instantiated regularly at all, but
the base class constructors are only called via F.p.call from the
subclass constructors.

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

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

In particular the Babel generated code for simple constructors is
of interest here, since that's what we hit in the wild most often
currently.

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

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

The StringIndexOf fast path used to be very narrow, only allowing
one-byte single-char search strings (and a one-byte subject string).

This changes the CSA fast path to call into our internal SearchString C++
function instead (after attempting to unpack both Strings), and can handle
strings of arbitrary length and encoding. The only remaining runtime call is
when either string needs to be flattened.

BUG=

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

R=yangguo@chromium.org

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

This new API sets a native data property on an object
directly, as Template::SetNativeDataProperty does.
It is similar to Object::SetAccessor, but properties
set by SetNativeDataProperty without kReadOnly flag
can be replaced.


Bug:chromium:617892

Change-Id: I32973f7190906d76be6802da9a0489edce0bd93e
Reviewed-on: https://chromium-review.googlesource.com/479474Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Hitoshi Yoshida <peria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44716}

This is to make testing parse tasks, which currently only work with
external strings, easier.

BUG=v8:6093

Change-Id: Ia248ea9e9547604b4c81179e54d8ef564377e2a9
Reviewed-on: https://chromium-review.googlesource.com/480559
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44715}

This fixes source position tracking within the "increment" expression of
a for-statement. The old {StashCode} method was inherently incompatible
with side tables like the source position table, as it would leave them
untouched while mutating the bytecode stream. It was hence trimmed down
to {DeleteCode}.

R=bradnelson@chromium.org
BUG=v8:6127

Change-Id: I7a5ff60cd5334208c44b165c8b54144d9ae83209
Reviewed-on: https://chromium-review.googlesource.com/480301
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44714}

This changes the message from

"method_name is not generic"

to

"method_name requires that 'this' be a primitive_name object"

BUG=v8:6206

Review-Url: https://codereview.chromium.org/2814043006
Cr-Original-Commit-Position: refs/heads/master@{#44683}
Committed: https://chromium.googlesource.com/v8/v8/+/21b104e3b83569b52539ecaa83e68a3646065101
Review-Url: https://codereview.chromium.org/2814043006
Cr-Commit-Position: refs/heads/master@{#44713}

The typing rule for JSCreateArguments must properly declare rest
parameters as arrays and only consider sloppy and strict arguments
objects as Type::OtherObject.

TBR=jarin@chromium.org
BUG=v8:6262,chromium:712802

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

Revert of Introduce mkgrokdump to update tools/v8heapconst.py. (patchset #21 id:390001 of https://codereview.chromium.org/2809653003/ )

Reason for revert:
Test driver runs into assert:
https://build.chromium.org/p/client.v8/builders/V8%20Win64/builds/17082

Original issue's description:
> Introduce mkgrokdump to update tools/v8heapconst.py.
>
> - Migrate make grokdump to GYP and GN
> - Move code from d8 into stand-alone execution
> - Add test case to ensure it's up-to-date
>
> Review-Url: https://codereview.chromium.org/2809653003
> Cr-Original-Commit-Position: refs/heads/master@{#44687}
> Committed: https://chromium.googlesource.com/v8/v8/+/0cc0c130fa56f129c90c2a74cb01bda85df5e42a
> Review-Url: https://codereview.chromium.org/2809653003
> Cr-Commit-Position: refs/heads/master@{#44710}
> Committed: https://chromium.googlesource.com/v8/v8/+/477f00557458d383bd9ebef281890ba485ee882a

TBR=mstarzinger@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/2826743003
Cr-Commit-Position: refs/heads/master@{#44711}

- Migrate make grokdump to GYP and GN
- Move code from d8 into stand-alone execution
- Add test case to ensure it's up-to-date

Review-Url: https://codereview.chromium.org/2809653003
Cr-Original-Commit-Position: refs/heads/master@{#44687}
Committed: https://chromium.googlesource.com/v8/v8/+/0cc0c130fa56f129c90c2a74cb01bda85df5e42a
Review-Url: https://codereview.chromium.org/2809653003
Cr-Commit-Position: refs/heads/master@{#44710}

Functions that take mandatory parameters plus a number of optional
parameters, that need to be materialized as an Array are quite common.
The simplest possible case of this is essentially:

  function foo(mandatory, ...args) { return args; }

Babel translates this to something like:

  function foo(mandatory) {
    "use strict";
    for (var _len = arguments.length,
             args = Array(_len > 1 ? _len - 1 : 0),
             _key = 1; _key < _len; _key++) {
      args[_key - 1] = arguments[_key];
    }
    return args;
  }

The key to great performance here is to make sure that we don't
materialize the (unmapped) arguments object in this case, plus that we
have some kind of fast-path for the Array constructor and the
initialization loop.

This microbenchmark ensures that we have decent performance even in the
case where the assignment to args is polymorphic, i.e. the arguments
have seen different elements kinds, starting with FAST_HOLEY_ELEMENTS
and then FAST_HOLEY_SMI_ELEMENTS.

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

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

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1501368..bca1cbe

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/49eb11f..cabc131

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/88db8e4..a38e11d

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

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

Bug: v8:5717
Change-Id: I88e1e3089844b0955f0f7a6a792c2e10949a5b18
Reviewed-on: https://chromium-review.googlesource.com/480927Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44707}

 - I8x16Splat, I8x16ExtractLane, I8x16ReplaceLane
 - Binops: I8x16Add, I8x16AddSaturateS, I8x16Sub, I8x16SubSaturateS, I8x16MinS,
 I8x16MaxS, I8x16AddSaturateU, I8x16SubSaturateU, I8x16MinU, I8x16MaxU
 - Compare ops: I8x16Eq, I8x16Ne

BUG=v8:6020

R=bbudge@chromium.org, bmeurer@chromium.org

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

Bug: v8:5717
Change-Id: I999ea81f745a25a1f3a539e50594e597e64f5287
Reviewed-on: https://chromium-review.googlesource.com/481044Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44705}

It succeeds on my machine, at least, so marking pass/fail to avoid
unnecessary noise until the attached bug is resolved.

TBR=machenbach@chromium.org

Bug: v8:6252
Change-Id: I146eee0c464896e42058745096e929d221c04347
Reviewed-on: https://chromium-review.googlesource.com/480988Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44704}

When --harmony-strict-legacy-accessor-builtins is enabled, it brings
V8's behavior in line with the spec and more recent versions of
SpiderMonkey and JSC:
  - No implicit receiver coercion
  - Attempting to redefine a non-configurable property throws

Bug: v8:5070
Change-Id: I82b927538604136c0c550e19bcc606fbfea1377e
Reviewed-on: https://chromium-review.googlesource.com/478312Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44703}

What will we get:
- console would be included into snapshot and allow us to reduce time that we spent in contextCreated function (~5 times faster),
- it allows us to make further small improvement of console methods, e.g. we can implement super quick return from console.assert if first argument is true,
- console calls are ~ 15% faster.

CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng

BUG=v8:6175
R=dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#44353}
Committed: https://chromium.googlesource.com/v8/v8/+/55905f85d63d75aaa9313e51eb7bede754a8e41c
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Original-Commit-Position: refs/heads/master@{#44355}
Committed: https://chromium.googlesource.com/v8/v8/+/cc74ea0bc4fe4a71fa53d08b62cc18d15e01fbb3
Review-Url: https://codereview.chromium.org/2785293002
Cr-Original-Commit-Position: refs/heads/master@{#44416}
Committed: https://chromium.googlesource.com/v8/v8/+/f5dc738cda0336929dcb8eb73b87fdcd01b7c685
Review-Url: https://codereview.chromium.org/2785293002
Cr-Commit-Position: refs/heads/master@{#44702}

Revert of [errors] Improve NotGeneric error message (patchset #3 id:40001 of https://codereview.chromium.org/2814043006/ )

Reason for revert:
Please schedule rebasing layout test first:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/15036

https://github.com/v8/v8/wiki/Blink-layout-tests

Original issue's description:
> [errors] Improve NotGeneric error message
>
> This changes the message from
>
> "method_name is not generic"
>
> to
>
> "method_name requires that 'this' be a primitive_name object"
>
> BUG=v8:6206
>
> Review-Url: https://codereview.chromium.org/2814043006
> Cr-Commit-Position: refs/heads/master@{#44683}
> Committed: https://chromium.googlesource.com/v8/v8/+/21b104e3b83569b52539ecaa83e68a3646065101

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

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

+ additional fixes uncovered by bug, and addressed remaining feedback
from original CL (https://codereview.chromium.org/2806073002/).

Note that the regression test differs slightly from the bug reported one,
in that it catches the RangeError which will eventually be thrown due
to call stack size being exceeded.

BUG=chromium:712569

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

This switches the parser to use token positions (i.e. {Position})
instead of stream positions (i.e. {GetPosition}) everywhere. Access to
the latter is being removed as it is unsupported when the scanner is in
rewind state anyways. This prevents "skipping" a token when seeking.

R=bradnelson@chromium.org
BUG=v8:6127

Change-Id: I9c13dd20a981061a2bccc4fb57e5c57d2a64ac5c
Reviewed-on: https://chromium-review.googlesource.com/480300Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44699}

IncrementalMarking has nine bytes of padding in 32-bit and 64-bit
builds. Fixing 32-bit builds just requires moving the one-byte
incremental_marking_job_ member. Fixing 64-bit requires moving the
four-byte state_ member. This change reduces the padding to one byte.

On 64-bit this reduces its size from 152 to 144. This also fits heap
granularity better. On 32-bit it goes from 96 to 88 bytes.

The initial padding was found with llvm-pdbdump.exe. The fix was
verified by compiling v8/src/assembler.cc with the undocumented
/d1reportSingleClassLayout option, like this:

    /d1reportSingleClassLayoutIncrementalMarking

The savings should apply on all platforms, or at worst should make no
difference except for improving alignment.

Thanks to zturner@ for some llvm-pdbdump improvements.

BUG=chromium:710933

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

BUG=v8:5807

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

Bug: v8:5717
Change-Id: I92c6d897ae7701e6c778590709f6f1c8a16295b0
Reviewed-on: https://chromium-review.googlesource.com/478591Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44696}

BUG: v8/6251
Change-Id: I64e6ad220f05384e4cd549c1356fd713423c3044
Reviewed-on: https://chromium-review.googlesource.com/480072Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44695}

- separated V8StackTraceImpl and AsyncStackTrace,
- V8Debugger owns all AsyncStackTrace and cleanup half of them when limit is reached (first created - first cleaned),
- V8StackTraceImpl, AsyncStackTrace and async-task-related tables in V8Debugger have weak reference to other async stack traces.
- async tasks are cleared with related async stacks.

BUG=v8:6189
R=dgozman@chromium.org

Review-Url: https://codereview.chromium.org/2816043006
Cr-Original-Commit-Position: refs/heads/master@{#44670}
Committed: https://chromium.googlesource.com/v8/v8/+/1bca73bc832c645138bd3e0306fcaa8bb44dad04
Review-Url: https://codereview.chromium.org/2816043006
Cr-Commit-Position: refs/heads/master@{#44694}

The feature is not quite ready for getting ClusterFuzzed.

BUG=v8:5516

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

This fixes the de-duplication logic used when writing the deoptimizer
translation of a frame-state containing {kArgumentsElementsState}. The
object counts as a captured object and participates in the numbering of
duplicated objects.

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

Change-Id: I4a3b892017ab8217197e5f94c1a0975d0cd6979f
Reviewed-on: https://chromium-review.googlesource.com/476631
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44692}