- 18 Feb, 2019 21 commits
-
-
Tobias Tebbi authored
This addresses the JSTests/Array/OptFastForEach regression, which ends up spending a lot of time in the ToString builtin. Bug: chromium:932919 Change-Id: I53cfdc61841bf10a669e54c3fdc009ead295782b Reviewed-on: https://chromium-review.googlesource.com/c/1477068Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59664}
-
Tobias Tebbi authored
This should recover the microbenchmark performance-regressions. Bug: chromium:932919 Change-Id: I00e2345428c8730035dc1164278006d687364de7 Reviewed-on: https://chromium-review.googlesource.com/c/1477063Reviewed-by:
-
Farazmand authored
Change-Id: Ic1f112ff47040024bc416a43867ddff08d51246c Reviewed-on: https://chromium-review.googlesource.com/c/1475333Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#59662}
-
tzik authored
Several parameter names of PromiseBuiltinsAssembler methods do not match to its definition, which confuses readers of the code. Change-Id: I8a43dd71b5a8d203cd040d754f8e650ecb203b82 Reviewed-on: https://chromium-review.googlesource.com/c/1476880Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Taiju Tsuiki <tzik@chromium.org> Cr-Commit-Position: refs/heads/master@{#59661}
-
Tamer Tas authored
Progress indicator calculates the percentage using the estimated amount of tests. When base tests produce more tests or when testrunner filters some tests, the percentage terminates over 100% or under it. This CL adds an informative message about how the percentage behaves. R=machenbach@chromium.org CC=yangguo@chromium.org,sergiyb@chromium.org Bug: v8:8728 Change-Id: I91cafd2579ea1894ac347ff7483c307cd46c545d Reviewed-on: https://chromium-review.googlesource.com/c/1477056Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Tamer Tas <tmrts@chromium.org> Cr-Commit-Position: refs/heads/master@{#59660}
-
Maciej Goszczycki authored
Change-Id: I25a2299e5e261cc125c7ff0e1acdeddbd7f664ff Reviewed-on: https://chromium-review.googlesource.com/c/1475753Reviewed-by:
Dan Elphick <delphick@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#59659}
-
Ulan Degenbaev authored
Bug: chromium:933107 Change-Id: Ie3a485447f96228d5c8d7fc169c9aabf8ccf6599 Reviewed-on: https://chromium-review.googlesource.com/c/1477057Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59658}
-
Mike Stanton authored
Reason for revert/reland: UBSan complained of unaligned reads. To improve the Torque debugging experience, we can add source positions for each line. This information is carried through the generated CSA code (in <output directory>/gen/torque-generated/*.cc) and embedded as SourcePositions in the Code object. At snapshot time, these SourcePositions are stripped from the Code object and turned into platform-appropriate line number debug information. At this time on Linux, you'll need to build with "is_clang=false" in order to use GCC, because crucial steps are missing in Clang's ability to convey the information into the binary successfully. This CL also introduces a flag to control the existing source information in CSA code. --enable-source-at-csa-bind is now set to false by default because it's a bit confusing to "hop" between source lines in .TQ files and in .CC files. I expect to continue making adjustments there, as I want to provide helpful debugging aids at the CSA level as well as the Torque level. The current configuration prioritizes Torque. TBR=tebbi@chromium.org Bug: v8:8418 Change-Id: Idb80467d3679ec2361386fe9b67597b93d7f72cf Reviewed-on: https://chromium-review.googlesource.com/c/1475763Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#59657}
-
Tobias Tebbi authored
To recover the performance regressions of FixedArray bounds-checks by default, disable bounds checks in the hot loops of ArrayIndexOf. Bug: chromium:932919 Change-Id: I977f063f6cb200a342e72a6361d56f945c442aec Reviewed-on: https://chromium-review.googlesource.com/c/1477059Reviewed-by:
-
Santiago Aboy Solanes authored
Also adding LoadTaggedPointerField and LoadAnyTaggedField that were missed on previous CLs. Similar to X64's CL: https://chromium-review.googlesource.com/c/v8/v8/+/1460953 Bug: v8:7703 Change-Id: I9c917aadace65d45204c3360aeeb7e9ece296e70 Reviewed-on: https://chromium-review.googlesource.com/c/1475474Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#59655}
-
Jakob Gruber authored
Correctness fuzzers need the global object to have a consistent shape across build configs. Bug: chromium:932877,chromium:932656,v8:7777 Change-Id: Id4e1251e50965b822bc4ef36c5ae2777864273d5 Reviewed-on: https://chromium-review.googlesource.com/c/1475768Reviewed-by:
-
Simon Zünd authored
This CL changes Array#sort to work roughly like: 1) Call [[Get]] on the receiver in [0, length) and store to FA 2) Use the existing TimSort to sort that FA 3) Call [[Set]] on the receiver in [0, length) using the result This has the advantage that we no longer need different fast-paths for the sorting algorithm itself, only for step 1 and 3. This results in a code size reduction of ~2650 bytes. This CL does not include optimizations that elides step 1 or 3. Change-Id: I7f2e35067a6ec356add8b0c50b160d76813c536d Reviewed-on: https://chromium-review.googlesource.com/c/1458237 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by: -
Mythri authored
These tests were timing out because we used to miss to runtime when storing keyed properties in lite mode. Now, the store ICs are updated to use fast path when possible even with lite mode. So, these should no longer timeout Bug: v8:8293 Change-Id: I63481768cc7d12c25c7f1a20ed1fa097979f2c50 Reviewed-on: https://chromium-review.googlesource.com/c/1475754Reviewed-by:
-
Simon Zünd authored
This CL changes "CaptureCurrentStackTrace" to use the FrameArrayBuilder. This way, simple and detailed stack traces use the same mechanism to capture stack traces. The stack trace API is implemented using the previously introduced StackTraceFrame class, which uses FrameArray as a backing store and can lazily initialize StackFrameInfo objects. R=jgruber@chromium.org, yangguo@chromium.org Bug: v8:8742 Change-Id: I716a9baa33d9ca1d2ef41a73fba26234a03b045b Reviewed-on: https://chromium-review.googlesource.com/c/1469822 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
-
Maya Lekova authored
Bug: chromium:931664 R=neis@chromium.org Change-Id: I4ad8e79b9b64898034d72264e968fc0cd01909b9 Reviewed-on: https://chromium-review.googlesource.com/c/1477050 Commit-Queue: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#59650}
-
Daniel Clifford authored
In the process, cleanup the StoreFixedArray* operators and change most FixedArray element accesses so that they explicitly use the '.objects' and '.floats' fields. Bug: v8:7793 Change-Id: I3e45a9b7536ec76e1413b7e508d79a56b37604ff Reviewed-on: https://chromium-review.googlesource.com/c/1460948 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59649}
-
Andrew Comminos authored
Signal a condition variable when profiling thread shutdown should occur, waking up a profiling thread that's currently waiting for the next tick. Mitigates the case where if a high sample interval is specified (e.g. 60s), the main thread is blocked until the next sample occurs due to a Sleep() call. Bug: v8:8843 Change-Id: Ied6b0bfb5c47a072ade17870911b961f5091f613 Reviewed-on: https://chromium-review.googlesource.com/c/1470953 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Alexei Filippov <alph@chromium.org> Cr-Commit-Position: refs/heads/master@{#59648}
-
Ulan Degenbaev authored
This replaces Heap::InNewSpace with Heap::InYoungGeneration and fixes tests that are sensitive to page size. Bug: chromium:852420 Change-Id: I32b1eafb45813ea3bdcbda075f9e6156aaf4c5e3 Reviewed-on: https://chromium-review.googlesource.com/c/1475766Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59647}
-
Ulan Degenbaev authored
The page flags of a large object promoted during scavenge are not updated until the finalization of the scavenge. Thus during slots recording they still indicate that the large object is in the from space. The MarkCompactCollector::RecordSlot bails out for object in young generation, which results in missing old-to-old slot. The fix is to insert the slot directly to the remembered set. Bug: chromium:852420 Change-Id: Ib3d62e6d939191411729dbc2eb16b89a171a1e80 Reviewed-on: https://chromium-review.googlesource.com/c/1475765Reviewed-by:
-
Jakob Gruber authored
This reverts commit c9ef0405. Reason for revert: https://crbug.com/932034 Original change's description: > [builtins]: Optimize CreateTypedArray to use element size log 2 for calculations. > > TypedArrayElementsInfo now represents an element's size as a log 2 and typed as > uintptr. This simplifies and speeds up (avoids possible HeapNumber allocations) a > number of calculations: > > - Number of Elements (length) -> Byte Length - is now a WordShl > - Byte Length -> Number of Elements (length) - is now a WordShr > - Testing alignment (byte offset or length) - is now a WordAnd > > These element/byte length related calculations are encapsulated in > TypedArrayElementsInfo as struct methods. > > This reduces the size of CreateTypedArray by 2.125 KB (24%) on Mac x64.release: > - Before: 9,088 > - After: 6,896 > > This improves the performance of the following microbencmarks > - TypedArrays-ConstructWithBuffer: ~87% > - TypedArrays-SubarrayNoSpecies: ~28% > > Bug: v8:7161 > Change-Id: I2239fd0e0af9d3ad55cd52318088d3c7c913ae44 > Reviewed-on: https://chromium-review.googlesource.com/c/1456299 > Commit-Queue: Peter Wong <peter.wm.wong@gmail.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59531} TBR=peter.wm.wong@gmail.com,jgruber@chromium.org,petermarshall@chromium.org,szuend@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7161, chromium:932034 Change-Id: I3da95447ce34f84d01629d2791868f3adcdfb387 Reviewed-on: https://chromium-review.googlesource.com/c/1475764 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Jon Kunkee authored
In the current version of the MSVC toolchain, it seems that the compiler finds a near-match for the FlushInstructionCache call in v8::internal::, so instead of looking in other namespaces for matching overrides it emits this error: C2660: 'v8::internal::FlushInstructionCache': function does not take 3 arguments This change works around this by explicitly stating the expected namespace. Bug: chromium:927113 Change-Id: Ie39d6fdd458646fc86a4a2b16a93d6888ef1a5ae Reviewed-on: https://chromium-review.googlesource.com/c/1462260Reviewed-by:
-
- 16 Feb, 2019 2 commits
-
-
Andrey Kosyakov authored
DevTools protocol is not supposed to carry structurally invalid utf8 as string payload. Bug: chromium:929862 Change-Id: I701eeb553e6bf22d887947dcd9f4b29af7a43e2b Reviewed-on: https://chromium-review.googlesource.com/c/1475665Reviewed-by:
Pavel Feldman <pfeldman@chromium.org> Reviewed-by:
-
Frank Tang authored
Bug: v8:7834 Change-Id: I54122c378ad79bca27b3f1258a18a1a04d444273 Reviewed-on: https://chromium-review.googlesource.com/c/1474551Reviewed-by:
Caitlin Potter <caitp@igalia.com> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#59642}
-
- 15 Feb, 2019 17 commits
-
-
Sigurd Schneider authored
This is a step towards making gn check pass on v8 without third_party Change-Id: I6a256d65159695e2ba2a5d44c0437cac9b28aa3a Bug: v8:8834, v8:8855 Reviewed-on: https://chromium-review.googlesource.com/c/1475460Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59641}
-
Sigurd Schneider authored
Change-Id: I43efddcbd381be3d61deb94515842e582069ffb9 Bug: v8:8834 Reviewed-on: https://chromium-review.googlesource.com/c/1475465Reviewed-by:
-
Matt Gardner authored
This CL fixes a perf regression caused by: https://chromium-review.googlesource.com/c/v8/v8/+/1465182 A deopt loop was occurring for HOLEY_DOUBLE_ELEMENTS arrays when hole elements were used as anything other than a float64, such as a return value or storing into a non-double array. bug: chromium:932082 Change-Id: I27290e9669d80050027e76cb62b0f67b51788d0f Reviewed-on: https://chromium-review.googlesource.com/c/1474560Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Mike Stanton authored
Just a straightforward port. bug:v8:7672 Change-Id: Ie2511cda23d7b61775e3619d61dde43c8ae48c7f Reviewed-on: https://chromium-review.googlesource.com/c/1425916 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by:
-
Michael Stanton authored
This reverts commit 0a24e67a. Reason for revert: Broke Linux 64 UBSan build with unaligned read in the snapshot. Will investigate... Original change's description: > [Torque] Add source positions for Torque files > > To improve the Torque debugging experience, we can add source positions > for each line. This information is carried through the generated > CSA code (in <output directory>/gen/torque-generated/*.cc) and > embedded as SourcePositions in the Code object. > > At snapshot time, these SourcePositions are stripped from the Code > object and turned into platform-appropriate line number debug > information. > > At this time on Linux, you'll need to build with "is_clang=false" > in order to use GCC, because crucial steps are missing in Clang's > ability to convey the information into the binary successfully. > > This CL also introduces a flag to control the existing source > information in CSA code. --enable-source-at-csa-bind is now set > to false by default because it's a bit confusing to "hop" between > source lines in .TQ files and in .CC files. I expect to continue > making adjustments there, as I want to provide helpful > debugging aids at the CSA level as well as the Torque level. > The current configuration prioritizes Torque. > > A detailed guide on usage to follow (also on v8.dev). > > Bug: v8:8418 > Change-Id: Ib4226877ce4cae451bb4d0c546927e89f4e66b58 > Reviewed-on: https://chromium-review.googlesource.com/c/1475473 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59636} TBR=mvstanton@chromium.org,tebbi@chromium.org Change-Id: I4ccf94dfdb8b2ba238a60db9ecc8e3ceebef2699 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8418 Reviewed-on: https://chromium-review.googlesource.com/c/1475757Reviewed-by:
-
Mike Stanton authored
To improve the Torque debugging experience, we can add source positions for each line. This information is carried through the generated CSA code (in <output directory>/gen/torque-generated/*.cc) and embedded as SourcePositions in the Code object. At snapshot time, these SourcePositions are stripped from the Code object and turned into platform-appropriate line number debug information. At this time on Linux, you'll need to build with "is_clang=false" in order to use GCC, because crucial steps are missing in Clang's ability to convey the information into the binary successfully. This CL also introduces a flag to control the existing source information in CSA code. --enable-source-at-csa-bind is now set to false by default because it's a bit confusing to "hop" between source lines in .TQ files and in .CC files. I expect to continue making adjustments there, as I want to provide helpful debugging aids at the CSA level as well as the Torque level. The current configuration prioritizes Torque. A detailed guide on usage to follow (also on v8.dev). Bug: v8:8418 Change-Id: Ib4226877ce4cae451bb4d0c546927e89f4e66b58 Reviewed-on: https://chromium-review.googlesource.com/c/1475473Reviewed-by:
-
Junliang Yan authored
Change-Id: I86b8c455a25896d9c4ce92901c23ec5971edde43 Reviewed-on: https://chromium-review.googlesource.com/c/1475332Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#59635}
-
Igor Sheludko authored
... and verify that upper 32-bits of on-heap tagged values contain zero. This CL also removes scratch register argument from decompression snippets. Bug: v8:7703 Change-Id: Ia69d1c5de423c465735719ed07d92df03d9db97c Reviewed-on: https://chromium-review.googlesource.com/c/1460953 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Junliang Yan authored
Port c142e0a2 Original Commit Message: Refactor the CallApiCallback builtin to - pass the context as with other stubs, and - pass holder and call data in registers. This avoids having to place holder and call data onto the stack, and thus makes it possible to easily call the CallApiCallback builtin from other builtins while just forwarding the (stack) arguments. The idea is to use this in the future to optimize the general case of calling into any API method via a FunctionTemplateInfo and doing appropriate security and/or interface checks upfront as necessary (eventually making the HandleApiCall C++ builtin obsolete at some point). R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com BUG= LOG=N Change-Id: I94583d1e0fa7c4696e628c363fefe273c8c5cab9 Reviewed-on: https://chromium-review.googlesource.com/c/1475331Reviewed-by:
-
Tobias Tebbi authored
This is a reland of a6b95a6a In addition to UBSan, also ASAN needs optimizations. So this CL doesn't disable optimizations for all sanitizer builds. Original change's description: > Reland "[build] disable C++ optimization for mksnapshot code." > > This is a reland of cee2f772 > > Original change's description: > > [build] disable C++ optimization for mksnapshot code. > > > > By disabling C++ optimizations for code that's only run in mksnapshot, > > that is, CSA and Torque-generated code, we can save compile time. > > I observed up to 2x improvements of compile time for some files, > > while the mksnapshot time did not increase significantly. > > > > Bug: v8:7629 > > Change-Id: I96be2966611b2471b68023e0dd9e351d94f0013c > > Reviewed-on: https://chromium-review.googlesource.com/c/1460941 > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#59585} > > Bug: v8:7629 > Change-Id: I8330f93173ab3d7b400e15ea4935bbe8256b250f > Reviewed-on: https://chromium-review.googlesource.com/c/1473292 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59606} Bug: v8:7629 Change-Id: I42175c472d8e41345573df81645dfe3accc9d8c4 Reviewed-on: https://chromium-review.googlesource.com/c/1475396Reviewed-by:
-
Tobias Tebbi authored
To address previously observed regressions, this CL also introduces unchecked FixedArray accessors and uses them to access collections. Bug: v8:8029 Change-Id: I6bcd8db2b89b29b7acb3b8431ec5405b737bcef2 Reviewed-on: https://chromium-review.googlesource.com/c/1473033 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#59631}
-
Sigurd Schneider authored
This allows removing some v8.h includes in blink, and replacing them by forward declarations. Change-Id: I3f55669f551e29038918f54a26a0ab032ffb252a Bug: v8:8788 Reviewed-on: https://chromium-review.googlesource.com/c/1475394Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59630}
-
Farazmand authored
Port a4b19dcc Original Commit Message: This switches from copying entire runtime stubs into each module to only having small jump table slots in each module that act as a trampoline to the actual embedded builtin representing the runtime stub. This reduces the memory footprint of modules. R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com BUG= LOG=N Change-Id: Ibbe5fdf4d926b45582748ae8b15eb316107409dc Reviewed-on: https://chromium-review.googlesource.com/c/1470455Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#59629}
-
Toon Verwaest authored
Escaped contextual keywords are simply valid identifiers if they do not occur in the context where they are a keyword. Escape sequences of the form \uNNNN or \u{NNNNNN} must be consumed as part of the identifier. If such escaped contextual keywords do occur in a context where they are a keyword, they are a syntax error. In that case we manually check locally whether they are escaped. Bug: v8:6543, v8:6541 Change-Id: I7e1557963883e722310b9078d7d7636ec94aa603 Reviewed-on: https://chromium-review.googlesource.com/c/1473293Reviewed-by:Leszek Swirski <leszeks@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#59628}
-
Peter Marshall authored
Also drive-by cleanup the TestMemoryAllocatorScope class so that it takes ownership of the old allocator while it holds onto it, and so that the MemoryAllocator for testing is constructed inside the scope rather than passed into it. This means users don't need to explicitly call TearDown() and delete the allocator as the scope does it for them. Change-Id: Id7da3c074618a376d2edfe3385bb185ba8287cea Reviewed-on: https://chromium-review.googlesource.com/c/1392194 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
-
Leszek Swirski authored
In addition to the previous change enabling forced FunctionDeclaration allocation when block code coverage is enabled, enable it now for all (non-best-effort) code coverage by reading off the coverage mode from the isolate (rather than relying on the presence of a source range map). Bug: chromium:927464 Change-Id: I26f86c9fbebc0df52d5cdeff3ca1095215a6d912 Reviewed-on: https://chromium-review.googlesource.com/c/1456041 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Tobias Tebbi authored
This changes the behavior of overload resolution to not consider if the call happens in a branching context (i.e., with implicit True and False labels from a conditional operator or statement). That way, it is not possible to get different behavior accidentially by using an operator in the wrong context. Instead, there will be a compile error because the call happened in a non-branching context, or because it is ambiguous without this information. The test doesn't perfectly fit the issue (impossible until we have negative tests), but instead tests that equality on HeapNumber's works in boolean contexts, which is something Peter fixed already in https://crrev.com/c/1432596. Bug: v8:8737 v8:7793 Change-Id: I08a3801891587aac705dc93b1c65b0c6cf164107 Reviewed-on: https://chromium-review.googlesource.com/c/1456093Reviewed-by:
Peter Wong <peter.wm.wong@gmail.com> Reviewed-by:
Daniel Clifford <danno@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#59625}
-
