Revert of Remove RegExp.multiline accessors. (patchset #3 id:40001 of https://codereview.chromium.org/1410993008/ )

Reason for revert:
[Sheriff] Causes layout test failures.

Original issue's description:
> Remove RegExp.multiline accessors.
>
> This is non-standard and not even documented on MDN.
>
> On Firefox, setting RegExp.multiline to true adds the multiline flag to all
> newly created RegExp objects (both from constructor and from literal).
>
> In V8 this has no effect.
>
> Source archaelogy shows that this is from the initial commit.
>
> R=bmeurer@chromium.org
>
> Committed: https://crrev.com/e8f752ce0c2a488e88cd87fe75f3907b4303d0a0
> Cr-Commit-Position: refs/heads/master@{#31673}

TBR=bmeurer@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review URL: https://codereview.chromium.org/1431433004

Cr-Commit-Position: refs/heads/master@{#31679}

This is in preparation of implementing Reflect.set.

Besides making SetSuperProperty and others return Maybe<bool>, this CL
also fixes some parts of my previous refactoring of SetProperty and
others: It doesn't make sense to take both a language_mode and a
should_throw argument.  A strict language_mode should imply
THROW_ON_ERROR.

R=rossberg, verwaest@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1431443003

Cr-Commit-Position: refs/heads/master@{#31678}

BUG=chromium:549162
LOG=n
R=verwaest@chromium.org

Review URL: https://codereview.chromium.org/1424293002

Cr-Commit-Position: refs/heads/master@{#31677}

This adds optimized lowering for JSConvertReceiver (in the general case)
and JSToObject in typed lowering. It also uses JSConvertReceiver for
direct calls in typed lowering.

R=mstarzinger@chromium.org
BUG=v8:4493
LOG=n

Review URL: https://codereview.chromium.org/1431543002

Cr-Commit-Position: refs/heads/master@{#31676}

Adds new Guard[Type] common operator, which takes value and control
inputs and records a guaranty that a certain value has a certain type
in that control path.  This is some kind of ad-hoc SSI similar to what
we have to do in Crankshaft in some places.

Also introduces an ObjectIsNumber simplified operator, which checks
whether a certain value is a number (either a Smi or a HeapNumber).

This doesn't yet support transitioning stores to double fields, which
require support for allocating mutable heap numbers.

R=jarin@chromium.org
BUG=v8:4470
LOG=n

Review URL: https://codereview.chromium.org/1420283009

Cr-Commit-Position: refs/heads/master@{#31675}

Proxies are not properly supported yet.

R=rossberg, jkummerow@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1408163005

Cr-Commit-Position: refs/heads/master@{#31674}

This is non-standard and not even documented on MDN.

On Firefox, setting RegExp.multiline to true adds the multiline flag to all
newly created RegExp objects (both from constructor and from literal).

In V8 this has no effect.

Source archaelogy shows that this is from the initial commit.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1410993008

Cr-Commit-Position: refs/heads/master@{#31673}

BUG=chromium:490559
LOG=NO

Review URL: https://codereview.chromium.org/1425143002

Cr-Commit-Position: refs/heads/master@{#31672}

This moves all cctest files for the compiler to live in the same
namespace as the components they are testing. Hence we can avoid the
forbidden using directives pulling in entire namespaces.

From the Google C++ style guide: "You may not use a using-directive to
make all names from a namespace available". This would be covered by
presubmit linter checks if build/namespaces were not blacklisted.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1424943004

Cr-Commit-Position: refs/heads/master@{#31671}

If you are not logged in with your Google account you are
faced with a blank screen. In order to make it more
clear for the Chromium sheriffs on how to close the
auto-roller I want to add this information.

R=machenbach@chromium.org
LOG=N
NOTRY=true

Review URL: https://codereview.chromium.org/1392823004

Cr-Commit-Position: refs/heads/master@{#31670}

BUG=

Review URL: https://codereview.chromium.org/1418213007

Cr-Commit-Position: refs/heads/master@{#31669}

In order to properly (lazy) bailout when converting the receiver for
sloppy mode functions (using the newly added JSConvertReceiver
operator), we need to have a bailout location right before every call
(also right before every %_Call and %_CallFunction), otherwise if the
JSConvertReceiver just reuses the lazy bailout frame state from the
JSCallFunction node, it will skip the whole function in case of lazy
bailout.

Note it should be impossible to trigger this currently because we do not
yet support AllocationSite code dependencies in TurboFan, which can
trigger this kind of lazy bailout; therefore it's not possible to write
a regression test (yet).

R=yangguo@chromium.org
BUG=v8:4493
LOG=n

Review URL: https://codereview.chromium.org/1425883004

Cr-Commit-Position: refs/heads/master@{#31668}

Rolling v8/buildtools to acafdaa4e81adae617177d57e3c1261cc3565469

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

Review URL: https://codereview.chromium.org/1420973008

Cr-Commit-Position: refs/heads/master@{#31667}

We have plans to create more ICs, and we are out of bits to represent the Kind
in the flags field of the code object. The InlineCacheState can lose a bit
because it no longer needs the DEFAULT state. That state existed as a way to
detect errors where code incorrectly looked at a vector IC stub's
InlineCacheState instead of correctly determining said state from a glance at
the vector. This really isn't a danger anymore.

So, with the horse trading, we could now represent up to 32 code kinds.

BUG=

Review URL: https://codereview.chromium.org/1427803003

Cr-Commit-Position: refs/heads/master@{#31666}

R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1423673003

Cr-Commit-Position: refs/heads/master@{#31665}

This fixes [NAMED|KEYED]_SUPER_PROPERTY_CALL to perform a method call
instead of a function call. The difference is visible for sloppy mode
targets that convert primitive receivers.

R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4525
BUG=v8:4525
LOG=n

Review URL: https://codereview.chromium.org/1419173004

Cr-Commit-Position: refs/heads/master@{#31664}

Most use sites of Call::GetCallType already distinguish the property
call case (i.e. formerly known as Call::PROPERTY_CALL) further. This
introduces this distinction to simplify use sites.

R=rossberg@chromium.org

Review URL: https://codereview.chromium.org/1414413004

Cr-Commit-Position: refs/heads/master@{#31663}

we may introduce moves that are redundant in the context of
moves on subsequent instructions. Currently, we only detect such
redundancies by allowing moves to skip over Nop instructions (true
nops, with no input/output). We can also skip over other cases, for
example over constant definitions (nop with an output), since whatever
moves happen above it do not influence the instruction's outcome.

We may be able to handle other cases, too - in subsequent CLs.

BUG=

Review URL: https://codereview.chromium.org/1422333003

Cr-Commit-Position: refs/heads/master@{#31662}

Proxies are not properly supported yet.

R=rossberg,jkummerow@chromium.org
BUG=v8:3931
LOG=n

Review URL: https://codereview.chromium.org/1421033002

Cr-Commit-Position: refs/heads/master@{#31661}

This requires copying usage flags from the outer scope to the
arrow scope upon encountering the arrow token.

In order to properly pass-on the calls_eval bit, now record
that bit on script scopes just like everywhere else, and add
necessary code to scopes.cc to handle that change in behavior.

Also factored out scope flag propagation to its own method to
make the call site simple (though note that only the eval
bit makes any difference for arrows).

BUG=v8:4395
LOG=n

Review URL: https://codereview.chromium.org/1423613002

Cr-Commit-Position: refs/heads/master@{#31660}

The fix is to broaden the set of cases for when NeedsHomeObject()
returns true. Note that this is broader than it needs to be (since,
e.g., non-arrow function scopes inside a method can't reference
super). But we don't track the types of inner scopes at the moment,
so this is the best we can do.

R=rossberg@chromium.org
BUG=v8:4522
LOG=n

Review URL: https://codereview.chromium.org/1411093008

Cr-Commit-Position: refs/heads/master@{#31659}

Also deprecate hidden values

BUG=none
LOG=y
R=rossberg@chromium.org,yangguo@chromium.org

Review URL: https://codereview.chromium.org/1428793002

Cr-Commit-Position: refs/heads/master@{#31658}

Reland of [heap] Decrease incremental marking finalization retry limit. (patchset #1 id:1 of https://codereview.chromium.org/1428783004/ )

Reason for revert:
Unnecessary revert.

Original issue's description:
> Revert of [heap] Decrease incremental marking finalization retry limit. (patchset #1 id:1 of https://codereview.chromium.org/1408183006/ )
>
> Reason for revert:
> crashes on webkit_unit_tests V8-Blink Linux 32
>
> Original issue's description:
> > [heap] Decrease incremental marking finalization retry limit.
> >
> > BUG=chromium:548562
> > LOG=n
> >
> > Committed: https://crrev.com/c689f5759b46506c38c84f404ebd8dc326dcb76f
> > Cr-Commit-Position: refs/heads/master@{#31647}
>
> TBR=ulan@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:548562
>
> Committed: https://crrev.com/f555708c5ee583dafbc803b0917c9cd87f1c9ac3
> Cr-Commit-Position: refs/heads/master@{#31648}

TBR=ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:548562

Review URL: https://codereview.chromium.org/1412683010

Cr-Commit-Position: refs/heads/master@{#31657}

R=jkummerow@chromium.org

Review URL: https://codereview.chromium.org/1407213005

Cr-Commit-Position: refs/heads/master@{#31656}

for starting major GC in the memory reducer.

BUG=

Review URL: https://codereview.chromium.org/1414483004

Cr-Commit-Position: refs/heads/master@{#31655}

This adapts the general purpose inlining heuristic to not inline within
or across the boundary of asm.js code. Note that this only affects the
heuristics, from a functional point of view it is still supported.

R=bmeurer@chromium.org
BUG=chromium:549000
LOG=n

Review URL: https://codereview.chromium.org/1418823005

Cr-Commit-Position: refs/heads/master@{#31654}

R=jarin@chromium.org
TEST=unittests/JSTypedLoweringTest.JSCreateArguments

Review URL: https://codereview.chromium.org/1417983004

Cr-Commit-Position: refs/heads/master@{#31653}

This refactors the handling of calls of type Call::PROPERTY_CALL to
super properties in AstGraphBuilder::VisitCall. It ensures that the
operand stack is kept in sync with full-codegen so that deopts while
evaluating sub-expressions behave as expected.

R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4521
BUG=v8:4521
LOG=n

Review URL: https://codereview.chromium.org/1426893003

Cr-Commit-Position: refs/heads/master@{#31652}

For..in introduces 3 new bytecodes ForInPrepare, ForInNext, and
ForInDone to start a for..in loop, get the next element, and check if
the loop is done.

For..in builds upon new LoopBuilder constructs for conditionally
breaking and continuing during iteration: BreakIf{Null|Undefined}
and ContinueIf{Null|Undefined}. New conditional jump bytecodes
support this succinctly: JumpIfNull and JumpIfUndefined.

Add missing check to BytecodeLabel that could allow multiple
forward referencess to the same label which is not supported.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1422033002

Cr-Commit-Position: refs/heads/master@{#31651}

[Interpreter] Ensure we save the BytecodeArray register properly in InterpreterEntryTrampoline builtin.

Ensure that we save the BytecodeArray register in the InterpreterEntryTrampoline
before calling out to the kStackGuard runtime function.

BUG=v8:4280
LOG=N

Review URL: https://codereview.chromium.org/1426863005

Cr-Commit-Position: refs/heads/master@{#31650}

Review URL: https://codereview.chromium.org/1431443002

Cr-Commit-Position: refs/heads/master@{#31649}

Revert of [heap] Decrease incremental marking finalization retry limit. (patchset #1 id:1 of https://codereview.chromium.org/1408183006/ )

Reason for revert:
crashes on webkit_unit_tests V8-Blink Linux 32

Original issue's description:
> [heap] Decrease incremental marking finalization retry limit.
>
> BUG=chromium:548562
> LOG=n
>
> Committed: https://crrev.com/c689f5759b46506c38c84f404ebd8dc326dcb76f
> Cr-Commit-Position: refs/heads/master@{#31647}

TBR=ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:548562

Review URL: https://codereview.chromium.org/1428783004

Cr-Commit-Position: refs/heads/master@{#31648}

BUG=chromium:548562
LOG=n

Review URL: https://codereview.chromium.org/1408183006

Cr-Commit-Position: refs/heads/master@{#31647}

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1424983003

Cr-Commit-Position: refs/heads/master@{#31646}

Add support for stores that transition to writable data fields,
based on the BeginRegion/FinishRegion mechanism for atomic regions
in the scheduler.

This is early work and still a bit rough around the edges, and similar
to regular stores, we don't support transitioning stores to double
fields yet.

R=jarin@chromium.org
BUG=v8:4470
LOG=n

Review URL: https://codereview.chromium.org/1406153010

Cr-Commit-Position: refs/heads/master@{#31645}

R=littledan@chromium.org

Review URL: https://codereview.chromium.org/1430643003

Cr-Commit-Position: refs/heads/master@{#31644}

R=littledan@chromium.org
BUG=v8:4305, v8:4343, v8:4344, v8:4345
LOG=N

Review URL: https://codereview.chromium.org/1424113003

Cr-Commit-Position: refs/heads/master@{#31643}

R=littledan@chromium.org
BUG=v8:3593
LOG=n

Review URL: https://codereview.chromium.org/1407233013

Cr-Commit-Position: refs/heads/master@{#31642}

Many places in the JavaScript standard library are changed in ES2015 from
getting an integer using ToUint32 to using ToLength. This patch stages
the flag turning on those new semantics.

BUG=v8:3087,v8:4244
LOG=Y
R=adamk

Review URL: https://codereview.chromium.org/1426673003

Cr-Commit-Position: refs/heads/master@{#31641}

This patch wraps callsites to %AddElement to fall back to adding a
named property in case it is given an argument of 2**32 or greater.
The change is needed because %AddElement is called by Array functions
in various places, and ES2015 changes these Array functions to use
ToLength rather than ToUint32, so several callsites of %AddElement
which used to be reliable array indices may be larger numbers. While
the proper long-term solution may be to call out to
Object.defineProperty, this fix should allow the ToLength semantics
to be shipped while preserving correctness and not requiring a
rewrite.

BUG=v8:4516
LOG=Y
R=adamk
TEST=Interactively ran Array.prototype.slice on an Array-like which
exceeded array bounds, and found that this did not check-fail at
runtime as it did before.
Microbenchmarked this technique against the previous version on a
simple reverse implementation and found at most a 1% slowdown, as
opposed to other techniques, like calling %DefineDataPropertyUnchecked,
which had a 20% slowdown or Object.defineProperty with a 80% slowdown.

Review URL: https://codereview.chromium.org/1420663003

Cr-Commit-Position: refs/heads/master@{#31640}