- 04 Oct, 2018 22 commits
-
-
v8-ci-autoroll-builder authored
Rolling v8/test/test262/data: https://chromium.googlesource.com/external/github.com/tc39/test262/+log/7e65999..ff8b10c TBR=adamk@chromium.org,gsathya@chromium.org Change-Id: I7c7bc6367724498f17ccfabce88b29c2f4595121 Reviewed-on: https://chromium-review.googlesource.com/c/1261876Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#56382}
-
Alexei Filippov authored
Change-Id: I1022cceafed0b27fa2fb5f0f30a1b75fd3a27f3f Reviewed-on: https://chromium-review.googlesource.com/c/1260258Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#56381}
-
Benedikt Meurer authored
Holes in double arrays are encoded using a signaling NaN bit pattern. Previously when checking for Float64 holes we did an expensive bit check always, but most values aren't even NaNs in reality. So we changed the CheckFloat64Hole operator to first check if the value is a NaN at all and only if so, perform the concrete bit check (in deferred code). This improves the array copying test case mentioned in the bug from copyPacked: 123 ms. copyHoley: 157 ms. to copyPacked: 122 ms. copyHoley: 125 ms. so there's almost no penalty for double holey arrays anymore in case of copying arrays. This change seems to yield an overall ~1% on the Kraken benchmark. Bug: v8:8264 Change-Id: Id7393867ec96fdc080e24d326039f80a9d7b6646 Reviewed-on: https://chromium-review.googlesource.com/c/1261519Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56380}
-
Sreten Kovacevic authored
AtomicPair operations are only available with some instructions introduced in version R6. Add support for needed instructions. Change-Id: I808d6ed5b5efafd638846ec599941ebc71d90e23 Reviewed-on: https://chromium-review.googlesource.com/c/1251526Reviewed-by:
Ivica Bogosavljevic <ibogosavljevic@wavecomp.com> Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Sreten Kovacevic <skovacevic@wavecomp.com> Cr-Commit-Position: refs/heads/master@{#56379}
-
Andreas Haas authored
We want to replace all uses of CallOnForegroundThread eventually by the new TaskRunner API so that we can eventually deprecate the old API and remove it. R=ulan@chromium.org Bug: v8:8238 Change-Id: I7e451eddf05f1f7f273c5cfd57d82737380f3f02 Reviewed-on: https://chromium-review.googlesource.com/c/1261145Reviewed-by:
-
Toon Verwaest authored
This makes it more explicit what we're actually parsing and allows us to omit unnecessary checks. Change-Id: I3e22ab4af0f23cee51cb689dd6377565e42f9bad Reviewed-on: https://chromium-review.googlesource.com/c/1260943Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56377}
-
Toon Verwaest authored
Use Check rather than if peek() + Expect/Consume Change-Id: I5bc98288a751234117a2708c17dbb68008af5838 Reviewed-on: https://chromium-review.googlesource.com/c/1261144Reviewed-by:
-
Andreas Haas authored
We want to replace all uses of CallOnForegroundThread eventually by the new TaskRunner API so that we can eventually deprecate the old API and remove it. R=leszeks@chromium.org Bug: v8:8238 Change-Id: I6a1e55fe431225ffe4c77cd3387f3b060eb43edf Reviewed-on: https://chromium-review.googlesource.com/c/1256866Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56375}
-
Jaroslav Sevcik authored
The goal is to remove CL to remove the confusing implications for full poisoning. This is an alternative to https://chromium-review.googlesource.com/c/chromium/src/+/1253341 where chrome has to work around our implication system. In the optimizing compiler, we already have a bottleneck for setting mitigation level in src/compiler/pipeline.cc, so it is easy to change back to partial mitigations. Bug: chromium:888892 Change-Id: I01de7ed7bb91e8b06f8f79cc2d90657a0600892a Reviewed-on: https://chromium-review.googlesource.com/c/1252985Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56374}
-
Stephan Herhut authored
This had bit-rotten a little and did no longer work for compiling webassembly code. Also, correct the output of live ranges so that it can be parsed again. Bug: v8:8238 Change-Id: I09c2d8bd604f3be12ead8b968f0b70287fad65f1 Reviewed-on: https://chromium-review.googlesource.com/c/1256864 Commit-Queue: Stephan Herhut <herhut@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#56373}
-
Benedikt Meurer authored
For NumberModulus and SpeculativeNumberModulus there's no observable difference between 0 and -0 for the right hand side, since both of them result in NaN (in general the sign of the right hand side is ignored for modulus in JavaScript). For the left hand side we can just propagate the zero identification part of the truncation, since we only care about -0 on the left hand side if the use nodes care about -0 too. This further improves the Kraken/audio-oscillator test from around 67ms to 64ms. Bug: v8:8015, v8:8178 Change-Id: I1f51d42f7df08aaa28a9b0ddd3177df6b76be98c Reviewed-on: https://chromium-review.googlesource.com/c/1260024 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#56372}
-
Benedikt Meurer authored
This is a follow-up cleanup to treat NumberRound like the other rounding operations (NumberFloor, NumberCeil and NumberTrunc). Bug: v8:8015 Change-Id: I2b2fbc7f0319497d16ccb7472595eeb68be1f51d Reviewed-on: https://chromium-review.googlesource.com/c/1260403Reviewed-by:
-
Benedikt Meurer authored
The slow-path of CheckedInt32Mod(x,y) when x is found to be negative still had the power of two right hand side optimization, and thus would perform a dynamic check on y. Now the same dynamic check was done for the fast-path, and the word operations for this check were pure, leading to weird bit materialization in TurboFan (due to sea of nodes). But there's not really a point to be clever for the slow-path, so we just insert the Uint32Mod operation directly here, which completely avoids the problem. This improves the Kraken/audio-oscillator test from around 73ms to 69ms. Bug: v8:8069 Change-Id: Ie8ea667136c95df2bd8c5ba56ebbc6bd2442ff23 Reviewed-on: https://chromium-review.googlesource.com/c/1259063Reviewed-by:
-
Benedikt Meurer authored
When converting a Signed32\/MinusZero value from Word32 to Float64 representation or just passing it through as Word32 (with potential type checks on it) we don't need to worry about -0 as long as the uses identify 0 and -0. Drive-by-fix: Fix the CheckChange() helper in the representation changer test to pass Truncation::Any() by default. Bug: chromium:891639, chromium:891612, chromium:891627, v8:8015, v8:8178 Change-Id: I06948ec0cdb8e778cb3678124ef927277a5f40ee Reviewed-on: https://chromium-review.googlesource.com/c/1258902Reviewed-by:
-
Dan Elphick authored
Adds new VisitModes VISIT_ALL_BUT_READ_ONLY and VISIT_STRONG_FOR_SERIALIZATION. GC-related methods like MarkReachableObjects now now use VISIT_ALL_BUT_READ_ONLY instead of VISIT_ALL. All GC-related VisitModes skip iterating over the read-only roots. All Serializer methods should always use a _FOR_SERIALIZATION value to ensure they do visit the read-only roots. Also adds RootsTable::read_only_roots_begin and end methods. Bug: v8:7464 Change-Id: I468d7ae9f345d9fc0e10837f01dc5b92bd996412 Reviewed-on: https://chromium-review.googlesource.com/c/1256245Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#56368}
-
Clemens Hammacher authored
Often, tasks just need to call a single API method. By implementing such tasks via a lambda, we save a lot of boilerplate. Additionally, since lambdas are defined inside other function bodies, they have access to private methods, which sometimes allows for better encapsulation. This CL introduces {CancelableLambdaTask} and {CancelableIdleLambdaTask} and uses them to replace some custom tasks. More can be refactored later. R=ahaas@chromium.org Bug: v8:8238 Change-Id: I88bd2c9bd57ebc32d082528f2e4251d741a0d021 Reviewed-on: https://chromium-review.googlesource.com/c/1256773 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
This is a hack to make sure the atomic operations don't use the kRootRegister ebx before code generation. I've filed v8:8254 to track that a larger clean-up operation will be needed to remove this and other hacks. Change-Id: I6f28f01ba2f96257a9e65eaa36fcad66b01906dd Bug: v8:6666, v8:8254 Reviewed-on: https://chromium-review.googlesource.com/c/1256862Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
-
Maya Lekova authored
This reverts commit ef2a19a2. Reason for revert: Broken layout tests: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_rel_ng/201392 Original change's description: > Add fast path for spreading primitive strings. > > This improves the performance on primitive strings of > IterableToListWithSymbolLookup, which implements the > CreateArrayFromIterable bytecode. The fast path is only > taken if the string iterator protector is valid (that is, > String.prototype[Symbol.iterator] and > String.prototype[Symbol.iterator]().next are untouched). > > This brings spreading of primitive strings closer to the > performance of the string iterator optimizations. > (see https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8/). > > Bug: chromium:881273, v8:7980 > Change-Id: Ic8d8619da2f2afcc9346203613a844f62653fd7a > Reviewed-on: https://chromium-review.googlesource.com/1243110 > Commit-Queue: Hai Dang <dhai@google.com> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56329} TBR=ulan@chromium.org,neis@chromium.org,sigurds@chromium.org,bmeurer@chromium.org,dhai@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: chromium:881273, v8:7980 Change-Id: I4868160b87bdebf9fd2ff346aefd4cdce23681a1 Reviewed-on: https://chromium-review.googlesource.com/c/1261022Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Michael Achenbach authored
This undoes the workaround from https://crrev.com/c/1223426. Bug: chromium:887888 Change-Id: Id7a68354b1f1020d7d001ba4120be8a11f896067 Reviewed-on: https://chromium-review.googlesource.com/c/1260942 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Benedikt Meurer authored
This introduces a new flag --async-stack-traces, which enables zero-cost async stack traces. This enriches the non-standard Error.stack property with async stack frames computed from walking up the promise chains and collecting all the await suspension points along the way. In Error.stack these async frames are marked with "async" to make it possible to distinguish them from regular frames, for example: ``` Error: Some error message at bar (<anonymous>) at async foo (<anonymous>) ``` It's zero-cost because no additional information is collected during the execution of the program, but only the information already present in the promise chains is used to reconstruct an approximation of the async stack in case of an exception. But this approximation is limited to suspension points at await's in async functions. This depends on a recent ECMAScript specification change, flagged behind --harmony-await-optimization and implied the --async-stack-traces flag. Without this change there's no way to get from the outer promise of an async function to the rest of the promise chain, since the link is broken by the indirection introduced by await. For async functions the special outer promise, named .promise in the Parser desugaring, is now forcible allocated to stack slot 0 during scope resolution, to make it accessible to the stack frame construction logic. Note that this first prototype doesn't yet work fully support async generators and might have other limitations. Bug: v8:7522 Ref: nodejs/node#11865 Change-Id: I0cc8e3cdfe45dab56d3d506be2d25907409b01a9 Design-Document: http://bit.ly/v8-zero-cost-async-stack-traces Reviewed-on: https://chromium-review.googlesource.com/c/1256762 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:Adam Klein <adamk@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/3d9873f..29568c1 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/0daedf7..b250ec1 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Ifbe08a9e1f1dc077c7e5e253c483dfab6a648ebe Reviewed-on: https://chromium-review.googlesource.com/c/1260255Reviewed-by:
-
Frank Tang authored
Bug: v8:7684 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I0f83c37dd1f5bd85dc3f444b6583fda404812b92 Reviewed-on: https://chromium-review.googlesource.com/c/1260402Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#56361}
-
- 03 Oct, 2018 13 commits
-
-
Deepti Gandluri authored
When projection nodes are optimized, TempRegisters are used, which don't check to see if the registers are already in use. UseUniqueRegisters instead. Change-Id: I6a327098067daa3328355380da666d404fcc8b46 Bug: v8:8202, v8:6532 Reviewed-on: https://chromium-review.googlesource.com/c/1259107Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#56360}
-
Mathias Bynens authored
Bug: v8:7834 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I146f32f9f71beb58efefa12ffcf7beca67d6c850 Reviewed-on: https://chromium-review.googlesource.com/c/1259865 Commit-Queue: Mathias Bynens <mathias@chromium.org> Reviewed-by:
-
Frank Tang authored
Chrome side changes in https://chromium-review.googlesource.com/c/chromium/src/+/1255629 Bug: v8:8250 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Icba3e73217919c71925774d0cfbab69a7ffa1bba Reviewed-on: https://chromium-review.googlesource.com/c/1255628Reviewed-by:
-
Mathias Bynens authored
The proposal is currently at Stage 3 of the TC39 process. Repository: https://github.com/tc39/proposal-well-formed-stringify Bug: v8:7782 Change-Id: Id46054ec6873ca2d1bc8113b8c82b58b1b8427d2 Reviewed-on: https://chromium-review.googlesource.com/c/1257921Reviewed-by:
-
Vasili Skurydzin authored
fixed Abort() calling sequence on platforms with function descriptors by taking function descriptor of the External Reference object into account when calling C code. Change-Id: I54c04a5f1774f2768380cc5c95b1b807204335ce Reviewed-on: https://chromium-review.googlesource.com/c/1258186Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
-
Igor Sheludko authored
In particular, recognize builtins' values accesses and direct accesses to external reference values. For example: REX.W leaq rax,[r13+0x47a0] REX.W leaq rbx,[r13+0x80b0] turns into REX.W leaq rax,[r13+0x47a0] (builtin (RecordWrite)) REX.W leaq rbx,[r13+0x80b0] (external value (Isolate::context_address)) Bug: v8:8238 Change-Id: I3b049a1e82de7450bf04135c0c8d76b4dca4ee10 Reviewed-on: https://chromium-review.googlesource.com/c/1256830Reviewed-by:
-
Alexei Filippov authored
unordered_map is supposedly faster on deleting items. BUG=chromium:889545 Change-Id: Id92d9d663e8b9ab2978b8016ef5dccfc93dc104e Reviewed-on: https://chromium-review.googlesource.com/1255554Reviewed-by:
Ali Ijaz Sheikh <ofrobots@google.com> Commit-Queue: Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#56354}
-
andrew-cc-chen authored
Change-Id: Ic99e2e02ae644382873d9cf0621145bcde23b6b2 Reviewed-on: https://chromium-review.googlesource.com/1257807Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56353}
-
Junliang Yan authored
In C to WASM stubs, when number of parameters is more than 5, or anything requires stack arguments, current linkage is faulty because of missing STACK_SHADOW_WORDS Drive-by: Also cleanup s390 code which is not supported anymore. R=joransiu@ca.ibm.com Change-Id: I7405c32fd94e158e6868f9ce7d4390c995078dbb Reviewed-on: https://chromium-review.googlesource.com/c/1257269Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56352}
-
Hans Wennborg authored
This is part of clean-up for a new Clang warning that we'd like to enable. This patch addresses all warnings from V8 that I saw in a full debug build of Chromium on Linux. ../../v8/src/reloc-info.h:405:18: warning: explicitly defaulted move assignment operator is implicitly deleted [-Wdefaulted-function-deleted] RelocIterator& operator=(RelocIterator&&) = default; ^ ../../v8/src/reloc-info.h:447:13: note: move assignment operator of 'RelocIterator' is implicitly deleted because field 'mode_mask_' is of const-qualified type 'const int' const int mode_mask_; ^ ../../v8/src/wasm/baseline/liftoff-compiler.cc:111:36: warning: explicitly defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted] MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(LiftoffCompiler); ^ ../../v8/src/wasm/baseline/liftoff-compiler.cc:1834:20: note: move constructor of 'LiftoffCompiler' is implicitly deleted because field 'asm_' has a deleted move constructor LiftoffAssembler asm_; ^ ../../v8/src/wasm/wasm-debug.cc:95:3: warning: explicitly defaulted move assignment operator is implicitly deleted [-Wdefaulted-function-deleted] MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(InterpreterHandle); ^ ../../v8/src/wasm/wasm-debug.cc:98:19: note: move assignment operator of 'InterpreterHandle' is implicitly deleted because field 'interpreter_' has a deleted move assignment operator WasmInterpreter interpreter_; ^ ../../v8/src/wasm/wasm-interpreter.h:211:35: note: copy assignment operator of 'WasmInterpreter' is implicitly deleted because field 'internals_' is of const-qualified type 'v8::internal::wasm::WasmInterpreterInternals *const' WasmInterpreterInternals* const internals_; ^ Bug: chromium:890307 Change-Id: Idfc5827f24821212081a006c4329c466c4576bcc Reviewed-on: https://chromium-review.googlesource.com/c/1256863 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: -
Mathias Bynens authored
It was shipped in Chrome 66. Bug: v8:4958, v8:8255, v8:8238 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I52fb826f4f245bc6484d8f406ecf99bc17d268ee Reviewed-on: https://chromium-review.googlesource.com/c/1254123Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#56350}
-
Mathias Bynens authored
The proposal is currently at Stage 3 of the TC39 process. Repository: https://github.com/tc39/proposal-well-formed-stringify Bug: v8:7782 Change-Id: Ice2125ffd3dbc5381c81193eb64d460e0d5485cd Reviewed-on: https://chromium-review.googlesource.com/c/1255728Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/64ce4b0..3d9873f Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/2ba11d1..2dd9144 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/95d4c85..0daedf7 TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: I4cebb87b89dbd10a350cd6349c72eab428b6df57 Reviewed-on: https://chromium-review.googlesource.com/c/1258125Reviewed-by:
-
- 02 Oct, 2018 5 commits
-
-
Yang Guo authored
By moving the block range end to left of closing bracket, we can avoid ambiguity where an open-ended singleton range could be both interpreted as inside the parent range, or next to it. R=verwaest@chromium.org Bug: v8:8237 Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a Reviewed-on: https://chromium-review.googlesource.com/1254127Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#56347}
-
Sigurd Schneider authored
The root register is not available in JS-to-Wasm functions, and this was not reflected in the linkage. Similarily, it is not available in C-to-Wasm functions. Change-Id: I2dbfd06ef99d6f9b9940e9489f563441d9ebfabd Bug: v8:6666 Reviewed-on: https://chromium-review.googlesource.com/1256766 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Change-Id: Ia5f0a4d7635a1944f1d7fbadce4497d1914d2191 Reviewed-on: https://chromium-review.googlesource.com/1256967Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#56345}
-
andrew-cc-chen authored
Change-Id: I7591ccc55405a2fbd258bf28d53cd40a4bddf2c2 Reviewed-on: https://chromium-review.googlesource.com/1255102Reviewed-by:
-
Junliang Yan authored
Int64AbsWithOverflow should have 2 return value, the 2nd one should indicate whether it's overflow or not. This causes a debug failure on s390x. Change-Id: I2874227751d5874b47e63fed9e8f085f5165a44d Reviewed-on: https://chromium-review.googlesource.com/1255642Reviewed-by:
-
