Ignition collects type feedback for binary and compare operations in type
feedback vector and FCG uses Binary/CompareOpICs to collect type feedback.
The feedback collected by ignition is not used by crankshaft. This hits the
performance, when trying to optimize functions that did not tier upto FCG.
This cl merges the feedback collected by ignition and FCG when passing to
crankshaft.

BUG=v8:4280

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

TBR=bmeurer@chromium.org
BUG=v8:5294

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

Revert of includes: Make ast.h not need isolate.h any more. (patchset #3 id:60001 of https://codereview.chromium.org/2301423002/ )

Reason for revert:
Breaks gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/5642

Original issue's description:
> includes: Make ast.h not need isolate.h any more.
>
> Also remove other unnecessary includes from ast.h and dependencies.
>
> BUG=v8:5294
>
> Committed: https://crrev.com/9c888dffda4bff420ec3ef21e623aa4e5054d1c3
> Cr-Commit-Position: refs/heads/master@{#39155}

TBR=adamk@chromium.org,mstarzinger@chromium.org,bmeurer@chromium.org,marja@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5294

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

Also remove other unnecessary includes from ast.h and dependencies.

BUG=v8:5294

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

This makes for slightly faster rebuilds when touching parser-base.h
(which changes frequently!). Also takes care of an old TODO,
moving CompileTimeValue into its own file under ast/, where it
properly belongs.

BUG=v8:5294

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

Our Type class has a semantic and representational dimension.
Much code in src/ast, Crankshaft and Turbofan is based on it.
Going forward in Turbofan we'd like to remove representational information
entirely. To that end, new type AstType has been created to preserve
existing behavior for the benefit of Crankshaft and the AST.

BUG=

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

This additionally gets rid of old approach to global shortcuts.

BUG=v8:5209

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

R=adamk@chromium.org
BUG=v8:1569

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

Removes Variable::is_possibly_eval() and instead stores whether
a call is possibly eval in the Call node's bitfield.

Also removes HandleDereferenceMode since it's no longer used.

BUG=v8:5203

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

This reduces peak zone memory usage by ~10% on codeload and ~5% on mandreel.

BUG=v8:5209

Committed: https://crrev.com/2648162dcfff622f8587cea2faa8c3af56456968
Review-Url: https://codereview.chromium.org/2209573002
Cr-Original-Commit-Position: refs/heads/master@{#38367}
Cr-Commit-Position: refs/heads/master@{#38390}

Revert of Separate Scope into DeclarationScope and Scope (patchset #13 id:240001 of https://codereview.chromium.org/2209573002/ )

Reason for revert:
[Sheriff] Make leak checker unhappy:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug/builds/10959

Original issue's description:
> Separate Scope into DeclarationScope and Scope
>
> This reduces peak zone memory usage by ~10% on codeload and ~5% on mandreel.
>
> BUG=v8:5209
>
> Committed: https://crrev.com/2648162dcfff622f8587cea2faa8c3af56456968
> Cr-Commit-Position: refs/heads/master@{#38367}

TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,adamk@chromium.org,verwaest@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5209

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

This reduces peak zone memory usage by ~10% on codeload and ~5% on mandreel.

BUG=v8:5209

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

Highlights:
- Record all imports and exports in the ModuleDescriptor.
- Remove ImportDeclaration; instead, introduce a new variable kind for imports.
- Set name on default exported anonymous functions.

Still to do: declaration of namespace imports.

BUG=v8:1569

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

R=adamk@chromium.org
BUG=

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

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.

BUG=

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

Expression::bounds_ is used only by a subset of compile passes, but the
data structure occupies space for every Expression node ever parsed. This
unneccessarily increases memory consumption. Particularly, peak memory
consumption during startup, which may cause out-of-memory errors.

This CL
- removes Expression::bounds_;
- introduces an AstTypeBounds container, which mappes Expression* to Bounds;
- modifies the code that actually requires bounds information, namely
  Crankshaft compile and AsmWasmBuilder, to instantiate such an AstTypeBounds
  container before typing and to pass it to the code that consumes this
  information; and
- modifies all accesses to Expression::bounds_ to instead access the bounds
  via the container instead.

Additionally, this rewrites test-ast-expression-visitor. The reason is that
this code attempted to test AstExpressionVisitor but did so exclusively
through its subclass ExpressionTypeCollector, meaning that the test dealt
almost exclusively with type bounds despite the class-under-test having
no knowledge or functionality related to it. Worse, the test was written
in a way to assume that type bounds were available outside & after
compilation, which is something this change changes.

BUG=v8:4947

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

Also make all AstVisitors consistently visit all the relevant parts
of ForOfStatement. PrettyPrinter no longer fares well, but given
how much desugaring happens to ForOf in the parser, any pretty-printed
view of it isn't going to be human readable. AstPrinter, on the other
hand, now gives a realistic view of what's been generated for for-of.

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

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}