1. 07 Jan, 2020 1 commit
  2. 07 Nov, 2019 1 commit
    • Sigurd Schneider's avatar
      [coverage] Fix coverage with default arguments · 0dfd9ea5
      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: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64836}
      0dfd9ea5
  3. 16 Oct, 2019 1 commit
    • Sigurd Schneider's avatar
      [coverage] Correctly report coverage for inline scripts · 0d7889d0
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64307}
      0d7889d0
  4. 12 Sep, 2019 1 commit
  5. 05 Sep, 2019 1 commit
    • Sigurd Schneider's avatar
      [debugger] Fix code coverage for async functions · 3b0f89d0
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63561}
      3b0f89d0
  6. 16 May, 2019 1 commit
    • Jakob Gruber's avatar
      [coverage] Add dedicated FunctionLiteral counters · 3002ff44
      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: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61574}
      3002ff44
  7. 28 Feb, 2019 1 commit
    • Benjamin's avatar
      [coverage] Extend SourceRangeAstVisitor for throw statements · 2d08967d
      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: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59936}
      2d08967d
  8. 05 Feb, 2019 1 commit
  9. 21 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [coverage] Rework continuation counter handling · 9365d090
      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: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58443}
      9365d090
  10. 13 Dec, 2018 1 commit
  11. 06 Dec, 2018 1 commit
    • tzik's avatar
      Replace %RunMicrotasks with %PerformMicrotaskCheckpoint · 07011cc4
      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: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58068}
      07011cc4
  12. 10 Oct, 2018 2 commits
    • Jakob Gruber's avatar
      [coverage] Filter out singleton ranges that alias full ranges · aac2f8c9
      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: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56531}
      aac2f8c9
    • Jakob Gruber's avatar
      Revert "[coverage] change block range to avoid ambiguity." · 47d34a31
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56513}
      47d34a31
  13. 02 Oct, 2018 1 commit
  14. 04 Apr, 2018 1 commit
    • jgruber's avatar
      [coverage] Fix invalid coverage block transformation · e42ce200
      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: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52352}
      e42ce200
  15. 12 Jan, 2018 1 commit
  16. 12 Dec, 2017 1 commit
  17. 24 Nov, 2017 1 commit
  18. 20 Nov, 2017 1 commit
  19. 17 Nov, 2017 1 commit
    • Jakob Gruber's avatar
      Revert "[coverage] add coverage for binary expressions" · 9037639e
      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: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49454}
      9037639e
  20. 10 Nov, 2017 1 commit
  21. 09 Nov, 2017 1 commit
  22. 10 Aug, 2017 1 commit
  23. 02 Aug, 2017 1 commit
  24. 28 Jul, 2017 1 commit
  25. 27 Jul, 2017 1 commit
  26. 26 Jul, 2017 2 commits
  27. 14 Jul, 2017 2 commits
  28. 13 Jul, 2017 2 commits
  29. 12 Jul, 2017 1 commit
  30. 11 Jul, 2017 1 commit
  31. 07 Jul, 2017 1 commit
  32. 06 Jul, 2017 1 commit
  33. 23 Jun, 2017 1 commit
  34. 21 Jun, 2017 1 commit
    • jgruber's avatar
      [coverage] Improve source range precision · 63a7fa5a
      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: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46095}
      63a7fa5a
  35. 19 Jun, 2017 1 commit
    • jgruber's avatar
      [coverage] Add continuation counters · 95882f0e
      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: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46006}
      95882f0e
  36. 08 Jun, 2017 1 commit