1. Jan 17, 2019
    • Benjamin Coe's avatar
      deps: v8, cherry-pick 9365d09, aac2f8c, 47d34a3 · b7bbd871
      Benjamin Coe authored
          Original commit message 9365d09:
      
              [coverage] Rework continuation counter handling
      
              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/1339119
      
      
      Reviewed-by: default avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: default avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: default avatarGeorg Neis <neis@chromium.org>
              Commit-Queue: Jakob Gruber <jgruber@chromium.org>
              Cr-Commit-Position: refs/heads/master@{#58443}
      
          Refs: v8/v8@9365d09
      
          Original commit message aac2f8c:
      
              [coverage] Filter out singleton ranges that alias full ranges
      
              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/1273095
      
      
      Reviewed-by: default avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: default avatarYang Guo <yangguo@chromium.org>
              Commit-Queue: Jakob Gruber <jgruber@chromium.org>
              Cr-Commit-Position: refs/heads/master@{#56531}
      
          Refs: v8/v8@aac2f8c
      
          deps: V8: backport 47d34a3
      
          Original commit message:
      
              Revert "[coverage] change block range to avoid ambiguity."
      
              This reverts commit 471fef0469d04d7c487f3a08e81f3d77566a2f50.
      
              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=<U+200B>verwaest@chromium.org
              >
              > Bug: v8:8237
              > Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
              > Reviewed-on: https://chromium-review.googlesource.com/1254127
      
      
      > Reviewed-by: default avatarGeorg 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/1273096
      
      
      Reviewed-by: default avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: default avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: default avatarYang Guo <yangguo@chromium.org>
              Commit-Queue: Jakob Gruber <jgruber@chromium.org>
              Cr-Commit-Position: refs/heads/master@{#56513}
      
          Refs: https://github.com/v8/v8/commit/47d34a317e47bad86b68326607cd2e6de3901f3e
      
      PR-URL: https://github.com/nodejs/node/pull/25429
      
      
      Reviewed-By: default avatarYang Guo <yangguo@chromium.org>
      Reviewed-By: default avatarMichael Dawson <michael_dawson@ca.ibm.com>
      b7bbd871
  2. Jan 16, 2019
  3. Jan 15, 2019
  4. Jan 14, 2019
  5. Jan 13, 2019
  6. Jan 12, 2019