- 07 Jan, 2020 1 commit
-
-
Sigurd Schneider authored
This CL improves whitespace precision of coverage around try blocks; previously a small portion of whitespace could be reported as uncovered between try blocks and catch and/or finally blocks. Change-Id: I763ae3d15106c88f2278cf8893c12b0869a62528 Fixed: v8:10030 Bug: v8:10030 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962265Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#65593}
-
- 07 Nov, 2019 1 commit
-
-
Sigurd Schneider authored
In the presence of default arguments, the body of the function gets wrapped into another block. This caused our trailing-range-after-return optimization to not apply, because the wrapper block had no source range assigned. This CL correctly assignes a source range to that block, which allows already present code to handle it correctly. Note that this is not a real coverage bug; we've just been reporting whitespace as uncovered. We're fixing it for consistency. Originally reported on github.com/bcoe/c8/issues/66 Bug: v8:9952 Change-Id: Iab3905f558eb99126e0dad8072d03d0a312fdcd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903430 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64836}
-
- 16 Oct, 2019 1 commit
-
-
Sigurd Schneider authored
This fixes a bug where coverage for the inline script <script>function foo() {}<script> started to get deterministically reported as covered after crrev.com/c/1771776, while before it, we most of the time reported it as uncovered (depending on heap order of SFIs). The correct result is to report `foo` as uncovered as it is never called. The problem arose from the fact that v8:9212 needed to handle extra-wrappers around scripts correctly. Those wrappers have the same source range as the wrapped script and a call count of zero even if the wrapped script is executed. To filter them out, we previously determined nesting for identical source ranges by ascending call count. However, in the script case above, the script has call count one, while `foo` (which has the same source range) has call count zero. In this case, nesting is decreasing order of call counts. This CL is a minimal change that sorts SFIs which are top-level to the front, only then considers call counts in descending order. This preserves the behavior that node's extra wrappers are sorted to the front (and then filtered out by existing logic), but also ensures that for the example above, we report the script's coverage before the coverage for `foo`. Bug: v8:9857, v9:9212 Change-Id: Id224b0d8f12028b1f586ee5039e126bb5b8d8d36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863197Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#64307}
-
- 12 Sep, 2019 1 commit
-
-
Sigurd Schneider authored
Case statements have a list of statements associated with them, but are not blocks, and were hence not fixed-up correctly for code coverage. This CL also applies the fix-up to the "body" of case statements, in this way removing ranges reported as uncovered between the final break/return in a case and the next case (or end of function). Drive-by: Add optional pretty printing to code coverage test results. Change-Id: I5f4002d4e17b7253ed516d99f7c389ab2264be10 Bug: v8:9705 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1798426Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63719}
-
- 05 Sep, 2019 1 commit
-
-
Sigurd Schneider authored
Async functions were not correctly fixed up for code coverage, which caused an additional uncovered range to be reported between a return statement and the closing bracket. This CL adds code that detects such ranges, and removes them, similarly to how the ranges are removed for normal functions. The removal process is different, because the parser rewrites async functions to contain a try-catch handling promise rejection. Change-Id: I73b08d64be74d26c32f2f9652d027430d4671251 Bug: chromium:981313, v8:8381 Change-Id: I82a7f0c54d3a48609ef5255a7659d9557e163566 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782837Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63561}
-
- 16 May, 2019 1 commit
-
-
Jakob Gruber authored
Prior to this CL, call counts at function scope were taken from the FeedbackVector::invocation_count field. This had two major drawbacks: 1. for generator functions, these count the number of resumptions instead of the number of calls; and 2. the invocation count is not maintained in optimized code. The solution implemented here is to add a dedicated call counter at function scope which is incremented exactly once each time the function is called. A minor complication is that our coverage output format expects function-scope counts in the dedicated CoverageFunction object, and not as a CoverageBlock. Thus function-scope block counts are initially marked with magic positions, and later recognized and rewritten during processing. This CL thus fixes reported generator function call counts and enables optimizations in block coverage modes (more to come in a follow-up). Drive-by: Don't report functions with empty source ranges. Bug: v8:6000,v8:9148,v8:9212 Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng Change-Id: Idbe5edb35a595cf12b6649314738ac00efd173b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1613996 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61574}
-
- 28 Feb, 2019 1 commit
-
-
Benjamin authored
The SourceRangeAstVisitor has custom logic for blocks ending with a statement that has a continuation range. In these cases, the trailing continuation is removed which makes the reported coverage ranges a bit nicer. throw Error('foo') consists of an ExpressionStatement, with a Throw expression stored within the statement. The source range itself is stored with the Throw, not the statement. We now properly extract the correct AST node for trailing throw statements. R=jgruber@chromium.org, neis@chromium.org, yangguo@chromium.org Bug: v8:8691 Change-Id: Ibcbab79fbe54719a8993045040349c863b139011 Reviewed-on: https://chromium-review.googlesource.com/c/1480632 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59936}
-
- 05 Feb, 2019 1 commit
-
-
Leszek Swirski authored
Preserve coverage for unused functions by force marking them used when code coverage is enabled. Bug: chromium:927464 Change-Id: Ia973467d06f7268f4e98cc76d0bb98cc591e979c Reviewed-on: https://chromium-review.googlesource.com/c/1454717 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#59373}
-
- 21 Dec, 2018 1 commit
-
-
Jakob Gruber authored
This changes a few bits about how continuation counters are handled. It introduces a new mechanism that allows removal of a continuation range after it has been created. If coverage is enabled, we run a first post-processing pass on the AST immediately after parsing, which removes problematic continuation ranges in two situations: 1. nested continuation counters - only the outermost stays alive. 2. trailing continuation counters within a block-like structure are removed if the containing structure itself has a continuation. R=bmeurer@chromium.org, jgruber@chromium.org, yangguo@chromium.org Bug: v8:8381, v8:8539 Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3 Reviewed-on: https://chromium-review.googlesource.com/c/1339119Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#58443}
-
- 13 Dec, 2018 1 commit
-
-
Ross McIlroy authored
Also disables --stress-flush-bytecode on some mjsunit tests which fail when bytecode flushing is stressed due to test invariants. Bug=v8:8395 Change-Id: If627910214b3c266e7776340ba182829148e8289 Reviewed-on: https://chromium-review.googlesource.com/c/1372071Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#58230}
-
- 06 Dec, 2018 1 commit
-
-
tzik authored
This replaces Runtime_RunMicrotasks with Runtime_PerformMicrotaskCheckpoint. RunMicrotasks forcibly runs Microtasks even when the microtasks are suppressed, and may causes nested Microtasks in a problematic way. E.g. that confuses v8::MicrotasksScope::IsRunningMicrotasks() and GetEnteredOrMicrotaskContext(). OTOH, PerformMicrotaskCheckpoint() doesn't run cause the failure as it respects the microtask suppressions. As all existing tests don't call RunMicrotasks() in the suppressed situation (like Promise.resolve().then(()=>{%RunMicrotasks();})), this change should not affect to these tests. Change-Id: Ib043a0cc8e482e022d375084d65ea98a6f54ef3d Reviewed-on: https://chromium-review.googlesource.com/c/1360095Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Taiju Tsuiki <tzik@chromium.org> Cr-Commit-Position: refs/heads/master@{#58068}
-
- 10 Oct, 2018 2 commits
-
-
Jakob Gruber authored
Block coverage is based on a system of ranges that can either have both a start and end position, or only a start position (so-called singleton ranges). When formatting coverage information, singletons are expanded until the end of the immediate full parent range. E.g. in: {0, 10} // Full range. {5, -1} // Singleton range. the singleton range is expanded to {5, 10}. Singletons are produced mostly for continuation counters that track whether we execute past a specific language construct. Unfortunately, continuation counters can turn up in spots that confuse our post-processing. For example: if (true) { ... block1 ... } else { ... block2 ... } If block1 produces a continuation counter, it could end up with the same start position as the else-branch counter. Since we merge identical blocks, the else-branch could incorrectly end up with an execution count of one. We need to avoid merging such cases. A full range should always take precedence over a singleton range; a singleton range should never expand to completely fill a full range. An additional post-processing pass ensures this. Bug: v8:8237 Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf Reviewed-on: https://chromium-review.googlesource.com/c/1273095Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#56531}
-
Jakob Gruber authored
This reverts commit 471fef04. Reason for revert: A more general fix incoming at https://crrev.com/c/1273095. Original change's description: > [coverage] change block range to avoid ambiguity. > > 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/1254127 > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56347} TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:8237 Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834 Reviewed-on: https://chromium-review.googlesource.com/c/1273096Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#56513}
-
- 02 Oct, 2018 1 commit
-
-
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}
-
- 04 Apr, 2018 1 commit
-
-
jgruber authored
Before reporting coverage data, we attempt to reduce clutter by merging nested and consecutive ranges. Nested ranges are merged, if the child range has the same execution count as the parent range. Sibling ranges are merged, if one sibling begins where the other ends and execution counts are identical. This allowed an invalid transformation in which a range with an execution count of 1 would be merged into the parent change, but the sibling range with identical start and end points and a count of 0 would remain, effectively deleting the covered range. For example: {start: 0, end: 10, count: 1}, {start: 5, end: 8, count: 1}, // It's invalid to remove this. {start: 5, end: 8, count: 0} The fix is to separate the parent and sibling merge passes, and removing duplicate ranges in-between. Bug: chromium:827530 Change-Id: Ic35eae1d4a106746570ce9cb412ed6710ef6da53 Reviewed-on: https://chromium-review.googlesource.com/992114Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#52352}
-
- 12 Jan, 2018 1 commit
-
-
Adam Klein authored
It was shipped in Chrome 63. Bug: v8:5855 Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: Icc00b8300622d1c7b5662be8ac5e425b9781f666 Reviewed-on: https://chromium-review.googlesource.com/858381 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#50558}
-
- 12 Dec, 2017 1 commit
-
-
Benjamin authored
'else' was missing in coverage range, resulting in odd looking reports R=jgruber@chromium.org Bug: v8:7179 Change-Id: I377cc557d51075256da27febdc8ab5442ea04d27 Reviewed-on: https://chromium-review.googlesource.com/816736Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#50030}
-
- 24 Nov, 2017 1 commit
-
-
jgruber authored
This is a reland of 4d3bc552 Original change's description: > [coverage] add coverage for binary expressions > > Adds block-level coverage tracking for binary && and || > expressions. Introduces a BinaryOperation source-range > for tracking the operations themselves and an Expression > source-range, used for tracking NaryLogical expressions. > > This builds on work by jgruber@chromium.org in > the issue. > > TBR=marja@chromium.org > R=jgruber@chromium.org, rmcilroy@chromium.org > > Bug: v8:6660 > Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18 > Reviewed-on: https://chromium-review.googlesource.com/754564 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49304} Bug: v8:6660 Change-Id: I1c8571660d6c501d526886867bd841c49d5c44fd Reviewed-on: https://chromium-review.googlesource.com/778288Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#49613}
-
- 20 Nov, 2017 1 commit
-
-
jgruber authored
When collecting source ranges for conditionals (`a ? b : c`), include the '?' and ':' tokens in the then- and else ranges, respectively. Bug: v8:7098 Change-Id: I22315e2040c96c977e0b49e1fafe4228a6558471 Reviewed-on: https://chromium-review.googlesource.com/778321Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#49484}
-
- 17 Nov, 2017 1 commit
-
-
Jakob Gruber authored
This reverts commit 4d3bc552. Reason for revert: https://crbug.com/785778 Original change's description: > [coverage] add coverage for binary expressions > > Adds block-level coverage tracking for binary && and || > expressions. Introduces a BinaryOperation source-range > for tracking the operations themselves and an Expression > source-range, used for tracking NaryLogical expressions. > > This builds on work by jgruber@chromium.org in > the issue. > > TBR=marja@chromium.org > R=jgruber@chromium.org, rmcilroy@chromium.org > > Bug: v8:6660 > Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18 > Reviewed-on: https://chromium-review.googlesource.com/754564 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49304} TBR=rmcilroy@chromium.org,marja@chromium.org,jgruber@chromium.org,ben@npmjs.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6660 Change-Id: Ie017c528604b2e01400f527511413eaea5786198 Reviewed-on: https://chromium-review.googlesource.com/776768Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#49454}
-
- 10 Nov, 2017 1 commit
-
-
Benjamin authored
Adds block-level coverage tracking for binary && and || expressions. Introduces a BinaryOperation source-range for tracking the operations themselves and an Expression source-range, used for tracking NaryLogical expressions. This builds on work by jgruber@chromium.org in the issue. TBR=marja@chromium.org R=jgruber@chromium.org, rmcilroy@chromium.org Bug: v8:6660 Change-Id: I83a81f13a3514a734c06948b2d3e91138fb00e18 Reviewed-on: https://chromium-review.googlesource.com/754564 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#49304}
-
- 09 Nov, 2017 1 commit
-
-
jgruber authored
Move block coverage logic for TryCatchStatement and TryFinallyStatement nodes into builder classes. Bug: v8:6000 Change-Id: I0402ef78a54d6ba1bae62214f16aabfebbd7c581 Reviewed-on: https://chromium-review.googlesource.com/758645 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49268}
-
- 10 Aug, 2017 1 commit
-
-
Michael Starzinger authored
This is in preparation to the removal of the FullCodeGenerator, we no longer need the ability to stress the underlying implementation. R=rmcilroy@chromium.org BUG=v8:6409 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Iad3177d6de4a68b57c12a770b6e85ed7a9710254 Reviewed-on: https://chromium-review.googlesource.com/584747Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47276}
-
- 02 Aug, 2017 1 commit
-
-
jgruber authored
Consider: function f() { return; } This CL ensures that the closing brace is considered as covered by introducing a special case for open-ended range rewrites when the parent range is the function range itself. Bug: v8:6000, v8:6661 Change-Id: I0be307759967e9f4df245a4f367326a37dda86fd Reviewed-on: https://chromium-review.googlesource.com/597651Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47079}
-
- 28 Jul, 2017 1 commit
-
-
jgruber authored
This includes the catch and finally keywords in the respective range. For instance: // Catch range previously: |<--------->| try { /* ... */ } catch (e) { /* ... */ } // Now: |<------------------->| Bug: v8:6000 Change-Id: I1bd9f7fce8bb7de945da83ab512833841b9d956a Reviewed-on: https://chromium-review.googlesource.com/586598 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46959}
-
- 27 Jul, 2017 1 commit
-
-
jgruber authored
These counters handle cases in which the catch/finally block contains a jump statement. Bug: v8:6000 Change-Id: Ic83f11ee431edabe61f129c9abc3adc12a79c338 Reviewed-on: https://chromium-review.googlesource.com/586595Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46945}
-
- 26 Jul, 2017 2 commits
-
-
jgruber authored
The yield* statement when used in combination with async iterators is not supported yet, as that is desugared into a more complex construct that doesn't offer a good dedicated bytecode to attach the source range information yet. Note that invocation counts of generator functions are incorrect as they count each resumption as an individual call. See https://crbug.com/v8/6594. Bug: v8:6000 Change-Id: I7ac7073473c9b64bb207cdbc4dab083ec1145656 Reviewed-on: https://chromium-review.googlesource.com/582690 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46890}
-
jgruber authored
Refactor common test code into code-coverage-utils.js and add tests to verify counter behavior in opt/no-opt situations. Bug: v8:6000 Change-Id: I07e62345476e8c81521c491ae605ddaf71600667 Reviewed-on: https://chromium-review.googlesource.com/584449Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46888}
-
- 14 Jul, 2017 2 commits
-
-
jgruber authored
Bug: v8:6000 Change-Id: I8c068383300ba869a87f836504c84ea08fcff87e Reviewed-on: https://chromium-review.googlesource.com/568307Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46675}
-
jgruber authored
Bug: v8:6000 Change-Id: Ia50108ebbf838e210d95cb268858394e6a66c88d Reviewed-on: https://chromium-review.googlesource.com/567990 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46658}
-
- 13 Jul, 2017 2 commits
-
-
jgruber authored
Both labeled blocks: l0: { break l0; } and blocks containing jump statements (break, return, continue) require a continuation counter to correctly display coverage. Bug: v8:6000 Change-Id: I3ae8ddd3d9f6c087622482b86014dd583b774b71 Reviewed-on: https://chromium-review.googlesource.com/568024Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46644}
-
Ross McIlroy authored
Removes the --ignition flag which is now on by default. Adds a --stress-fullcodegen flag which enables running all functions supported by fullcodegen to be compiled by fullcodegen. This will enable moving parser internalization later when we are not stressing fullcodegen or compiling asm.js functions. BUG=v8:5203, v8:6409, v8:6589 Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e Reviewed-on: https://chromium-review.googlesource.com/565569 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46635}
-
- 12 Jul, 2017 1 commit
-
-
jgruber authored
This CL moves collected source range information out of AST nodes and into a side table stored on ParseInfo. The side table is only created if block coverage is enabled, so there's almost no memory overhead in the standard case. Change-Id: I41871b8425ebbc6217d82d3ad26b5fc9e5d68ecb Reviewed-on: https://chromium-review.googlesource.com/566808 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46590}
-
- 11 Jul, 2017 1 commit
-
-
jgruber authored
Switch statements generate a counter for each clause plus a continuation counter. Bug: v8:6000 Change-Id: Ic55a7efda54de1152bd5283d753119aa2764afbd Reviewed-on: https://chromium-review.googlesource.com/558249Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46550}
-
- 07 Jul, 2017 1 commit
-
-
jgruber authored
This adds support for exception control flow by adding a counter behind throw statements (never incremented), as well as a counter for catch and finally blocks. Bug: v8:6000 Change-Id: I3959772c889b543ab5e186ad7cd710e55a8aec23 Reviewed-on: https://chromium-review.googlesource.com/558993 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46476}
-
- 06 Jul, 2017 1 commit
-
-
jgruber authored
This CL adds a few transformations that clean up the set of reported source ranges. Duplicates, empty, and uncovered ranges are removed, and nested/consecutive ranges are merged if possible. BUG=v8:6000 Change-Id: I421ee35ce8292cfe84c1eea4f653762cea5d909d Reviewed-on: https://chromium-review.googlesource.com/558411Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46450}
-
- 23 Jun, 2017 1 commit
-
-
jgruber authored
Drive-by-fixes: Singleton ranges past EOF, disable optimization for block count mode. Bug: v8:6000 Change-Id: I718891f8821285ce3d7d8360faaa91a43de5b93d Reviewed-on: https://chromium-review.googlesource.com/541300Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46168}
-
- 21 Jun, 2017 1 commit
-
-
jgruber authored
This CL improves reported source range precision in a couple of ways: Source ranges are now standardized to consist of an inclusive start index and an exclusive end index (similar to what's reported for functions). For example: 0123456789 // Offset. { f(); } // Block represented as range {0,8}. Duplicate singleton ranges (i.e. same start and end offsets) are now merged (this only becomes relevant once jump statement coverage is added). For example: for (.) break; // Break- and loop continuation have same positions. SourceRangeScope incorrectly collected starting position (unconditionally) and end position (when no semi-colon was present). 01234567890123 // Offset. for (.) break // Loop body range is {8,13}, was {6,9}. Bug: v8:6000 Change-Id: I62e7c70cc894a20f318330a2fbbcedc47da2b5db Reviewed-on: https://chromium-review.googlesource.com/541358 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#46095}
-
- 19 Jun, 2017 1 commit
-
-
jgruber authored
Track execution counts of the continuations of block structures (e.g. IfStatements) to capture cases in which execution does not continue after a block. For example: for (;;) { return; } // Never reached, tracked by continuation counter. A continuation counter only has a start position; it's range is implicitly until the next sibling range or the end of the parent range. Bug: v8:6000 Change-Id: I8e8f1f5b140b64c86754b916e626eb50f0707d70 Reviewed-on: https://chromium-review.googlesource.com/530846 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#46006}
-
- 08 Jun, 2017 1 commit
-
-
jgruber authored
This adds block coverage support for simple iteration. For-of and for-in loops are not yet covered, and we don't yet keep execution counts for init, cond, and next statements. BUG=v8:6000 Change-Id: I30b468a2c93f0bb60e857b6632be92920f6857e0 Reviewed-on: https://chromium-review.googlesource.com/527113 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45779}
-