Previously we'd check `x` for -0 by testing `(1.0 / x) == -Infinity`,
but this will yield the wrong results when `x` is a subnormal, i.e.
really close to 0.
In CSA we already perform bit checks to test for -0, so teach TurboFan
to do the same for comparisons to -0 (via `Object.is`). We introduce a
new NumberIsMinusZero simplified operator to handle the case where
SimplifiedLowering already knows that the input is a number.
Bug: chromium:903043, v8:6882
Change-Id: I0cb7c568029b461a92fc183104d5f359b4bfe7f4
Reviewed-on: https://chromium-review.googlesource.com/c/1328802
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57382}
Since we use a ScopedPtrList to track cover grammar expressions we don't know
the position of the commas anymore. The position of the commas was used to
demark the initializer, which is needed to figure out whether we need hole
checks for variable references. (Typically only references within the
initializer need hole checks for the initialized variable.) Since we didn't
have the comma position, we simply used the position of the first expression as
the position of any subsequent comma, which would make it seem as if the
initializer body wasn't in the initializer. Now instead we simply use the
position of the subsequent parameter as the end of the initializer, which is
close enough.
Bug: chromium:902810
Change-Id: I8d2bc7a2dc9f59db16ce56ccef01e263a18a3b7a
Reviewed-on: https://chromium-review.googlesource.com/c/1326022
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57357}
The Ignition statement list visitor will skip the rest of the
statements in the list if it hits a jump statement (like a return
or break), as the rest of the code in the list can be considered
dead.
return;
dead_call(); // skipped
However, since this is at an AST node level, it does not take into
account condition shortcutting:
if(2.2) return;
dead_call(); // not skipped
There is also a second dead code elimination in Ignition compilation, at
the bytecode array writer level, where a bytecodes are not emitted if an
"exit" bytecode (Return, Jump, or a few others) has been written, until
the next basic block starts (i.e. a Bind).
This can cause an issue with statements that resurrect the bytecode
array writer part-way through their visit. An example is try-catch
statements, which save the context to a register, and then Bind to start
the try region.
For the case:
if (2.2) return;
try { // try statement not skipped
...
}
the bytecode writer is called with
OutputReturn() // exit bytecode seen
OutputMove(<context>, r1) // not emitted
Bind(&try_begin) // starts new basic block
// try body
So, the try is emitted, but without saving the context to a register.
This means that the liveness analysis sees the read of that register
(as the output liveness of throwing bytecodes), but does not have a
write to the register, which means that the liveness escapes.
This patch fixes this by using the bytecode array writer dead-code
elimination (i.e. "exit bytecode seen") to inform the statement list
visitor, so that in this example the try statement is not visited at
all.
Bug: chromium:902395
Change-Id: Ieb8e46a4318df3edbac0ae17235e0ce8fba12ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1322951
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57350}
Installation of the PrototypePropertyDependency, as well as GC, can
invalidate dependencies.
Bug: chromium:902552
Change-Id: Iabcce026c7475c722d19ac0b80758b22d9fbcfda
Reviewed-on: https://chromium-review.googlesource.com/c/1322450
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57343}
regress-336820 is testing that joining a very sparse
array to create a too-big string results in a RangeError,
rather than a crash. Reducing the largest index by
two orders of magnitude speeds this up (on x64 debug)
by 8x (from 8 seconds down to 1). Given that this test
takes nearly 9 minutes on arm64 sim debug, I hope to
see big ones there too.
Bug: v8:7783, chromium:336820
Change-Id: I74c22cf451a892eb039efc7f1259152921bf8530
Reviewed-on: https://chromium-review.googlesource.com/c/1323915
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57335}
The array length is modifiable by user code that is called as a
side-effect during the sorting algorithm. We thus cannot base any
guarantees on the current length, but must reference the initially-read
array length instead.
Note that even though the algorithm may read and write from beyond
the current array length value, this adheres to the spec, which only
requires accesses to be within the original array dimensions (i.e.: 0
<= i < original array length).
Bug: chromium:901633
Change-Id: Id765e80d4231ff6f2a73e040ec94c2b07f8c5b0f
Reviewed-on: https://chromium-review.googlesource.com/c/1317814
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57279}
- Avoid allocating AstRawString in the preparser
- Use fast LiteralEquals to compare the directive.
Bug: chromium:901250
Change-Id: I178aca812f6c0ffa28d7f48b707316a5a99a2ac0
Reviewed-on: https://chromium-review.googlesource.com/c/1314570
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57217}
Restructure the code a little, and change how we detect sloppy block function
redeclaration so we don't dereference a possibly nullptr function.
Bug: chromium:900786
Change-Id: Ief124fe767603ca36f4dc8865c4aeb3e0635b4cf
Reviewed-on: https://chromium-review.googlesource.com/c/1314331
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57206}
The fast-path in the `ArrayPrototypeLastIndexOf` torque implementation
didn't check that the `fromIndex` is within the bounds of the JSArray
_AFTER_ the call to ToInteger, which can have arbitrary side-effects,
i.e. it can change the length of the array.
R=yangguo@chromium.org
Bug: chromium:898785
Change-Id: I7ef84143ec8c33148f6e9d451bd52769d5074fb4
Reviewed-on: https://chromium-review.googlesource.com/c/1314329
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57204}
CanCover is not transitive. The counter example are Nodes A,B,C such
that CanCover(A, B) and CanCover(B,C) and B is pure. In this case the
effect level of A and B might differ.
This CL adds a missing CanCover check to a case of shift reduction where
we assumed transitivity.
Change-Id: I9f368ffa6907d2af21bbc87b3e6570d0d422e125
Bug: v8:8384
Reviewed-on: https://chromium-review.googlesource.com/c/1307419
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57157}
For memory limit checks, we should use the minimum of the
--wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a
limit set by the user, the latter is the maximum we can handle
internally.
R=titzer@chromium.org
Bug: chromium:898677
Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc
Reviewed-on: https://chromium-review.googlesource.com/c/1305274
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57127}
The "grow_memory" opcode was renamed to "memory.grow", and the spec
repo was updated to use kExprMemoryGrow internally instead of
kExprGrowMemory (https://github.com/WebAssembly/spec/pull/720).
This CL does the same change for v8.
Drive-by: Rename "current_size" to "memory.size", and a minor cleanup
in wasm-graph-builder.js to bring it in line with the version in the
js-api tests in the spec repo.
R=titzer@chromium.org
Change-Id: If525dba898b2c248890a616d3392c22b45f698ef
Reviewed-on: https://chromium-review.googlesource.com/c/1302057
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57089}
This fixes the fall-back case when parsing a multiplicative expression
where the lookahead found a '-' token followed by an unsigned token, but
no '*' token is following. We cannot rewind both tokens, but still need
to make sure that a full multiplicative expression is parsed.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-8377
BUG=v8:8377
Change-Id: I20ce6267445b32bdaf03f41f11d9ef4be66cb636
Reviewed-on: https://chromium-review.googlesource.com/c/1304317
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57084}
This allows very large arrays being joined to incrementally,
on-demand allocate the internal buffer. Previously, join
would allocate the buffer upfront and all at once. Large,
sparse arrays will use less memory.
Bug: chromium:897404
Change-Id: Id914b14a7c55a62834f63ad602bdb45363249075
Reviewed-on: https://chromium-review.googlesource.com/c/1303538
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57075}
While not strictly necessary, this is consistent with how
SlowFlagGetter behaves. It adds an additional shift operation (which
we could fold into the smi untagging if needed).
Drive-by: Typify flag accessors.
Bug: chromium:899464
Change-Id: Ib154d626e522ed723e2c19b1ab7f68560ac414bc
Reviewed-on: https://chromium-review.googlesource.com/c/1304315
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57063}
When replacing a LoadElement with variable index with its known fields,
only do it if the types match, otherwise we end up with a graph that
representation selection cannot handle. That can only happen in dead
code, but TurboFan would nevertheless crash in representation selection.
Bug: chromium:893982, chromium:899524, v8:5267, v8:6200
Change-Id: I01e645d5e01bffb911d216d37d923792d9d0beab
Reviewed-on: https://chromium-review.googlesource.com/c/1303721
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57059}
The assumption behind this optimization was invalid. Even if the
string's prototype is unchanged, the symbol could exist somewhere
further up the prototype chain.
GetProperty has been sped up significantly so it might be fine to just
skip this fast path. An alternative would be to use a protector cell.
Bug: v8:8357
Change-Id: Ia577107a58157350eb15780c02aa63d77e600637
Reviewed-on: https://chromium-review.googlesource.com/c/1301498
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57038}
This just adds calls to SerializePrototype right before we access the
serialized prototype. Eventually we need to do this earlier.
Bug: v8:7790, chromium:899115
Change-Id: I597e95f5f6df8aae608ee295fe9550e7c2a45e6d
Reviewed-on: https://chromium-review.googlesource.com/c/1301475
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57034}
The valid store types of a {Float64Array} heap view are specified to be
"float?" and "double?". We correctly accepted both types but forgot to
emit the appropriate conversion in the "float?" case. This just adds the
missing conversion expression.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-898974
BUG=chromium:898974,v8:8347
Change-Id: I306b10e2088185b1522da29b1a113908ef9925f2
Reviewed-on: https://chromium-review.googlesource.com/c/1301499
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57025}
Checking impl()->IsAsync(identifier) is insufficient since it could be
parenthesized. By checking the token in addition to IsIdentifier guarantees
that we've only seen the single token ASYNC.
Bug: chromium:898812
Change-Id: Id94dd607381050b4bd8cd6d8672a5d11256db7da
Reviewed-on: https://chromium-review.googlesource.com/c/1300134
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57013}
PrepareElementsForSort must return a number less than or equal the array
length.
Bug: chromium:897512, v8:7382
Change-Id: If5f9c4d052e623ab9f3300b8534603abbee859fa
Reviewed-on: https://chromium-review.googlesource.com/c/1297958
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56982}
This reverts commit ec969ea3b1.
Reason for revert: test fails consistently on arm bots.
I can't repro the failure locally, but it does consume ~512MB of memory (for a single string, I think?), so my guess is that the bots don't have enough contiguous address space.
Original change's description:
> [builtins] Fix Array.p.join length overflow and invalid string length handling
>
> - Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
> - When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
> - Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
>
> - Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
>
> Bug: chromium:897404
> Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
> Reviewed-on: https://chromium-review.googlesource.com/c/1293070
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56907}
TBR=danno@chromium.org,peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org
Change-Id: I8ca80bd75833aacc94ccb25ceb82bbc8880991db
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:897404
Reviewed-on: https://chromium-review.googlesource.com/c/1297471
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56915}
- Fixes and simplify allocating the temporary fixed array for ToString-ed elements.
- When the array size is greater than representable by an intptr, it overflowed into a negative value causing a non-negative assert to fail.
- Simplify fallback behavior by always allocating a conservatively sized temporary fixed array. Previously, if the array had dictionary elements, the temporary fixed array was sized based on %GetNumberDictionaryNumberOfElements() and then resized when entering the fallback.
- Fixes related invalid string length handling. When the running total of the resulting string length overflowed or exceeded String::kMaxLength, a RangeError is thrown. Previously, this thrown RangeError bypassed JoinStackPop and left the receiver on the stack.
Bug: chromium:897404
Change-Id: I157b71ef04ab06125a5b1c3454e5ed3713bdb591
Reviewed-on: https://chromium-review.googlesource.com/c/1293070
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56907}
Whenever left-trimming is possible (e.g. whenever user code is
called), we must not store a reference to an exposed JSArray's
elements.
Bug: chromium:897366,v8:7382
Change-Id: I8dd6a93aa6ed19e755ccce7122e0e019dc578a31
Reviewed-on: https://chromium-review.googlesource.com/c/1292066
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56903}
This is to fix test262 tests which expect that there is no arguments
object.
Bug: v8:7186
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I56205c29609666dc832297e4d36a4d487eae36cc
Reviewed-on: https://chromium-review.googlesource.com/c/1291469
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56890}
Previously we'd first accumulate errors to the parent and validate the
destructuring pattern in the parent. In the case of ParseArguments this
will invalidly propagate binding pattern errors from one argument to the
next. The reason why ParseArguments keeps track of binding pattern errors
is because it could also be used to parse async arrow function parameters.
If we see async(a,b) we don't yet know whether this is the head of an
async arrow function, or a call to async with arguments a and b.
Bug: v8:8241
Change-Id: I670ab9a9c6f2e0bee399808b02a465ae1afa7c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1296229
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56887}
In the ElementsAccessor fast-path for Array.prototype.includes, we
iterate backing-store elements according to start and length numbers
which might or might not be within the JSArray::length field, for
example when side-effects changed the receiver while start and length
are computed. So even when we have a packed ElementsKind, we might still
observe the hole. This is fine, since logical out-of-bounds accesses
are safe in this case, but it means we must not rely on the
ElementsKind telling us if we can encounter holes.
Bug: chromium:897098
Change-Id: I17db38246aef6edbdd5cee30598cbf7619aba6d8
Reviewed-on: https://chromium-review.googlesource.com/c/1293571
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56884}
With async_hooks it's also possible that the "current microtask" is an
await task, whose generator is already suspended, when there's an
exception thrown in the AFTER callback. In that case we cannot build
a meaningful async stack trace.
Bug: chromium:897406, v8:7522
Change-Id: I682dc1fc3ebb1864e1c2061041ff99ced0313f0c
Reviewed-on: https://chromium-review.googlesource.com/c/1292057
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56839}
In the process:
- add volatile types for FastJSArray and remove the length_fast accessor
from JSArray with the application of more rigorous typing.
- add micro benchmarks for testing all the interesting slice cases
Also update a few assorted places in .tq code to make them more
idiomatic.
The original version of this patch had an overly agressive assert that has
been loosened.
TBR=jgruber@chromium.org
Change-Id: I56870862f4b124d1b38372daa326182a526c874c
Reviewed-on: https://chromium-review.googlesource.com/c/1291375
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56829}
This reverts commit 41ba3d3eb0.
Reason for revert: Speculative revert:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Fuzzer/27370https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20predictable/19895
Original change's description:
> [builtins] Implement Array.prototype.slice in Torque
>
> In the process:
>
> - add volatile types for FastJSArray and remove the length_fast accessor
> from JSArray with the application of more rigorous typing.
> - add micro benchmarks for testing all the interesting slice cases
>
> Also update a few assorted places in .tq code to make them more
> idiomatic.
>
> Change-Id: I76ec2bb25b65a869180af1f7288419dc1f0a9c37
> Reviewed-on: https://chromium-review.googlesource.com/c/1281603
> Commit-Queue: Daniel Clifford <danno@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56806}
TBR=danno@chromium.org,jgruber@chromium.org,tebbi@chromium.org
Change-Id: I1f2c82b4c3ab0848857f620facacf9604d4fcd11
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1290973
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56815}
In the process:
- add volatile types for FastJSArray and remove the length_fast accessor
from JSArray with the application of more rigorous typing.
- add micro benchmarks for testing all the interesting slice cases
Also update a few assorted places in .tq code to make them more
idiomatic.
Change-Id: I76ec2bb25b65a869180af1f7288419dc1f0a9c37
Reviewed-on: https://chromium-review.googlesource.com/c/1281603
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56806}
When --async-stack-traces is on and there's an exception from within an
async_hook "after" handler, we will be faced with a settled promise. In
that case we cannot do anything, since the promise will not have any
reactions on it anymore, but we should also not crash of course.
Bug: chromium:896700, v8:7522
Change-Id: I6e3d212d0433da40740489ff7421c5a98cf9bff3
Reviewed-on: https://chromium-review.googlesource.com/c/1290550
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56801}
When creating the buffer for the fall back, the initial entry was not
considered when calculating the size.
Bug: chromium:896181
Change-Id: I7f15bb1bdf31b3255db91b1fe8dcd68c76033980
Reviewed-on: https://chromium-review.googlesource.com/c/1286957
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#56768}
Properly handle the case where the CheckFloat64Hole becomes a
no-op after RETYPE (because the feedback type is already Number).
We always need to pass the Number restriction type here.
Bug: chromium:895199
Change-Id: I96a949ba35db1e6d35abedddc4507c101d95b716
Reviewed-on: https://chromium-review.googlesource.com/c/1278804
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56622}
