-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[v10.x backport] deps: v8, backport coverage fixes
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. [email protected], [email protected], [email protected] Bug: v8:8691 Change-Id: Ibcbab79fbe54719a8993045040349c863b139011 Reviewed-on: https://chromium-review.googlesource.com/c/1480632 Commit-Queue: Georg Neis <[email protected]> Reviewed-by: Georg Neis <[email protected]> Reviewed-by: Jakob Gruber <[email protected]> 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. [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: [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 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 <[email protected]> Reviewed-by: Marja Hölttä <[email protected]> Reviewed-by: Camillo Bruni <[email protected]> Commit-Queue: Igor Sheludko <[email protected]> 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 <[email protected]> Reviewed-by: Toon Verwaest <[email protected]> Cr-Commit-Position: refs/heads/master@{#53820} Refs: v8/v8@52e2b5a
- Loading branch information
Showing
34 changed files
with
961 additions
and
599 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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -49,7 +49,7 @@ Andrew Paprocki <[email protected]> | |
Andrei Kashcha <[email protected]> | ||
Anna Henningsen <[email protected]> | ||
Bangfu Tao <[email protected]> | ||
Ben Coe <ben@npmjs.com> | ||
Ben Coe <bencoe@gmail.com> | ||
Ben Newman <[email protected]> | ||
Ben Noordhuis <[email protected]> | ||
Benjamin Tan <[email protected]> | ||
|
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.