- 10 Mar, 2020 3 commits
-
-
Iain Ireland authored
Non-unicode, case-insensitive regexps (e.g. /foo/i, not foo/iu) use a case-folding algorithm that doesn't quite match the Unicode definition. There are two places in irregexp that need to do case-folding. Prior to this patch, neither of them quite matched the spec (https://tc39.es/ecma262/#sec-runtime-semantics-canonicalize-ch). This patch implements the "Canonicalize" algorithm in src/regexp/special-case.h, and uses it in the relevant places. It replaces special-case logic around upper-casing / ASCII characters with the following approach: 1. For most characters, calling UnicodeSet::closeOver on a set containing that character will produce the correct set of case-insensitive matches. 2. For a small handful of characters (like the sharp S that prompted this change), UnicodeSet::closeOver will include some characters that should be omitted. For example, although closeOver('ß') = "ßẞ", uppercase('ß') is "SS", so step 3.e means that 'ß' canonicalizes to itself, and should not match 'ẞ'. In these cases, we can skip the closeOver entirely, because it will never add an equivalent character. These characters are in the IgnoreSet. 3. For an even smaller handful of characters, UnicodeSet::closeOver will produce some characters that should be omitted, but also some characters that should be included. For example, closeOver('k') = "kKK" (lowercase k, uppercase K, U+212A KELVIN SIGN), but KELVIN SIGN should not match either of the other two (step 3.g). To handle this, we put such characters in the SpecialAddSet. In these cases, we closeOver the original character, but filter out the results that do not have the same canonical value. The computation of IgnoreSet and SpecialAddSet happens at build time, using the pre-existing gen-regexp-special-case.cc step. R=jgruber@chromium.org Bug: v8:10248 Change-Id: I00d48b180c83bb8e645cc59eda57b01eab134f0b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072858Reviewed-by:
Frank Tang <ftang@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66641}
-
Daniel Bevenius authored
Change-Id: If9ef15e1ecbb75b7542b8033f68e63ba1a08cae1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091470Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/1739acf..9b4e026 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/fa6ae42..1a8a3a7 Rolling v8/buildtools/linux64: git_revision:4166e9fbc1fa5ceab69b69710a0f8b430c50127b..git_revision:fd3d768bcfd44a8d9639fe278581bd9851d0ce3a Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/c5f5b9e..abdb603 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ffd0295..a12175c Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/0f734f7..0a95832 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ib266db1413cabf622559762833896b304d6deeb8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095247Reviewed-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@{#66639}
-
- 09 Mar, 2020 19 commits
-
-
Ng Zhi An authored
In https://crrev.com/c/2084321 I added s128 load store to the fuzzer, and updated the memop generator to use IsPrefixOpcode check. But it was used wrongly. IsPrefixOpcode checks a 1 byte opcode and see if it is a prefix opcode, but if memory_op is already a 2 byte opcode, it will fail the IsPrefixOpcode check. Bug: chromium:1059899 Change-Id: I4caadfb2feaf42ebb9f5578cb790ef8a1d08d173 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095681Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66638}
-
Shu-yu Guo authored
Previous commit incorrectly inlined ToIntegerImpl into ToInteger_Inline, causing code bloat. Bug: chromium:1059364 Change-Id: I7bc369255a29a7ea567fafc775835c37584905b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2092843 Auto-Submit: Shu-yu Guo <syg@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66637}
-
Joyee Cheung authored
When looking for private members in an object for the inspector, we check if that object is a class constructor with the a bit has_static_private_methods set on its SFI. If it is, we look for any variables in the context locals with a VariableMode associated with private methods or accessors and a IsStaticFlag being kStatic. This patch also filters out static private methods when inspecting instances. Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit See also: https://docs.google.com/document/d/14maU596YbHcWR7XR-_iXM_ANhAAmiuRlJZysM61lqaE/edit Bug: v8:9839, v8:8330 Change-Id: Idad15349c983898de2ce632c38b0174da10e639d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1955664Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#66636}
-
Frank Tang authored
These two tests was fixed by ICU rolling to 0b6134378 See https://chromium-review.googlesource.com/c/chromium/src/+/2090002 File new bug 10313 to track the unrelated issue in built-ins/Date/parse/without-utc-offset Bug: v8:9612, v8:9474, v8:10313 Change-Id: I26f5857f3c4b6000b3585600bc3ed2f2ed29a043 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2095394Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#66635}
-
Z Nguyen-Huu authored
Bug: v8:10290 Change-Id: I35670fef49a89cd075fb654daec4b55440266673 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2088231 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66634}
-
Seth Brenith authored
Bill kindly pointed out to me that v8windbg was not handling bit_field2 correctly. The issue was that the constexpr type for ElementsKind was, somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully- qualified type name like "v8::internal::ElementsKind". This change addresses the problem in two ways: 1. Update v8windbg's type resolution logic to resolve type names as if they were used in the v8::internal namespace. This makes it more consistent with how those type names are used in other generated Torque code, reducing surprises and the number of times we have to write `v8::internal::` in .tq files. 2. Add compile-time verification that any constexpr type name used as a string in class-debug-readers-tq.cc can also resolve as a type name. Bug: v8:9376 Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769Reviewed-by:
-
Ng Zhi An authored
When dst is a fp pair, we set both low and high fp regs. Later when we look at set regs to determine which registers to load into, we examine both low and high fp. This is wrong - we only need to look at the low fp, since Fill will load into the correct fp pairs. The bug was triggered because we were examining into junk values in register_loads indexed by the high fp. Fixed: v8:10307 Change-Id: I6cbc212a969090818a5da0fe3dab36a418c23d04 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091632Reviewed-by:
-
Andreas Haas authored
There exists the pattern in wasm-compiler.cc of allocating a stack slot and filling it with values. This CL introduces a helper function for this pattern. Note that not all cases of this pattern can be changed to use the helper function. In these cases either the size of the stack slot is not statically known, or the stack slot is also used for return values. R=clemensb@chromium.org Bug: v8:10155 Change-Id: I8497a22fed730424561fc32bc1cfa21643341643 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093495Reviewed-by:
-
Clemens Backes authored
We now always tier down to Liftoff when the debugger is enabled, hence we don't need to force Liftoff-only execution in the test. R=thibaudm@chromium.org CC=duongn@microsoft.com Bug: v8:9654 Change-Id: I9b9e21b2ee977b349bb4f5d0e34c6ebf82166cb9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093504Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#66630}
-
Nico Hartmann authored
Bug: v8:7790 Change-Id: Ibdfe1c1a1ad2eb082583285493227fb833be4690 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093501 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#66629}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/e393474..1739acf Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/b3bfbaa..c5f5b9e Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ee8be8a..ffd0295 Rolling v8/third_party/icu: https://chromium.googlesource.com/chromium/deps/icu/+log/49ee7b1..0b61343 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/101bca1..0f734f7 Rolling v8/tools/luci-go: git_revision:02ba678a47594da180904851f3e6f809da7e0fc5..git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6 Rolling v8/tools/luci-go: git_revision:02ba678a47594da180904851f3e6f809da7e0fc5..git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6 Rolling v8/tools/luci-go: git_revision:02ba678a47594da180904851f3e6f809da7e0fc5..git_revision:3d22d4e5a77a3d9cbe4b1bf5ed2fc85b61c1e3e6 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Iba72789d04e02c6dcac6e37df5e66d1e6d079710 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2094658Reviewed-by:
-
Georg Neis authored
Bug: chromium:1051017 Change-Id: Id300c6d5f88b762e465383ac78ed037d3bc958d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089938 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
This CL merges nested loops that share the same header offset with its parent loop, by not emitting JumpLoop bytecode for these inner loops. Instead, we generate a Jump to its parent's JumpToHeader (which in turn can be a JumpLoop or another Jump to its parent's JumpToHeader). Originally, every loop had a unique first Bytecode to jump to. Since IterationBody StackChecks are going to become implicit this will no longer be the case. As a note, this CL just sets the foundation that the follow-up CLs will build on top of. Since we have explicit StackChecks, and they are at the beginning of loops we do not have nested loops as of now. Bug: v8:10149, v8:9960 Change-Id: I6daee4d2c6d6216f022228c87c4aa74e163997b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062390 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
-
Santiago Aboy Solanes authored
Change-Id: Iae85e97cd59f3270959e506f43dae22e6a331217 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078580Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66625}
-
Nico Hartmann authored
Bug: v8:9612 TBR=sathya@chromium.org, syg@chromium.org Change-Id: I6101d30e5af3e677c35deba202e22dfe4aa36869 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093498Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66624}
-
Jakob Kummerow authored
Considering that the security benefit is unclear at this point, the performance and binary size costs are not justified. This CL includes reverts of earlier partial disablings: 173a2bd8 af7bf14f 85f72be3 Bug: chromium:977230, chromium:1055312, chromium:1055317 Change-Id: I173b61656a542687c4619fa374a0b2ee22c85ef7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091474Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Hablich <hablich@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66623}
-
Dan Elphick authored
String::NewFromLiteral is a templated function that takes a char[N] argument that can be used as an alternative to String::NewFromUtf8 and returns a Local<String> rather than a MaybeLocal<String> reducing the number of ToLocalChecked() or other checks. Since the string length is known at compile time, it can statically assert that the length is less than String::kMaxLength, which means that it can never fail at runtime. This also converts all found uses of NewFromUtf8 taking a string literal or a variable initialized from a string literal to use the new API. In some cases the types of stored string literals are changed from const char* to const char[] to ensure the size is retained. This API does introduce a small difference compared to NewFromUtf8. For a case like "abc\0def", NewFromUtf8 (using length -1 to infer length) would treat this as a 3 character string, whereas the new API will treat it as a 7 character string. As a drive-by fix, this also fixes all redundant uses of v8::NewStringType::kNormal when passed to any of the String::New* functions. Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Mathias Bynens <mathias@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66622}
-
Tobias Tebbi authored
In the process: * Augment C++-generated Torque classes with SizeFor methods to calculate size of instances. * Add a new "@generateBodyDescriptor" annotation that causes Torque to generate C++ BodyDescriptors code that can be used to visit objects compatible with existing V8 mechanisms, e.g. GC * Fully automate C++ macro machinery so that adding non-extern Torque class doesn't require any C++ changes, including ensuring generation of instance types and proper boilerplate for validators and printers. * Make handling of @export a true annotation, allowing the modifier to be used on class declarations. * Add functionality such that classes with the @export annotation are available to be used from C++. Field accessors for exported classes are public and factory methods are generated to create instances of the objects from C++. * Change the Torque compiler such that Non-exported classes implicitly have the @generateBodyDescriptor annotation added and causes both verifiers and printers to be generated. * Switch non-extern Torque classes from using existing Struct-based machinery to being first-class classes that support more existing Torque class features. Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
Nico Hartmann authored
Bug: v8:9612 TBR=gsathya@chromium.org, syg@chromium.org Change-Id: I95b70f0c443904acd7fe1d05077acba28713b2b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093494 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
-
- 06 Mar, 2020 18 commits
-
-
Zhao Jiazhong authored
Port fd735e84 https://crrev.com/c/2067631 Change-Id: I720c4e218ea7a6088c61c2411c7c74e636f0772a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089228Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#66619}
-
Ng Zhi An authored
Bug: v8:10233 Change-Id: I8bb564e595d5c2b093adea0b9dde9c1c86dcee70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084318Reviewed-by:
-
Nate Chapin authored
This state can be set on the NativeContext by the embedder. When a PromiseReaction/PromiseReactionJobTask is constructed, store this contextual state if present, and restore it while the reaction job is running. Change-Id: I141cdbd9e36ea83ce4a6bf08440ae7eaa54523df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2005849Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Nate Chapin <japhet@chromium.org> Cr-Commit-Position: refs/heads/master@{#66617}
-
Ng Zhi An authored
Implement f64x2, i64x2, i8x16 splats on arm and arm64. Bug: v8:9909 Change-Id: I41f635ae5c6f025ece7f6445a58fbad1ad678fbd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087694Reviewed-by:
-
Zhao Jiazhong authored
Port 820faa6e https://crrev.com/c/2056468 Original Commit Message: The arm/arm64 simulators debugger has a command "mem" that prints the content of the memory. It also prints a short summary for JS objects (SMI, Array, JSFunction, ...). That is very handy, but when trying to print incomplete initialized memory, it could raise an exception. It is useful to have a command that prints the content of the memory for non-initialized or bogus values without the risk of raising an exception. This CL adds the command "dump". Change-Id: If8c96d7bac4a484c2a4fee9d192a29ea2696580a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089224Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66615}
-
Milad Farazmand authored
Port fd735e84 R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I8a46492241be9686da2220cb99162c9610962b5c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091212Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66614}
-
Andreas Haas authored
Prefixed opcodes do not get written correctly in code comments in Liftoff. The reason is that only one byte is interpreted as the opcode, but prefixed opcodes take two bytes. This CL loads the second byte if necessary. The change could be done in function-body-decoder-impl.h, but that could lead to performance regressions: it is a hot code path, and the change here is just for debugging. R=clemensb@chromium.org Bug: v8:10155 Change-Id: I2282c068c81b5b1e2e2ed9757f4e77687d1d4ede Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091467Reviewed-by:
-
Pierre Langlois authored
Comments on this reservation indicate it may hold either only code pages or code and data pages if pointer compression is enabled. But in fact it only holds the reservation for code pages. Change-Id: Ic007fcadf881153b69dce51db561777cc52685bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091465Reviewed-by:
-
Clemens Backes authored
The test started failing (sometimes flaking) on an unrelated CL. R=gsathya@chromium.org Bug: v8:10307 Change-Id: If198c2cf518f7a36e54614307462272774d9e48e No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091466Reviewed-by:
-
Andreas Haas authored
This CL fixes a special case where a WasmExportedFunction is passed to the WebAssembly.Function constructor. This is a case that was not yet implemented in V8, and which is also not specified in the proposal yet. With this CL we do a signature check of the provided function. If it matches, the function itself is returned. Otherwise a TypeError is thrown. I filed an issue: https://github.com/WebAssembly/js-types/issues/13 R=jkummerow@chromium.org Bug: chromium:1057534 Change-Id: Ib09d1ba18abaa6a8dd451aa747fd26c03d927413 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084813 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#66610}
-
Zhao Jiazhong authored
Port 7ad6b04e https://crrev.com/c/2080362 Change-Id: Iac305bf76c5a602bd238310fed0828e5ea95cd0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084323Reviewed-by:
-
Vitaly Buka authored
Bug: chromium:1055312, chromium:977230 Change-Id: I2ee8776b5118b07e414a1e88e43cc42ab82ecc64 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090982Reviewed-by:
-
Andreas Haas authored
All other simple C functions take a pointer to a stack slot which contains the actual parameters, whereas the memory_copy_wrapper takes three parameters. This makes the code generation from Liftoff more difficult. This CL changes the signature of memory_copy_wrapper to match the signature of other simple C functions. As MemoryCopy and MemoryInit are already implemented with C calls, this change should not make a big difference in terms of performance. Simpler and smaller Liftoff code may have more effect on performance. If this assumption turns out wrong, we can change it in the future. R=clemensb@chromium.org Bug: v8:10281 Change-Id: I39e0ea00fcb22b4e84e612fe58eb4642856b72c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078576 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
-
Ulan Degenbaev authored
This adds two new histograms: - V8.MeasureMemoryDelayMilliseconds measures how long it takes to serve a memory measurement request - V8.GCFinalizeMCMeasureMemory is a variant of the existing GC pause histogram that used when GC runs in memory measurement mode. Additionally this CL lowers the maximum measurement delay to 10 seconds. Bug: chromium:1049093 Change-Id: I97cbf443da514a69d6cf8c1d74d2757098e60acd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089937Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66606}
-
Milad Farazmand authored
Change-Id: Id5d6d1b2b6c06a2c4d1712bfa281bce18fb1320a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2090533Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/fa4450f..e393474 Rolling v8/third_party/aemu-linux-x64: hvClQbzFhJApEEpHpfc8UqpDdzLK0eabIbmpPlfODp8C..7YlCgase5GlIanqHn-nZClSlZ5kQETJyVUYRF7Jjy6UC Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f6edc90..b3bfbaa Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/fe6f752..ee8be8a Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/d548cda..101bca1 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I5ab721e9e72c0f7bae5790dbde73478c6ba78d61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089726Reviewed-by:
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: I8dc5d0143d90ecad6766c686af2d3f0f8ea89c16 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2067631Reviewed-by:
-
Ng Zhi An authored
Bug: v8:10180 Change-Id: If8dd729739854ee0bc08bf71100f48de6a0437b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2084321Reviewed-by:
-
