BUG=v8:5828

Change-Id: I1a75c06ba80a39b28b74870c3e3be4d5e2ec3712
Reviewed-on: https://chromium-review.googlesource.com/480299Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44684}

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}

Moved recording data about functions to PreParser, since it knows the
num_inner_funcs. Recording used to be done in AnalyzePartially and then it was
too late, since at that point we only have the Scope and have lost all other
info about the function.

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

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

Use Type::Array to constant-fold Array.isArray builtin based on the
value input type. Also use it to improve type based alias analysis,
where we know that stores to an object of type Array don't affect stores
to an object of type OtherObject, and vice versa.

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

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

The CheckBounds operator identifies zeros, but we ignore these bits in
the representation selector, which generates unnecessary -0 checks for
array accesses.

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

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

No usage sites are getting the length for uncompiled functions, so we can
postpone setting the correct length until after compilation. This way we don't
need to produce and store it for skipped inner functions.

In the current implementation, getting the function length compiles it (and
users rely on it - so the feature is probably not going to go away).

BUG=v8:5516

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

Revert of [inspector] avoid cloning of async call chains (patchset #7 id:120001 of https://codereview.chromium.org/2816043006/ )

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

Might require changing a browser test first?

Original issue's description:
> [inspector] avoid cloning of async call chains
>
> - 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-Commit-Position: refs/heads/master@{#44670}
> Committed: https://chromium.googlesource.com/v8/v8/+/1bca73bc832c645138bd3e0306fcaa8bb44dad04

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

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

BUG=v8:4743
TBR=jgruber@chromium.org

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

Fix  751e8935 commit
Fix typo in implementation
BUG=

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

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

Rolling v8/buildtools: https://chromium.googlesource.com/chromium/buildtools/+log/d307444..88811f4

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

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

Rolling v8/tools/gyp: https://chromium.googlesource.com/external/gyp/+log/e7079f0..eb296f6

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

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

BUG=none
R=yangguo@chromium.org

Change-Id: I683c10eae10f60fb7239f3714df0a12a9d19a43b
Reviewed-on: https://chromium-review.googlesource.com/480071Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44674}

Bug: v8:5193
TBR=yangguo@chromium.org
NOTRY=true

Change-Id: I2f6b8e9e9468195fca4e74b83c642a8595c4a51b
Reviewed-on: https://chromium-review.googlesource.com/480091Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44673}

This rolls:
https://chromium.googlesource.com/chromium/deps/icu/+log/450be73..b34251f

Bug: v8:6252
Change-Id: I496f35bad1717105c8e450ce045f3e9929574e0f
Reviewed-on: https://chromium-review.googlesource.com/475652Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44672}

Currently when the module has memory specified in the compiled bytes, but with no initial memory
exported memory assigns a bogus buffer to the instance. When grow_memory is called on this buffer, it tries to patch an incorrect address.
 - Fix exported memory to handle no initial memory
 - Fix grow_memory to handle uninitialized buffers

BUG=chromium:710844
R=bradnelson@chromium.org

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

- 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-Commit-Position: refs/heads/master@{#44670}

Today, the semantics of:

WebAssembly.instantiate

and

WebAssembly.compile().then(new WebAssemblyInstance)

are subtly different, to the point where attempting the proposed
change uncovered bugs.

In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.

This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.

- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.

BUG=chromium:697028

Review-Url: https://codereview.chromium.org/2806073002
Cr-Original-Commit-Position: refs/heads/master@{#44592}
Committed: https://chromium.googlesource.com/v8/v8/+/7829af3275ff4644a2d0a1270abe1a1e4415e9fb
Review-Url: https://codereview.chromium.org/2806073002
Cr-Commit-Position: refs/heads/master@{#44669}

Bug=chromium:707066
R=littledan@chromium.org, adamk@chromium.org, caitp@igalia.com
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel

Change-Id: I24ce0a08816940ef4646d0f2de188d4832c823a0
Reviewed-on: https://chromium-review.googlesource.com/474990Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Josh Wolfe <jwolfe@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44668}

This flag was shipped with V8 5.7 (Chrome 57).

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

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

Inspector doesn't use debugger context and this entering only slow down our async instrumentation.

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

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

 - Add I16x8 Splat, ExtractLane, ReplaceLane, shift ops, Some BinOps and compare ops
 - Add pshufhw, pshuflw in the assembler, disassembler
 - Fix incorrect modrm for pextrw, this bug disregards the register allocated and always makes pextrw use rax.
 - Fix pextrw disasm to take the 0 - 7 bits of the immediate instead of 0 - 3.
 - Pextrw, pinsrw are in the assembler use 128 bit encodings, pextrw, pinsrw in the disassembler use legacy encodings, fix inconsistencies causing weird code gen when --print-code is used.

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

BUG=None
TEST=None
R=mtrofin@chromium.org
LOG=N

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

R=bradnelson@chromium.org, mtrofin@chromium.org

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

NOTRY=true
TBR=hablich@chromium.org

Change-Id: I36418c2d0198c52a52ba3426a2792b2f52c29d67
Reviewed-on: https://chromium-review.googlesource.com/479411Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44661}

This reverts commit 8faf3d6f.

Reason: blocks roll https://codereview.chromium.org/2820753003/

TBR=martyn.capewell@arm.com,jarin@chromium.org,bmeurer@chromium.org,machenbach@chromium.org

NOTRY=true

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

Also simplify usage of Object.prototype methods in JS natives: now
that they're added in bootstrapper, no need to import them.

Change-Id: I0db53dd5acaed3aa0a5b46f730b31baa376e282d
Reviewed-on: https://chromium-review.googlesource.com/478574
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44659}

Change-Id: I9973858f2596a9bc4d66afbb26612189fbded7f3
Reviewed-on: https://chromium-review.googlesource.com/478413Reviewed-by: Caitlin Potter <caitp@igalia.com>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44658}

- creating JSArray and further setter and getter calls are slower then on fixed array.

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

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

If the current context is overwritten by doing Realm.navigate(0) we
fail to delete the module embedder data from the correct current
context, because we have an handle to the old context which was
already cleaned up by calling DisposeRealm in RealmNavigate.

This patch disallows navigation to the first realm.

Bug: chromium:711165
Change-Id: I6b9d3187367dae9d1fe38c0efa361d461c94c917
Reviewed-on: https://chromium-review.googlesource.com/476970Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44656}

Enabling on trunk after having landed change to add flag and disable for
branch.

BUG=None
R=mtrofin@chromium.org,ahaas@chromium.org
LOG=N

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

TBR=martyn.capewell@arm.com
NOTRY=true

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

Adding a flag to explicitly enable/disable async compile.
Will cherrypick this to M59.
Separately will land a change to re-enable this by default.

BUG=v8:6264
R=mtrofin@chromium.org,ahaas@chromium.org,hablich@chromium.org

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

This reverts commit cc047635.
The CL was reverted due to a missing DEPS mirror.

Original issue's description:
> ARM64: Add NEON support
>
> Add assembler, disassembler and simulator support for NEON in the ARM64 backend.
>
> BUG=
>
> Review-Url: https://codereview.chromium.org/2622643005
> Cr-Commit-Position: refs/heads/master@{#44306}

BUG=

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

TBR=ishell@chromium.org
NOTRY=true

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

Taking the slow runtime path for every non-internalized string key
can be avoided by doing optimistic string table lookups: if there
is a matching entry, use that; if there isn't, then no existing
object has a property with that name.
The hashing/internalizing logic is in C++ and called directly.

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

https://github.com/tc39/proposal-async-iteration/commit/e3246ad69cc6f83b34bdd3451c3c6abce37fd1f3
removed some redundancies in yield and yield*.

In particular:
- AsyncGeneratorRawYield becomes unnecessary, and is deleted in this CL
- Parser::RewriteYieldStar() is updated to perform the IteratorValue() algorithm as appropriate

BUG=v8:6187, v8:5855
R=rmcilroy@chromium.org, adamk@chromium.org, littledan@chromium.org, vogelheim@chromium.org

Change-Id: I05e8429b9cbd4531c330ee53a05656b90162064c
Reviewed-on: https://chromium-review.googlesource.com/471806Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44649}

R=tebbi@chromium.org

Change-Id: I28cdf18616e16a681e2cab3f36263f3c09953b8b
Reviewed-on: https://chromium-review.googlesource.com/476612
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44648}

Currently we count optimizations to decide to disable optimization, and
count deopts to detect this decision and allow re-enabling optimizations
after a while.

However, throwing out TurboFan OSR code and GC optimized code evictions
do not count as deopts, which means that the optimization count
increases without increasing the deopt count. This increased optimization
count disables further optimization -- which is bad, because these are
not "true" deopts -- and can stop the optimization from being re-enabled,
because the deopt count can't go high enough.

Instead, we now only ever look at deopts to disable/re-enable
optimization, and opt counts are only used for naming log files and in
tests.

Change-Id: I0c7d6be497545449a38cf952cd2f007ee51982ba
Reviewed-on: https://chromium-review.googlesource.com/468811
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44647}

This option doesn't work for ARM any more.

BUG=

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

If the new.target passed to the Array constructor cannot be a Proxy,
then we know that the Array constructor cannot trigger any observable
side-effects.

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

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