- 24 Oct, 2018 1 commit
-
-
Caitlin Potter authored
The assertion was intended to verify that the function is only called at appropriate times (at a point when it was called both by by other builtins, and by desugarings added in the parser and during bytecode generation) --- However, it didn't account for the case where the wrapper Promise is resolved with another JSPromise with a non-callable "then" method. (Step 12 of https://tc39.github.io/ecma262/#sec-promise-resolve-functions): "If IsCallable(thenAction) is false, then Return FulfillPromise(promise, resolution)." It would be observable to verify this behaviour by loading the "then" value and asserting that it's non-callable, so instead the CSA_ASSERT is just removed and replaced with a comment explaining the appropriate use of the function. BUG=chromium:897436, v8:5855 R=bmeurer@chromium.org Change-Id: Ib4b11abfe3339409b57ccfda9c3f75a34e0db532 Reviewed-on: https://chromium-review.googlesource.com/c/1296909 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56916}
-
- 23 Oct, 2018 39 commits
-
-
Jakob Kummerow authored
This reverts commit ec969ea3. 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/1297471Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#56915}
-
Yang Guo authored
This reverts commit 1d837093. Reason for revert: Speculative revert for https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm%20-%20debug/8158 Original change's description: > [heap] Clean-up MemoryChunk allocation area constants. > > Change-Id: I8ba59546ab93c7af98bc5ece2f0160628844dd92 > Reviewed-on: https://chromium-review.googlesource.com/c/1280584 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Hannes Payer <hpayer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56908} TBR=ulan@chromium.org,yangguo@chromium.org,hpayer@chromium.org Change-Id: I0ce51513864d3f7e4337391dc510fb828c083d48 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/1296488Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56914}
-
Clemens Hammacher authored
When resetting the {unique_ptr} to the {CompilationState} in the {NativeModule}, what actually happens is that first the pointer stored in the {unique_ptr} is reset to {nullptr}, then the destructor is called. The destructor of {CompilationState} cancels and waits for background compile jobs. While doing so, background compile jobs still try to access the {unique_ptr} in the {NativeModule}. This CL fixes this race by splitting the shutdown in two steps: First, cancel and wait the background compile jobs, and only later reset the pointer. R=ahaas@chromium.org Bug: v8:8359 No-Tree-Checks: true Change-Id: Ifa3bdf3424dfd5a4712d33f8ca85f9382b1766a6 Reviewed-on: https://chromium-review.googlesource.com/c/1296486 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56913}
-
Michael Hablich authored
This reverts commit fcbb023b. Reason for revert: blocks roll https://chromium-review.googlesource.com/c/chromium/src/+/1296315 Original change's description: > Add Windows ARM64 ABI support to V8 > > This change added Windows ARM64 ABI support, major things are: > 1. Excluding x18 register from any usage because it is reserved as > platform register. Preserve alignment after the change. > 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is > still LLP64. > 3. Stack guard page probe for large allocation on stack. > > Reference: > Windows ARM64 ABI: > https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017 > > Bug: chromium:893460 > Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e > Reviewed-on: https://chromium-review.googlesource.com/c/1285129 > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56881} TBR=bbudge@chromium.org,ulan@chromium.org,machenbach@chromium.org,hpayer@chromium.org,brucedawson@chromium.org,mlippautz@chromium.org,ahaas@chromium.org,bmeurer@chromium.org,Tom.Tan@microsoft.com Change-Id: I0b804af6dfca9409a655194fa6e5407f209be2dc No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:893460 Reviewed-on: https://chromium-review.googlesource.com/c/1296460Reviewed-by:
Michael Hablich <hablich@chromium.org> Commit-Queue: Michael Hablich <hablich@chromium.org> Cr-Commit-Position: refs/heads/master@{#56912}
-
Michael Lippautz authored
Marking resets global handles which touches the corresponding slots on the embedder side. The embedder may already have freed the memory which results in use after free. Bug: chromium:843903 Change-Id: I05a62f28d801b4de167f6fbf1be29743544c1293 Reviewed-on: https://chromium-review.googlesource.com/c/1296457Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#56911}
-
Joyee Cheung authored
This patch merges ClassLiteralProperty::PUBLIC_FIELD and ClassLiteralProperty::PRIVATE_FIELD into ClassLiteralProperty::FIELD, and moves the visibility part into ClassLiteralProperty::is_private() for the ease of adding new combinations in the future. Bug: v8:8330 R=gsathya@chromium.org Change-Id: I54f64d05bccb1867d9111e4c80158a6075406d80 Reviewed-on: https://chromium-review.googlesource.com/c/1291052Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#56910}
-
Clemens Hammacher authored
Background tasks are not throttled any more, so there is no need to restart background compile after finishing units. Background tasks will only stop if all compilation units have been processed. R=ahaas@chromium.org Change-Id: I2b28c079bf5847cd5eb4f65629b9aed89afa8d1e Reviewed-on: https://chromium-review.googlesource.com/c/1296477Reviewed-by:
-
Hannes Payer authored
Change-Id: I8ba59546ab93c7af98bc5ece2f0160628844dd92 Reviewed-on: https://chromium-review.googlesource.com/c/1280584Reviewed-by:
-
peterwmwong authored
- 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}
-
Clemens Hammacher authored
R=mstarzinger@chromium.org Bug: v8:8238 Change-Id: I93c9d2a643731766f15f4db1bf7647a85488a6d0 Reviewed-on: https://chromium-review.googlesource.com/c/1296454Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56906}
-
Florian Sattler authored
Bug: chromium:897815, chromium:897935, chromium:897766 Change-Id: Ie8c4105867f84054559a4c43c23be82365502c1e Reviewed-on: https://chromium-review.googlesource.com/c/1296469Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
-
Michael Starzinger authored
R=ulan@chromium.org Change-Id: I73f6fc0baee8e1219a88d4d8f594bba16e64f332 Reviewed-on: https://chromium-review.googlesource.com/c/1296480Reviewed-by:
-
Jakob Gruber authored
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/1292066Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#56903}
-
Benedikt Meurer authored
This introduces a new bit on the Isolate which tells whether promise hooks, async event delegate or the debug delegate are enabled. Use this new bit in places where we generally need to take the slow path due to async instrumentation. Bug: v8:7253, v8:7522, v8:8238 Change-Id: I8f34eeb9f8f7b56fcbb4deb59ac51b2d0907ff6c Reviewed-on: https://chromium-review.googlesource.com/c/1296473 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
-
Dan Elphick authored
Bug: v8:8329 Change-Id: I5be972698809ca77a621bb960cbc6a23b9f0f4b0 Reviewed-on: https://chromium-review.googlesource.com/c/1296474Reviewed-by:
-
Michael Achenbach authored
NOTRY=true TBR=sergiyb@chromium.org Bug: chromium:830557 Change-Id: I598a8591559c489944da6aa06fea793aaed0fa6e Reviewed-on: https://chromium-review.googlesource.com/c/1296479Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56900}
-
Michael Achenbach authored
NOTRY=true TBR=sergiyb@chromium.org Bug: chromium:830557 Change-Id: Ie9022b04cb5858654c6903f38031c860e8681b9e Reviewed-on: https://chromium-review.googlesource.com/c/1296478Reviewed-by:
-
Michael Achenbach authored
NOTRY=true Bug: v8:8291 Change-Id: Iae948ef9de027f86702accf34487524fd1c6b538 Reviewed-on: https://chromium-review.googlesource.com/c/1296455 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Sergiy Byelozyorov <sergiyb@chromium.org> Cr-Commit-Position: refs/heads/master@{#56898}
-
Clemens Hammacher authored
This is the last method which modified the Result after construction. Turn this into a named constructor instead. Drive-by: Replace a Result<bool> by VoidResult, since the bool is not used anywhere. R=mstarzinger@chromium.org Bug: v8:8238 Change-Id: I352e0687e99a90e6ad00587d6fdf388f68c9b60a Reviewed-on: https://chromium-review.googlesource.com/c/1296271 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
Instead, create it when needed and pass it down to the actual compilation. This saves memory by making the WasmCompilationUnit smaller and will eventually allow us to implement the trap handler fallback correctly by using an updated ModuleEnv in background compilation and tier up. R=mstarzinger@chromium.org Bug: v8:5277, v8:8343 Change-Id: I0dc3a37fb88e54eb4822dc99d58ff024f4b2a367 Reviewed-on: https://chromium-review.googlesource.com/c/1293953 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
Update two more uses of {bool} instead of {UseTrapHandler}. R=mstarzinger@chromium.org Change-Id: I83715661a2238004a4cbccf271a2bf781ef2f44d Reviewed-on: https://chromium-review.googlesource.com/c/1293952 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Michael Achenbach authored
NOTRY=true TBR=sergiyb@chromium.org Bug: chromium:830557 Change-Id: I2dd9e040c0d29a49aa0a23283da67d550a110677 Reviewed-on: https://chromium-review.googlesource.com/c/1296453Reviewed-by:
-
Clemens Hammacher authored
This is to prepare larger refactorings that reduce the amount of information stored in the WasmCompilationUnits and avoid ever storing the ModuleEnv. Instead, we will generate it when needed. This will allow us to correctly switch from a trap-handler configuration to non-trap-handler. R=mstarzinger@chromium.org Bug: v8:8343, v8:5277 Change-Id: I383a8105448ccdcae1148ddfebd74db70c648ecf Reviewed-on: https://chromium-review.googlesource.com/c/1293951Reviewed-by:
-
Florian Sattler authored
Bug: v8:8351 Change-Id: I6ea08e0eb8b77a578a6a4fbe3eb0b96e6c3a0f95 Reviewed-on: https://chromium-review.googlesource.com/c/1296451Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Florian Sattler <sattlerf@google.com> Cr-Commit-Position: refs/heads/master@{#56892}
-
Michael Achenbach authored
All configs auto-generated with https://crrev.com/c/1270796. NOTRY=true TBR=sergiyb@chromium.org Bug: chromium:830557 Change-Id: Ie421a3a01bbcd996297ab3a8585dd6f116e29886 Reviewed-on: https://chromium-review.googlesource.com/c/1296449Reviewed-by:
-
Yang Guo authored
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/1291469Reviewed-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}
-
Peter Marshall authored
This reverts commit c92a1dda. Reason for revert: Breaks arm sim: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm%20-%20sim/15207 Original change's description: > [cpu-profiler] Fix a bug which caused a pure virtual function call > > We need to remove each Sampler from the SamplerManager before we call > the Sampler destructor. This is because the signal handler can interrupt > the destructor, and call DoSampler(), which calls sampler->SampleStack() > on the sampler being destructed, causing general unhappiness and > "Pure virtual function called!" crashes. > > Bug: v8:8346, v8:5193 > Change-Id: Iaa595a196eab33fb1af31584e9a68fd1ce0a18f6 > Reviewed-on: https://chromium-review.googlesource.com/c/1293949 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Alexei Filippov <alph@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56882} TBR=alph@chromium.org,yangguo@chromium.org,petermarshall@chromium.org Change-Id: I517e07d75045f6253e7f12714304fba77959fbc2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8346, v8:5193 Reviewed-on: https://chromium-review.googlesource.com/c/1296472Reviewed-by:
-
Toon Verwaest authored
Change-Id: I403a6c5124f560d47a3b5d54d79bf54563207c1e Reviewed-on: https://chromium-review.googlesource.com/c/1296269Reviewed-by:
-
Toon Verwaest authored
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ä authored
Previous version: https://chromium-review.googlesource.com/c/v8/v8/+/1292058 BUG=v8:8179 TBR=hpayer@chromium.org, gsathya@chromium.org Change-Id: Ia79b75a0630c5926e59206c29053addc88bfb6fe Reviewed-on: https://chromium-review.googlesource.com/c/1296210Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
-
Michael Achenbach authored
All configs auto-generated with https://crrev.com/c/1270796/9. NOTRY=true TBR=sergiyb@chromium.org Bug: chromium:830557 Change-Id: Ibc56891314907c0de393ce6858cac1450664e4c6 Reviewed-on: https://chromium-review.googlesource.com/c/1296270Reviewed-by:
-
Tobias Tebbi authored
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/1293571Reviewed-by:
-
Andreas Haas authored
The DEPS file was already up to date, so we only had to update the hash. R=herhut@chromium.org Change-Id: Ibbf960e140746b522339cb8f649691a08f4cd485 Reviewed-on: https://chromium-review.googlesource.com/c/1293576Reviewed-by:
Stephan Herhut <herhut@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56883}
-
Peter Marshall authored
We need to remove each Sampler from the SamplerManager before we call the Sampler destructor. This is because the signal handler can interrupt the destructor, and call DoSampler(), which calls sampler->SampleStack() on the sampler being destructed, causing general unhappiness and "Pure virtual function called!" crashes. Bug: v8:8346, v8:5193 Change-Id: Iaa595a196eab33fb1af31584e9a68fd1ce0a18f6 Reviewed-on: https://chromium-review.googlesource.com/c/1293949 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#56882}
-
Tom Tan authored
This change added Windows ARM64 ABI support, major things are: 1. Excluding x18 register from any usage because it is reserved as platform register. Preserve alignment after the change. 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is still LLP64. 3. Stack guard page probe for large allocation on stack. Reference: Windows ARM64 ABI: https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017 Bug: chromium:893460 Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e Reviewed-on: https://chromium-review.googlesource.com/c/1285129 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Gus Caplan authored
This CL replaces the stack trace parameter with a the array that is usually passed to the JS prepareStackTrace callback. This allows two important goals to be realized: 1) we can easily stringify individual frames and 2) we can (if needed) call back into JS from this callback with a usable structure. If, as is sometimes the case, a v8::StackTrace is needed, |v8::Exception::GetStackTrace| can be used on the exception that is passed to PrepareStackTraceCallback. Bug: v8:7637 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I57fa1f2b4552cc7f69351fe0918f4e59e3f5fce1 Reviewed-on: https://chromium-review.googlesource.com/c/1266698Reviewed-by:
-
Hai Dang authored
Currently Torque's Array.prototype.slice creates holey arrays for those that don't fit in new space in its slow path (by calling ArraySpeciesCreate), even if the source is packed. This creates regression on packed arrays where TurboFan optimizes and then deoptimizes because the maps don't match. See https://chromeperf.appspot.com/report?sid=4553b0826123337f5026fd6b4a285d5fc3cd77cafb515ddd954d195630642730 This CL reduces the chance that Torque's Array.prototype.slice returns holey arrays. In particular, in the case of a large FastJSArray, ExtractFastJSArray can still be used because it can handle large objects, and will return a packed array if the source array is also packed. Change-Id: I691cf48e07c699e5d42afda0bea6cbdc117b653f Reviewed-on: https://chromium-review.googlesource.com/c/1293372Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Daniel Clifford <danno@chromium.org> Commit-Queue: Hai Dang <dhai@google.com> Cr-Commit-Position: refs/heads/master@{#56879}
-
Benedikt Meurer authored
This builtin was initially used to create the promise for an async function, but that is now done by the AsyncFunctionEnter intrinsic. Bug: v8:7253 Change-Id: I90d0bb31c1548bbfdb53833a5c06161db368f4f0 Reviewed-on: https://chromium-review.googlesource.com/c/1296129Reviewed-by:
-
Hannes Payer authored
Bug: chromium:897074 Change-Id: I65894046064a230847f3e629e56d8a171546aa51 Reviewed-on: https://chromium-review.googlesource.com/c/1293950Reviewed-by:
-
