Commits on Jan 26, 2019

1. deps: v8, cherry-pick 9365d09, aac2f8c, 47d34a3 …

     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.
   
         [email protected], [email protected], [email protected]
   
         Bug: v8:8381, v8:8539
         Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3
         Reviewed-on: https://chromium-review.googlesource.com/c/1339119
         Reviewed-by: Yang Guo <[email protected]>
         Reviewed-by: Leszek Swirski <[email protected]>
         Reviewed-by: Georg Neis <[email protected]>
         Commit-Queue: Jakob Gruber <[email protected]>
         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: Georg Neis <[email protected]>
         Reviewed-by: Yang Guo <[email protected]>
         Commit-Queue: Jakob Gruber <[email protected]>
         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>[email protected]
         >
         > Bug: v8:8237
         > Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
         > Reviewed-on: https://chromium-review.googlesource.com/1254127
         > Reviewed-by: Georg Neis <[email protected]>
         > Commit-Queue: Yang Guo <[email protected]>
         > Cr-Commit-Position: refs/heads/master@{#56347}
   
         [email protected],[email protected],[email protected]
   
         # 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: Jakob Gruber <[email protected]>
         Reviewed-by: Toon Verwaest <[email protected]>
         Reviewed-by: Yang Guo <[email protected]>
         Commit-Queue: Jakob Gruber <[email protected]>
         Cr-Commit-Position: refs/heads/master@{#56513}
   
     Refs: v8/v8@47d34a3
   
   PR-URL: nodejs#25429
   Backport-PR-URL: nodejs#25728
   Reviewed-By: Yang Guo <[email protected]>
   Reviewed-By: Michael Dawson <[email protected]>

   

   bcoe committed Jan 26, 2019
   Configuration menu

   • View commit details
   • Copy full SHA for c92fd82
   • Browse repository at this point

   Copy the full SHA

   c92fd82 View commit details

   Browse the repository at this point in the history