of non-pattern expressions, according to the (internally circulated)
design document.  Details to be provided here.

1.  RewritableAssignmentExpression has been renamed to RewritableExpression.
    It is a wrapper for AST nodes that wait for some potential rewriting
    (that may or may not happen).  Also, Is... and As... macros now see
    through RewritableExpressions.

2.  The function state keeps a list of rewritable expressions that must be
    rewritten only if they are used as non-pattern expressions.

3.  Expression classifiers are now templates, parameterized by parser
    traits.  They keep some additional state: a pointer to the list of
    non-pattern rewritable expressions.  It is important that expression
    classifiers be used strictly in a stack fashion, from now on.

4.  The RewriteNonPattern function has been simplified.

BUG=chromium:579913
LOG=N

Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c
Cr-Commit-Position: refs/heads/master@{#34154}

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

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

Revert of Non-pattern rewriting revisited (patchset #3 id:40001 of https://codereview.chromium.org/1702063002/ )

Reason for revert:
[Sheriff] This makes jsfunfuzz unhappy:
https://build.chromium.org/p/client.v8/builders/V8%20Fuzzer/builds/7681

Original issue's description:
> This patch implements an alternative approach to the rewriting
> of non-pattern expressions, according to the (internally circulated)
> design document.  Details to be provided here.
>
> 1.  RewritableAssignmentExpression has been renamed to RewritableExpression.
>     It is a wrapper for AST nodes that wait for some potential rewriting
>     (that may or may not happen).  Also, Is... and As... macros now see
>     through RewritableExpressions.
>
> 2.  The function state keeps a list of rewritable expressions that must be
>     rewritten only if they are used as non-pattern expressions.
>
> 3.  Expression classifiers are now templates, parameterized by parser
>     traits.  They keep some additional state: a pointer to the list of
>     non-pattern rewritable expressions.  It is important that expression
>     classifiers be used strictly in a stack fashion, from now on.
>
> 4.  The RewriteNonPattern function has been simplified.
>
> BUG=chromium:579913
> LOG=N
>
> Committed: https://crrev.com/7f5c864a6faf2b957b7273891e143b9bde35487c
> Cr-Commit-Position: refs/heads/master@{#34154}

TBR=rossberg@chromium.org,bmeurer@chromium.org,titzer@chromium.org,nikolaos@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:579913

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

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

of non-pattern expressions, according to the (internally circulated)
design document.  Details to be provided here.

1.  RewritableAssignmentExpression has been renamed to RewritableExpression.
    It is a wrapper for AST nodes that wait for some potential rewriting
    (that may or may not happen).  Also, Is... and As... macros now see
    through RewritableExpressions.

2.  The function state keeps a list of rewritable expressions that must be
    rewritten only if they are used as non-pattern expressions.

3.  Expression classifiers are now templates, parameterized by parser
    traits.  They keep some additional state: a pointer to the list of
    non-pattern rewritable expressions.  It is important that expression
    classifiers be used strictly in a stack fashion, from now on.

4.  The RewriteNonPattern function has been simplified.

BUG=chromium:579913
LOG=N

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

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

Revert of Type Feedback Vector lives in the closure (patchset #2 id:40001 of https://codereview.chromium.org/1668103002/ )

Reason for revert:
Must revert for now due to chromium api natives issues.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> (RELAND: the problem before was a missing write barrier for adding the code
> entry to the new closure. It's been addressed with a new macro instruction
> and test. The only change to this CL is the addition of two calls to
> __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
> Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
> And Benedikt reviewed it as well.
>
> TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/bb31db3ad6de16f86a61f6c7bbfd3274e3d957b5
> Cr-Commit-Position: refs/heads/master@{#33741}

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

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

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

(RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

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

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

This CL removes the Config templatization from the types. It is not
necessary anymore, after the HeapTypes have been removed.

The CL also changes the type hierarchy - the specific type kinds are
not inner classes of the Type class and they do not inherit from Type.
This is partly because it seems impossible to make this work without
templates. Instead, a new TypeBase class is introduced and all the
structural (i.e., non-bitset) types inherit from it.

The bitset type still requires the bit-munging hack and some nasty
reinterpret-casts to pretend bitsets are of type Type*. Additionally,
there is now the same hack for TypeBase - all pointers to the sub-types
of TypeBase are reinterpret-casted to Type*. This is to keep the type
constructors in inline method definitions (although it is unclear how
much that actually buys us).

In future, we would like to move to a model where we encapsulate Type*
into a class (or possibly use Type where we used to use Type*). This
would loosen the coupling between bitset size and pointer size, and
eventually we would be able to have more bits.

TBR=bradnelson@chromium.org

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

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

Revert of Type Feedback Vector lives in the closure (patchset #2 id:20001 of https://codereview.chromium.org/1642613002/ )

Reason for revert:
Bug: failing to use write barrier when writing code entry into closure.

Original issue's description:
> Reland of Type Feedback Vector lives in the closure
>
> (Fixed a bug found by nosnap builds.)
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
> BUG=
>
> Committed: https://crrev.com/d984b3b0ce91e55800f5323b4bb32a06f8a5aab1
> Cr-Commit-Position: refs/heads/master@{#33548}

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

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

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

(Fixed a bug found by nosnap builds.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org
BUG=

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

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

Revert of Type Feedback Vector lives in the closure (patchset #12 id:260001 of https://codereview.chromium.org/1563213002/ )

Reason for revert:
FAilure on win32 bot, need to investigate webkit failures.

Original issue's description:
> Type Feedback Vector lives in the closure
>
> We get less "pollution" of type feedback if we have one vector per native
> context, rather than one for the whole system. This CL moves the vector
> appropriately.
>
> We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
> vector actually lives in the first slot of the literals array (indeed there is
> great commonality between those arrays, they can be thought of as the same
> thing). So we make greater effort to ensure there is a valid literals array
> after compilation.
>
> This meant, for performance reasons, that we needed to extend
> FastNewClosureStub to support creating closures with literals. And ultimately,
> it drove us to move the optimized code map lookup out of FastNewClosureStub
> and into the compile lazy builtin.
>
> The heap change is trivial so I TBR Hannes for it...
>
> TBR=hpayer@chromium.org
>
> BUG=
>
> Committed: https://crrev.com/a5200f7ed4d11c6b882fa667da7a1864226544b4
> Cr-Commit-Position: refs/heads/master@{#33518}

TBR=bmeurer@chromium.org,akos.palfi@imgtec.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=

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

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

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...

TBR=hpayer@chromium.org

BUG=

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

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

After 1564083002, spread expressions are desugared and should not
survive in the AST after parsing. This patch removes dead code
related to this.  It also eliminates the kSpread bailout reason
and the concat_iterable_to_array_builtin.

R=bmeurer@chromium.org
BUG=

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

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

Attempt #<really big number>

Parses, and lazily rewrites Destructuring Assignment expressions. The rewriting strategy involves inserting a placeholder RewritableAssignmentExpression into the AST, whose content expression can be completely rewritten at a later time.

Lazy rewriting ensures that errors do not occur due to eagerly rewriting nodes which form part of a binding pattern, thus breaking the meaning of the pattern --- or by eagerly rewriting ambiguous constructs that are not immediately known

BUG=v8:811
LOG=Y
R=adamk@chromium.org, bmeurer@chromium.org, rossberg@chromium.org

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

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

Moves all files related to AST and scopes into ast/,
and all files related to scanner & parser to parsing/.

Also eliminates a couple of spurious dependencies.

R=mstarzinger@chromium.org
BUG=

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

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

BUG=

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

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

Adds an implementation of "do expression" parsing (https://webcache.googleusercontent.com/search?q=cache:MIGALjqPDNgJ:wiki.ecmascript.org/doku.php%3Fid%3Dstrawman:do_expressions+&cd=1&hl=en&ct=clnk&gl=us).

This feature provides a way to evaluate a block of statements within an expression context, producing the resulting completion value. This is very helpful for implementing certain language features via desugaring.

BUG=v8:4488
LOG=N
R=adamk@chromium.org, bmeurer@chromium.org, rossberg@chromium.org, wingo@igalia.com

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

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

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

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

This adds a bit of boilerplate to some AstVisitors (they now have to
declare their own zone_ member and zone() accessor), but makes it clearer
what DEFINE_AST_VISITOR_SUBCLASS_MEMBERS is for: stack limit checking.

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

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

Previously, any AstVisitor subclasses which wanted to make use of
the shared stack overflow checking code needed to depend on Isolate.

With this patch, it will be easy to create a second InitializeAstVisitor
overload taking a stack_limit directly, for use in code that has no
Isolate available (such as code running in the parser).

AstVisitor subclasses which depended upon the isolate() accessor have
been fixed to either have their own isolate_ member or get it from
somewhere else convenient.

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

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

This CL also allows to use arbitrary number of feedback vector elements for particular slot kind.

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

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

ES2015 specifies very particular semantics for functions defined in blocks.
In strict mode, it is simply a lexical binding scoped to that block. In sloppy
mode, in addition to that lexical binding, there is a var-style binding in
the outer scope, which is overwritten with the local binding when the function
declaration is evaluated, *as long as* introducing ths var binding would not
create a var/let conflict in the outer scope.

This patch implements the semantics by introducing a DelegateStatement, which
is initially filled in with the EmptyStatement and overwritten with the
assignment when the scope is closed out and it can be checked that there is
no conflict.

This patch is tested with a new mjsunit test, and I tried staging it and running
test262, finding that the tests that we have disabled due to lack of Annex B
support now pass.

R=adamk,rossberg
LOG=Y
BUG=v8:4285

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

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

There isn't a plan to turn it on soon, so we'll take it out in favor of cleaner code.

BUG=

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

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

The refactoring is because it's awkward and error-prone to deterimine which IC slot an
ObjectLiteralProperty uses for feedback. The fix is for each one to know it's own slot. In the
numbering pass, we allocate slots for the ObjectLiteral, then hand out those slots into the
properties.

It adds one word to the ObjectLiteralProperty expression - I'm investigating if thats a
problem.

This changes makes compiling the object literal cleaner across the three compilers. Also, the
slot allocation logic in ObjectLiteral::ComputeFeedbackRequirements() was refactoring to mimic
the style in full-codegen. This is useful since it must remain in sync with
FullCodegen::VisitObjectLiteral().

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

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

We're moving away from using CompilationInfo as a big bag o' stuff.
Passing in just what we need to several AstVisitors to avoid
increasing the problem.

BUG=None
TEST=trybots
R=titzer@chromium.org
LOG=N

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

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

Also, polymorphic element stores have a slightly different shape for the array
attached to a vector slot. It's of the form [map, map, handler], where the 2nd
map is either a transition map or undefined (the maps are actually in
WeakCells).

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

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

BUG=v8:4211
LOG=Y
R=rossberg@chromium.org

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

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

Revert of Parse arrow functions at proper precedence level (patchset #2 id:60001 of https://codereview.chromium.org/1286383005/ )

Reason for revert:
Breaks layout test. Please change test expectation on blink first.

--- /mnt/data/b/build/slave/V8-Blink_Linux_64/build/layout-test-results/inspector/sources/debugger-pause/debugger-pause-in-internal-expected.txt
+++ /mnt/data/b/build/slave/V8-Blink_Linux_64/build/layout-test-results/inspector/sources/debugger-pause/debugger-pause-in-internal-actual.txt
@@ -1,4 +1,4 @@
-CONSOLE ERROR: line 9: Uncaught SyntaxError: Expected () to start arrow function, but got '}' instead of '=>'
+CONSOLE ERROR: line 9: Uncaught SyntaxError: Unexpected token )
 Tests that pause on exception in internal script does not crash.

 Script source was shown.

Original issue's description:
> Parse arrow functions at proper precedence level
>
> BUG=v8:4211
> LOG=Y
> R=rossberg@chromium.org
>
> Committed: https://crrev.com/9271b0ccf9ddb217deb1f0b9ef9b59b64dc40214
> Cr-Commit-Position: refs/heads/master@{#30298}

TBR=rossberg@chromium.org,mstarzinger@chromium.org,fennyfanny655@gmail.com,machenbach@chromium.org,wingo@igalia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4211

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

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

While the class Type objects the AstTyper generates should be
allocated to zone memory, there's no particular reason
the typer object itself needs to be.

BUG=None
TEST=None
R=rossberg@chromium.org,titzer@chromium.org
LOG=N

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

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

BUG=v8:4211
LOG=Y
R=rossberg@chromium.org

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

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

R=rossberg@chromium.org
BUG=

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

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

This tries to remove includes of "-inl.h" headers from normal ".h"
headers, thereby reducing the chance of any cyclic dependencies and
decreasing the average size of our compilation units.

Note that this change still leaves 7 violations of that rule in the
code. However there now is the "tools/check-inline-includes.sh" tool
detecting such violations.

R=bmeurer@chromium.org

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

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

This adds the implicit function variable for a function literal to the
declarations list in scope analysis, instead of specially handling it
throughout all back-ends.

R=rossberg@chromium.org

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

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

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

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

BUG=v8:4132
LOG=N

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

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

Revert of Reland "Keep a canonical list of shared function infos." (patchset #3 id:40001 of https://codereview.chromium.org/1211453002/)

Reason for revert:
proxies test failing https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/903/steps/Mjsunit/logs/proxies

Original issue's description:
> Reland "Keep a canonical list of shared function infos."
>
> This reverts commit 3164aa74.
>
> Committed: https://crrev.com/cacb646d80daa429f6915824a741f595db7d5044
> Cr-Commit-Position: refs/heads/master@{#29282}

TBR=adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

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

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

This reverts commit 3164aa74.

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

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

Speculative revert in the hopes of fixing serializer crashes seen in canary.

This reverts commit c1669450, as well as
followup change "Do not look for existing shared function info when compiling a new script."
(commit 7c43967b).

BUG=chromium:503552,v8:4132
TBR=yangguo@chromium.org
LOG=n

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

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

Each Script object now keeps a WeakFixedArray of SharedFunctionInfo
objects created from this script.

This way, when compiling a function, we do not create duplicate shared
function info objects when recompiling with either compiler.

This fixes a class of issues in the debugger, where we set break points
on one shared function info, but functions from duplicate shared function
infos are not affected.

LOG=N
BUG=v8:4132

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

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

This splits the SuperReference AST node into SuperPropertyReference and
SuperCallReference. The super call reference node consists of three
unresolved vars to this, new.target and this_function. These gets
declared when the right function is entered and if it is in use. The
variables gets assigned in FullCodeGenerator::Generate.

This is a revert of the revert 88b1c917

BUG=v8:3768
LOG=N
R=wingo@igalia.com, adamk@chromium.org

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

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

When compiling on a laptop I like to concatenate the small test files.
This makes a big difference to compile times. These changes make that
easier.

R=ulan@chromium.org
BUG=

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

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

Revert of [es6] Super call in arrows and eval (patchset #5 id:100001 of https://codereview.chromium.org/1146863007/)

Reason for revert:
Fails

http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%201/builds/579/steps/Check/logs/super

Original issue's description:
> [es6] Super call in arrows and eval
>
> This splits the SuperReference AST node into SuperPropertyReference and
> SuperCallReference. The super call reference node consists of three
> unresolved vars to this, new.target and this_function. These gets
> declared when the right function is entered and if it is in use. The
> variables gets assigned in FullCodeGenerator::Generate.
>
> BUG=v8:3768
> LOG=N
> R=wingo@igalia.com, adamk@chromium.org
>
> Committed: https://crrev.com/673c0516ab96f24343bbb26e0afc2846b5a679df
> Cr-Commit-Position: refs/heads/master@{#28731}

TBR=wingo@igalia.com,adamk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3768

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

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