-
Notifications
You must be signed in to change notification settings - Fork 29.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Pulls in patches from V8 (52e2b5, 512175, aac2f8, 9365d09, 2d08967) which address a variety of coverage bugs, bringing Node v10 coverage to parity with Node v11. Original commit message: [coverage] Extend SourceRangeAstVisitor for throw statements 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} Refs: v8/v8@2d08967 Original commit message: [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: 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} Refs: v8/v8@9365d09 Original commit message: [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 <neis@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#56531} Refs: v8/v8@aac2f8c Original commit message: [ast] Introduce ZonePtrList<T> typedef for ZoneList<T*>. This is a preliminary step before changing the way we store zone pointers in the zones. Bug: v8:7903, v8:7754 Change-Id: I1e1af1823766c888ee0f8fe190f205f5b7e21973 Reviewed-on: https://chromium-review.googlesource.com/1118887 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#54193} Refs: v8/v8@512175a Original commit message: [explicit isolates] Replace every Handle(T*) in parsing/ Replace all but one Handle<T*>(T*) calls with ones that explicitly pass in an Isolate. Requires plumbing Isolate* through several Parser functions which previously avoided it because of worries about accessing the heap off the main thread. In all off-main-thread cases, isolate will be nullptr and every such function asserts with: DCHECK_EQ(parsing_on_main_thread_, isolate != nullptr); Also deletes unused function ParseInfo::ReopenHandlesInNewHandleScope. Bug: v8:7786 Change-Id: I3dd9c49dcde49fdbcb684ba73f47a30d00fc495e Reviewed-on: https://chromium-review.googlesource.com/1087272 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#53820} Refs: v8/v8@52e2b5a PR-URL: #26579 Reviewed-By: Rich Trott <rtrott@gmail.com> Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com> Reviewed-By: Shelley Vohr <codebytere@gmail.com> Reviewed-By: Guy Bedford <guybedford@gmail.com> Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
- Loading branch information
1 parent
2643801
commit 23ea7ee
Showing
35 changed files
with
964 additions
and
605 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.