- 27 May, 2020 26 commits
-
-
George Wort authored
Display register allocation live ranges alongside sequences in turbolizer. The existing --trace-turbo flag now also outputs the register allocation data as part of the json file alongside the instruction sequence data that is already produced before and after register allocation is performed. This data includes live range intervals for each virtual and fixed register and the state of their assignments. This json data can now be displayed in turbolizer alongside the instruction sequences. The information is presented as a grid, with each grid cell representing a LifeTimePosition of a certain virtual register, determined by the column and row indices respectively. Each LifeTimePosition is shown to be part of an instruction id which itself is shown to be part of a block id. Each interval is shown as a coloured rectangle positioned over the relevant cells, and displaying text to indicate the state of their assignment. The Resizer object has been extended to allow the grid's html panel to be varied in size in the same manner that the left and right panels can be. The size of the grid itself must also be adjusted whenever the div container changes size. The RangeView class is introduced and is created and held by the single SequenceView object used to display the InstructionSequence data before and after register allocation. A checkbox allows the user to show/hide the range view, this is disabled when register allocation data is not provided or more than 249 instructions are in the sequence. The latter being required due to the css grid-row-col limit of 1000 alond with helping alleviate performance issues. The SequenceView object tracks the phase index currently selected as well as whether or not it is currently being shown. This ensures that the RangeView is not hidden and shown when switching between before and after register allocation, allowing for a smoother transition between the two. The scroll position is also saved and restored for convenience. The data about the instruction sequence required for the display is held by the RangeView object and reset whenever a new instruction sequence is shown. The grid div must sync its scroll with the headers and row labels so as to ensure a consistent view. The register allocation data is extracted from the json, with each register row showing all intervals within the relevant ranges. When the view is switched between before and after register allocation, the relevant intervals are swapped in. Bug: v8:7327 Notry: true Change-Id: I183535a2410a7d663382f387199885250fb98691 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184232Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68019}
-
Seth Brenith authored
This is a partial reland of https://crrev.com/c/v8/v8/+/2199640 . It allows scoped lookups to not crash during CompileCurrentAst, fixes the formatting in an error message, and includes an extra line for convenience when generating macros for bitfields. Change-Id: I7ed9f7d76b3ce5e2cc0f2580d7ba1953da340ae8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216301Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#68018}
-
Bill Budge authored
- Moves some CSA macros back into the global namespace, and uses Torque's new global namespace feature to disambiguate the calls. Bug: v8:9891 Change-Id: I6a94ee04daed1e6a8f672b2eaa12161ab998f14c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216932Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#68017}
-
Santiago Aboy Solanes authored
Bug: v8:9708, v8:6949 Change-Id: I80fa9b813d6ce80e52a42a02b42f8c98e2f3f75f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212267 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68016}
-
Michael Lippautz authored
Add docs for: - cppgc namespace (to have doxygen generate the namespace doc) - Heap - LivenessBroker Bug: chromium:1056170 Change-Id: I5e4664458b7209f4adebb4d5e7b5119c341f59a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214834 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#68015}
-
Marja Hölttä authored
All strings in the internalized string list now have them. Bug: v8:10506 Change-Id: I68feb34d0dc424465a53ac73a5d6b5297e29dd00 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218032 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68014}
-
Milad Farazmand authored
Port 0f624aae R=fanchen.kong@intel.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I4f2aebe38e05bb6f92da96a3f7aea1cc4c4cbf2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215258Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#68013}
-
Georg Neis authored
Change-Id: I15aefc6ecfc6a8d65b6bd74af9e2331cdc49fdc4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202986 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#68012}
-
Victor Gomes authored
Change-Id: Ifadaffdd7e846f51accc51cc14898ddf05c98f88 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214836 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68011}
-
Santiago Aboy Solanes authored
Bug: v8:9708, v8:6949 Change-Id: Id3eeab803d50c95d53eef1806859b85e857c4d2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212266Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68010}
-
Santiago Aboy Solanes authored
INTPTR_PARAMETERS is deduced from reg, which is an TNode<IntPtrT>. Bug: v8:9708, v8:6949 Change-Id: I84c4e5803602ecc2d9284bce46409a384e93a035 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212265Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68009}
-
Santiago Aboy Solanes authored
Since now all phases have the same order (or the reverse) we can share only one container that would specify the traversal order. We still need a queue that will be used for revisiting purposes in PROPAGATE and RETYPE. Bug: v8:10424 Change-Id: Iab1e3c3cf6ffd342240d43be3b8ac77812aff211 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154201 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#68008}
-
Santiago Aboy Solanes authored
We now have one initial phase (before PROPAGATE) that generates the traversal that the subphases are going to take. Generates post-order starting from End for RETYPE and LOWER, and the reverse for PROPAGATE. As a note, LOWER could use either PO or RPO. Bug: v8:10424 Change-Id: I7435d681aba012b4f5e5ecd971bfa1d88bfb8b3a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154785Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68007}
-
Santiago Aboy Solanes authored
Also remove a version that was only used once. Bug: v8:9708, v8:6949 Change-Id: Ifd65af3866a3740d8da6d4501445b25a48d7219a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212264Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#68006}
-
Jakob Gruber authored
The `slot` parameter is expected to be a UintPtr. Bug: v8:8888 Change-Id: Ia1137cd5af3d3aa0b00e9bf194661067c37332b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215047 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#68005}
-
Jakob Gruber authored
This CL brings unary op assembler structure closer to that of binary ops assemblers: - Decrement, Increment, Negate call into UnaryOpWithFeedback, - which takes lambdas specifying smi, float, and bigint logic. - BitwiseNot is different in that it still dispatches using TaggedToWOrd32OrBigIntWithFeedback. - These methods are all implemented in the (hidden) UnaryOpAssemblerImpl class. - The header only exposes UnaryOpAssembler with the bare minimum of API. The last point is the remaining major divergence from binary op assemblers. I just like how this avoids useless implementation details in the header. Bug: v8:8888 Change-Id: I0ac4695483950356885301234d58c1900904aa92 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214830 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#68004}
-
Leszek Swirski authored
Object shapes or sizes shouldn't change during the string fixup, but we're seeing crashes that indicate that they might do anyway, so add some more exhaustive checking to make sure they don't. Bug: chromium:1086478 Change-Id: I36d41e036a32d8dd072000d900ba1900343d4608 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214839 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#68003}
-
Maya Lekova authored
Change-Id: Ic874265567ed752c314f962a5da7ce84353a4336 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214835 Auto-Submit: Maya Lekova <mslekova@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#68002}
-
Kong, Fanchen authored
Bug: v8:9909 Change-Id: I6224ce9ae3ac814ee33be71a67f1df02a398e0c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208686 Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Reviewed-by: Zhi An Ng <zhin@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68001}
-
Gilang Mentari Hamidy authored
If the return_count is zero, the Generate will be called twice. The recent update in Generate function already handle the case inside the Generate function overload. Change-Id: I49e0ee4a0824db60f157ea288ae6d28978c42db5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215816Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#68000}
-
Joyee Cheung authored
This is a reland of 8374feed. Fixed rehashing of global proxy keys by creating its identity hash early, before the deserialization of the context snapshot. Original change's description: > [snapshot] rehash JSMap and JSSet during deserialization > > To rehash JSMap and JSSet, we simply replace the backing store > with a new one created with the new hash. > > Bug: v8:9187 > Change-Id: I90c25b18b33b7bc2b6ffe1b89fe17aa5f978b517 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2143983 > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67663} Bug: v8:9187, v8:10523 Change-Id: I7a0319b1d10ff07644de902fec43e7c2b1dd8da9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212085Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/master@{#67999}
-
Arnaud Robin authored
Added --trace-wasm flag which prints function entry in wasm. R=clemensb@chromium.org Bug: v8:10559 Change-Id: I049efeadb0149f4f58ce34a29fd53fbf5688bd4b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215052 Commit-Queue: Arnaud Robin <arobin@google.com> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#67998}
-
Benedikt Meurer authored
Previously both the length and the endColumn for Wasm scripts were reported as 0, and that was sort of okayish, since the front-end was ignoring both of these fields in case of Wasm, and was applying special cases. But these special casing lead to some subtle bugs, and this is the first step towards a more uniform treatment. Source positions for Wasm are in terms of the bytecode, and the column field contains the bytecode offset here, while the line number field is always 0. Hence we send 0 for both startLine and endLine as before, but endColumn now corresponds to the bytecode size. Bug: chromium:1056632 Change-Id: Ia8a9cfe454ed250b87a524f5cbcbbbe242205db6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215817 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#67997}
-
Manos Koukoutos authored
Bug: v8:7748 Change-Id: I4ae500548e7ab09f5bd037563af5c057751197bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215049Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#67996}
-
Iain Ireland authored
To ensure that regexp syntax errors are reported as early errors, SpiderMonkey calls ParseRegExp at parse time to validate that the regexp parses properly. This does not require the allocation of named capture information. We have a project underway to completely eliminate the allocation of GC things at parse time, which will require us to suppress the allocation of named capture information (or else jump through hoops to implement FixedArray as a non-GC thing). We can work around this in our shim layer -- for example, by setting a flag on the Factory shim that causes us to allocate dummy objects -- but it's much simpler to add an option to ParseRegExp. (Note: V8 currently does not treat regexp syntax errors as early errors. See https://bugs.chromium.org/p/v8/issues/detail?id=896.) Bug: v8:10406 Change-Id: Ib5f0613a54509146e00f90cf61bda4bf03b03859 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207813 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67995}
-
Manos Koukoutos authored
Motivation: In the wasm-gc proposal, structs and arrays are allowed to store elements of packed types i8 and i16. Changes: - Add i8 and i16 to ValueType. - Fix all case switches to handle the new cases. - Add a couple helper methods to ValueType and improve the implementation/usage of a couple more. Bug: v8:7748 Change-Id: I527cfe5acf5d877fc38e4212174ba9f9de5c40ad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215046Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/master@{#67994}
-
- 26 May, 2020 14 commits
-
-
Ng Zhi An authored
This removes the post-mvp flag for bitmask, since it was accepted into the proposal, see https://github.com/WebAssembly/simd/pull/201. Bug: v8:10308 Change-Id: I4ced43a6484660125d773bc9de46bdea9f72b13b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216532Reviewed-by: Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67993}
-
Milad Farazmand authored
Change-Id: Ife10d7c8634cbd6b542dc522a49124f790f51921 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2216434Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#67992}
-
Seth Brenith authored
We can do a good job of optimizing Torque expressions that load and check multiple bitfields from a bitfield struct, but only if those expressions are written using the binary `&` operator as opposed to the logical `&&`. This change adds a lint rule to detect some simple cases where we should clearly prefer `&` to `&&`. Bug: v8:7793 Change-Id: Id996a7971cff8f7f83198075a172170d9c7d42e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207666 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67991}
-
Ng Zhi An authored
Making them private was a way to hide the constructor, we can explicitly delete them, which give a better compilation error message as well. Also see: https://stackoverflow.com/q/55205874 Bug: v8:10488 Change-Id: Iddc00b86e5481b90c20d9c68f1261f853ac8d5dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210778Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67990}
-
Ng Zhi An authored
See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-override.html for more on this warning. Bug: v8:10488 Change-Id: I904fa4fada2860938a32be9f0a84af091adc76ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211193Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67989}
-
Ng Zhi An authored
Making them private was a way to hide the constructor, we can explicitly delete them, which give a better compilation error message as well. Also see: https://stackoverflow.com/q/55205874 Bug: v8:10488 Change-Id: I9268f42b9367cc1af4d58e71e2033c254ed4cbf7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210777Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67988}
-
Ng Zhi An authored
See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-override.html for more on this warning. Bug: v8:10488 Change-Id: I872782060c22812c93eadf4f77ba75c058283b8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2210779 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67987}
-
Ng Zhi An authored
Bug: v8:9909 Change-Id: Ic3a13131e07487512161eec1bec0cdc33a0a3f63 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207664Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67986}
-
Ng Zhi An authored
See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-override.html for more on this warning. Bug: v8:10488 Change-Id: I78fdfb904ea94d9ae034b41cd43be8689a0096ea Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211188 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67985}
-
Daniel Clifford authored
There was a legacy place in map code that wasn't fully ported to use the strong, new SloppyArgumentsElements type because of code that used hard-coded constants. Bug: chromium:1086470 Change-Id: Ieba152e4bd92c89125f831949c2efb4f4219f95c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215059Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#67984}
-
Ng Zhi An authored
See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-override.html for more on this warning. Bug: v8:10488 Change-Id: Ia2bf5c1ec84dd4473d0e013ec3d22548b38a0578 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211190Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67983}
-
Ng Zhi An authored
Making them private was a way to hide them, we can explicitly delete them, which give a better compilation error message as well. Also see: https://stackoverflow.com/q/55205874 Bug: v8:10488 Change-Id: Ieffa05951aeefc0225f8fb84e756eb67353e57a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211184Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67982}
-
Seth Brenith authored
VisitWord32EqualImpl was checking for inputs of type kCompressedHeapConstant, but it can also sometimes have inputs of type kHeapConstant. In either case, we can check for whether to do a load from the roots array. This improves Octane score by about 3% (or about 1.5% if --no-opt is specified). Bug: v8:8948 Change-Id: Iab6c0b1dacd96c74e4cfb54c772aa92e5baf00ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2213081 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#67981}
-
Ng Zhi An authored
Making them private was a way to hide them, we can explicitly delete them, which give a better compilation error message as well. Also see: https://stackoverflow.com/q/55205874 Bug: v8:10488 Change-Id: I3f2b6881ae2252809c84fbd32ce0687e8328506e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211182Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#67980}
-