nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2025-06-19 19:17:31 +00:00
Code Issues Packages Projects Releases Wiki Activity
master
rust/tests/coverage/conditions.cov-map

233 lines
14 KiB
Plaintext
Raw Permalink Normal View History

Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 11:29:41 +00:00
Function name: conditions::main
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Raw bytes (656): 0x[01, 01, 57, 05, 09, 01, 05, 09, 5d, 09, 27, 5d, 61, 27, 65, 5d, 61, 09, 23, 27, 65, 5d, 61, 01, 03, 03, 0d, 11, 51, 11, 4f, 51, 55, 4f, 59, 51, 55, 11, 4b, 4f, 59, 51, 55, 03, 9f, 01, 0d, 11, 0d, 11, 0d, 11, 0d, 11, 0d, 11, 0d, 11, 0d, 11, 9f, 01, 15, 0d, 11, 19, 45, 19, 97, 01, 45, 49, 97, 01, 4d, 45, 49, 19, 93, 01, 97, 01, 4d, 45, 49, 9f, 01, 9b, 02, 0d, 11, 15, 19, 15, 19, 15, 19, 15, 19, 15, 19, 1d, 21, 15, 19, 9b, 02, 1d, 15, 19, 21, 39, 21, e3, 01, 39, 3d, e3, 01, 41, 39, 3d, 21, df, 01, e3, 01, 41, 39, 3d, 9b, 02, d7, 02, 15, 19, 1d, 21, 9b, 02, d7, 02, 15, 19, 1d, 21, 9b, 02, d7, 02, 15, 19, 1d, 21, 9b, 02, d7, 02, 15, 19, 1d, 21, 9b, 02, d7, 02, 15, 19, 1d, 21, 25, 29, 1d, 21, d7, 02, 25, 1d, 21, 29, 2d, 29, cf, 02, 2d, 31, cf, 02, 35, 2d, 31, 29, cb, 02, cf, 02, 35, 2d, 31, d7, 02, db, 02, 1d, 21, 25, 29, 53, 01, 03, 01, 00, 0a, 01, 01, 09, 00, 16, 01, 00, 19, 00, 1a, 01, 01, 08, 00, 0c, 01, 00, 0d, 02, 06, 00, 02, 05, 00, 06, 03, 03, 09, 00, 0a, 01, 00, 10, 00, 1d, 05, 01, 09, 00, 17, 05, 01, 09, 00, 0a, 06, 01, 0f, 00, 1c, 09, 01, 0c, 00, 19, 0a, 00, 1d, 00, 2a, 0e, 00, 2e, 00, 3c, 23, 00, 3d, 02, 0a, 1e, 02, 09, 00, 0a, 09, 01, 09, 00, 17, 09, 01, 09, 00, 12, 2a, 02, 09, 00, 0f, 03, 03, 09, 00, 16, 03, 00, 19, 00, 1a, 03, 01, 08, 00, 0c, 03, 00, 0d, 02, 06, 00, 02, 05, 00, 06, 03, 02, 08, 00, 15, 0d, 00, 16, 02, 06, 2e, 02, 0f, 00, 1c, 11, 01, 0c, 00, 19, 32, 00, 1d, 00, 2a, 36, 00, 2e, 00, 3c, 4b, 00, 3d, 02, 0a, 46, 02, 09, 00, 0a, 11, 01, 09, 00, 17, 52, 02, 09, 00, 0f, 9f, 01, 03, 08, 00, 0c, 9f, 01, 01, 0d, 00, 1a, 9f, 01, 00, 1d, 00, 1e, 9f, 01, 01, 0c, 00, 10, 9f, 01, 00, 11, 02, 0a, 00, 02, 09, 00, 0a, 9f, 01, 02, 0c, 00, 19, 15, 00, 1a, 02, 0a, 72, 04, 11, 00, 1e, 19, 01, 10, 00, 1d, 7a, 00, 21, 00, 2e, 7e, 00, 32, 00, 40, 93, 01, 00, 41, 02, 0e, 8e, 01, 02, 0d, 00, 0e, 19, 01, 0d, 00, 1b, 9a, 01, 02, 0d, 00, 13, 00, 02, 05, 00, 06, 9b, 02, 02, 09, 00, 16, 9b, 02, 00, 19, 00, 1a, 9b, 02, 01, 08, 00, 0c, 9b, 02, 00, 0d, 02, 06, 00, 02, 05, 00, 06, d7, 02, 02, 09, 00, 0a, 9b, 02, 00, 10, 00, 1d, 1d, 00, 1e, 02, 06, be, 01, 02, 0f, 00, 1c, 21, 01, 0c, 00, 19, c6, 01, 00, 1d, 00, 2a, ca, 01, 00, 2e, 00, 3c, df, 01, 00, 3d, 02, 0a, da, 01, 02, 09, 00, 0a, 21, 01, 09, 00, 17, 96, 02, 02, 0d, 00, 20, 96, 02, 00, 23, 00, 2c, 96, 02, 01, 09, 00, 11, 96, 02, 00, 12, 00, 1b, 96, 02, 01, 09, 00, 0f, db, 02, 03, 09, 00, 0a, d7, 02, 00, 10, 00, 1d, 25, 00, 1e, 02, 06, aa, 02, 02, 0f, 00, 1c, 29, 01, 0c, 00, 19, b2, 02, 00, 1d, 00, 2a, b6, 02, 00, 2e, 00, 3c, cb, 02, 00, 3d, 02, 0a, c6, 02, 02, 09, 00, 0a, 29, 01, 09, 00, 17, d2, 02, 02, 09, 00, 0f, 01, 02, 01, 00, 02]
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 11:29:41 +00:00
Number of files: 1
coverage-dump: Dump filenames instead of global file IDs (and bless)
2025-04-24 07:36:50 +00:00
- file 0 => $DIR/conditions.rs
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Number of expressions: 87
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
- expression 0 operands: lhs = Counter(1), rhs = Counter(2)
- expression 1 operands: lhs = Counter(0), rhs = Counter(1)
- expression 2 operands: lhs = Counter(2), rhs = Counter(23)
- expression 3 operands: lhs = Counter(2), rhs = Expression(9, Add)
- expression 4 operands: lhs = Counter(23), rhs = Counter(24)
- expression 5 operands: lhs = Expression(9, Add), rhs = Counter(25)
- expression 6 operands: lhs = Counter(23), rhs = Counter(24)
- expression 7 operands: lhs = Counter(2), rhs = Expression(8, Add)
- expression 8 operands: lhs = Expression(9, Add), rhs = Counter(25)
- expression 9 operands: lhs = Counter(23), rhs = Counter(24)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- expression 10 operands: lhs = Counter(0), rhs = Expression(0, Add)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
- expression 11 operands: lhs = Expression(0, Add), rhs = Counter(3)
- expression 12 operands: lhs = Counter(4), rhs = Counter(20)
- expression 13 operands: lhs = Counter(4), rhs = Expression(19, Add)
- expression 14 operands: lhs = Counter(20), rhs = Counter(21)
- expression 15 operands: lhs = Expression(19, Add), rhs = Counter(22)
- expression 16 operands: lhs = Counter(20), rhs = Counter(21)
- expression 17 operands: lhs = Counter(4), rhs = Expression(18, Add)
- expression 18 operands: lhs = Expression(19, Add), rhs = Counter(22)
- expression 19 operands: lhs = Counter(20), rhs = Counter(21)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- expression 20 operands: lhs = Expression(0, Add), rhs = Expression(39, Add)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
- expression 21 operands: lhs = Counter(3), rhs = Counter(4)
- expression 22 operands: lhs = Counter(3), rhs = Counter(4)
- expression 23 operands: lhs = Counter(3), rhs = Counter(4)
- expression 24 operands: lhs = Counter(3), rhs = Counter(4)
- expression 25 operands: lhs = Counter(3), rhs = Counter(4)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- expression 26 operands: lhs = Counter(3), rhs = Counter(4)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
- expression 27 operands: lhs = Counter(3), rhs = Counter(4)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- expression 28 operands: lhs = Expression(39, Add), rhs = Counter(5)
- expression 29 operands: lhs = Counter(3), rhs = Counter(4)
- expression 30 operands: lhs = Counter(6), rhs = Counter(17)
- expression 31 operands: lhs = Counter(6), rhs = Expression(37, Add)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
- expression 32 operands: lhs = Counter(17), rhs = Counter(18)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- expression 33 operands: lhs = Expression(37, Add), rhs = Counter(19)
- expression 34 operands: lhs = Counter(17), rhs = Counter(18)
- expression 35 operands: lhs = Counter(6), rhs = Expression(36, Add)
- expression 36 operands: lhs = Expression(37, Add), rhs = Counter(19)
- expression 37 operands: lhs = Counter(17), rhs = Counter(18)
- expression 38 operands: lhs = Expression(39, Add), rhs = Expression(70, Add)
- expression 39 operands: lhs = Counter(3), rhs = Counter(4)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
- expression 40 operands: lhs = Counter(5), rhs = Counter(6)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- expression 41 operands: lhs = Counter(5), rhs = Counter(6)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- expression 42 operands: lhs = Counter(5), rhs = Counter(6)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- expression 43 operands: lhs = Counter(5), rhs = Counter(6)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
- expression 44 operands: lhs = Counter(5), rhs = Counter(6)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- expression 45 operands: lhs = Counter(7), rhs = Counter(8)
- expression 46 operands: lhs = Counter(5), rhs = Counter(6)
- expression 47 operands: lhs = Expression(70, Add), rhs = Counter(7)
- expression 48 operands: lhs = Counter(5), rhs = Counter(6)
- expression 49 operands: lhs = Counter(8), rhs = Counter(14)
- expression 50 operands: lhs = Counter(8), rhs = Expression(56, Add)
- expression 51 operands: lhs = Counter(14), rhs = Counter(15)
- expression 52 operands: lhs = Expression(56, Add), rhs = Counter(16)
- expression 53 operands: lhs = Counter(14), rhs = Counter(15)
- expression 54 operands: lhs = Counter(8), rhs = Expression(55, Add)
- expression 55 operands: lhs = Expression(56, Add), rhs = Counter(16)
- expression 56 operands: lhs = Counter(14), rhs = Counter(15)
- expression 57 operands: lhs = Expression(70, Add), rhs = Expression(85, Add)
- expression 58 operands: lhs = Counter(5), rhs = Counter(6)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
- expression 59 operands: lhs = Counter(7), rhs = Counter(8)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- expression 60 operands: lhs = Expression(70, Add), rhs = Expression(85, Add)
- expression 61 operands: lhs = Counter(5), rhs = Counter(6)
- expression 62 operands: lhs = Counter(7), rhs = Counter(8)
- expression 63 operands: lhs = Expression(70, Add), rhs = Expression(85, Add)
- expression 64 operands: lhs = Counter(5), rhs = Counter(6)
- expression 65 operands: lhs = Counter(7), rhs = Counter(8)
- expression 66 operands: lhs = Expression(70, Add), rhs = Expression(85, Add)
- expression 67 operands: lhs = Counter(5), rhs = Counter(6)
- expression 68 operands: lhs = Counter(7), rhs = Counter(8)
- expression 69 operands: lhs = Expression(70, Add), rhs = Expression(85, Add)
- expression 70 operands: lhs = Counter(5), rhs = Counter(6)
- expression 71 operands: lhs = Counter(7), rhs = Counter(8)
- expression 72 operands: lhs = Counter(9), rhs = Counter(10)
- expression 73 operands: lhs = Counter(7), rhs = Counter(8)
- expression 74 operands: lhs = Expression(85, Add), rhs = Counter(9)
- expression 75 operands: lhs = Counter(7), rhs = Counter(8)
- expression 76 operands: lhs = Counter(10), rhs = Counter(11)
- expression 77 operands: lhs = Counter(10), rhs = Expression(83, Add)
- expression 78 operands: lhs = Counter(11), rhs = Counter(12)
- expression 79 operands: lhs = Expression(83, Add), rhs = Counter(13)
- expression 80 operands: lhs = Counter(11), rhs = Counter(12)
- expression 81 operands: lhs = Counter(10), rhs = Expression(82, Add)
- expression 82 operands: lhs = Expression(83, Add), rhs = Counter(13)
- expression 83 operands: lhs = Counter(11), rhs = Counter(12)
- expression 84 operands: lhs = Expression(85, Add), rhs = Expression(86, Add)
- expression 85 operands: lhs = Counter(7), rhs = Counter(8)
- expression 86 operands: lhs = Counter(9), rhs = Counter(10)
Number of file 0 mappings: 83
- Code(Counter(0)) at (prev + 3, 1) to (start + 0, 10)
- Code(Counter(0)) at (prev + 1, 9) to (start + 0, 22)
- Code(Counter(0)) at (prev + 0, 25) to (start + 0, 26)
- Code(Counter(0)) at (prev + 1, 8) to (start + 0, 12)
- Code(Counter(0)) at (prev + 0, 13) to (start + 2, 6)
coverage: Restrict empty-span expansion to only cover `{` and `}`
2024-11-05 10:59:10 +00:00
- Code(Zero) at (prev + 2, 5) to (start + 0, 6)
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 11:29:41 +00:00
- Code(Expression(0, Add)) at (prev + 3, 9) to (start + 0, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c1 + c2)
coverage: Simplify counter expressions using simple algebra Some of these cases currently don't occur in practice, but are included for completeness, and to avoid having to add them later as branch coverage and MC/DC coverage start building more complex expressions.
2024-05-14 03:51:24 +00:00
- Code(Counter(0)) at (prev + 0, 16) to (start + 0, 29)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Counter(1)) at (prev + 1, 9) to (start + 0, 23)
- Code(Counter(1)) at (prev + 1, 9) to (start + 0, 10)
- Code(Expression(1, Sub)) at (prev + 1, 15) to (start + 0, 28)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c0 - c1)
- Code(Counter(2)) at (prev + 1, 12) to (start + 0, 25)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(2, Sub)) at (prev + 0, 29) to (start + 0, 42)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c2 - c23)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(3, Sub)) at (prev + 0, 46) to (start + 0, 60)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c2 - (c23 + c24))
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(8, Add)) at (prev + 0, 61) to (start + 2, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c23 + c24) + c25)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(7, Sub)) at (prev + 2, 9) to (start + 0, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c2 - ((c23 + c24) + c25))
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Counter(2)) at (prev + 1, 9) to (start + 0, 23)
- Code(Counter(2)) at (prev + 1, 9) to (start + 0, 18)
- Code(Expression(10, Sub)) at (prev + 2, 9) to (start + 0, 15)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c0 - (c1 + c2))
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(0, Add)) at (prev + 3, 9) to (start + 0, 22)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c1 + c2)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(0, Add)) at (prev + 0, 25) to (start + 0, 26)
= (c1 + c2)
- Code(Expression(0, Add)) at (prev + 1, 8) to (start + 0, 12)
= (c1 + c2)
- Code(Expression(0, Add)) at (prev + 0, 13) to (start + 2, 6)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c1 + c2)
coverage: Restrict empty-span expansion to only cover `{` and `}`
2024-11-05 10:59:10 +00:00
- Code(Zero) at (prev + 2, 5) to (start + 0, 6)
coverage: Simplify counter expressions using simple algebra Some of these cases currently don't occur in practice, but are included for completeness, and to avoid having to add them later as branch coverage and MC/DC coverage start building more complex expressions.
2024-05-14 03:51:24 +00:00
- Code(Expression(0, Add)) at (prev + 2, 8) to (start + 0, 21)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c1 + c2)
- Code(Counter(3)) at (prev + 0, 22) to (start + 2, 6)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(11, Sub)) at (prev + 2, 15) to (start + 0, 28)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c1 + c2) - c3)
- Code(Counter(4)) at (prev + 1, 12) to (start + 0, 25)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(12, Sub)) at (prev + 0, 29) to (start + 0, 42)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c4 - c20)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(13, Sub)) at (prev + 0, 46) to (start + 0, 60)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c4 - (c20 + c21))
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(18, Add)) at (prev + 0, 61) to (start + 2, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c20 + c21) + c22)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(17, Sub)) at (prev + 2, 9) to (start + 0, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c4 - ((c20 + c21) + c22))
- Code(Counter(4)) at (prev + 1, 9) to (start + 0, 23)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(20, Sub)) at (prev + 2, 9) to (start + 0, 15)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c1 + c2) - (c3 + c4))
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(39, Add)) at (prev + 3, 8) to (start + 0, 12)
= (c3 + c4)
- Code(Expression(39, Add)) at (prev + 1, 13) to (start + 0, 26)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c3 + c4)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(39, Add)) at (prev + 0, 29) to (start + 0, 30)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c3 + c4)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(39, Add)) at (prev + 1, 12) to (start + 0, 16)
= (c3 + c4)
- Code(Expression(39, Add)) at (prev + 0, 17) to (start + 2, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c3 + c4)
coverage: Restrict empty-span expansion to only cover `{` and `}`
2024-11-05 10:59:10 +00:00
- Code(Zero) at (prev + 2, 9) to (start + 0, 10)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(39, Add)) at (prev + 2, 12) to (start + 0, 25)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c3 + c4)
- Code(Counter(5)) at (prev + 0, 26) to (start + 2, 10)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(28, Sub)) at (prev + 4, 17) to (start + 0, 30)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c3 + c4) - c5)
- Code(Counter(6)) at (prev + 1, 16) to (start + 0, 29)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(30, Sub)) at (prev + 0, 33) to (start + 0, 46)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c6 - c17)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(31, Sub)) at (prev + 0, 50) to (start + 0, 64)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c6 - (c17 + c18))
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(36, Add)) at (prev + 0, 65) to (start + 2, 14)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c17 + c18) + c19)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(35, Sub)) at (prev + 2, 13) to (start + 0, 14)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c6 - ((c17 + c18) + c19))
- Code(Counter(6)) at (prev + 1, 13) to (start + 0, 27)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(38, Sub)) at (prev + 2, 13) to (start + 0, 19)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c3 + c4) - (c5 + c6))
coverage: Restrict empty-span expansion to only cover `{` and `}`
2024-11-05 10:59:10 +00:00
- Code(Zero) at (prev + 2, 5) to (start + 0, 6)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(70, Add)) at (prev + 2, 9) to (start + 0, 22)
= (c5 + c6)
- Code(Expression(70, Add)) at (prev + 0, 25) to (start + 0, 26)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c5 + c6)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(70, Add)) at (prev + 1, 8) to (start + 0, 12)
= (c5 + c6)
- Code(Expression(70, Add)) at (prev + 0, 13) to (start + 2, 6)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c5 + c6)
coverage: Restrict empty-span expansion to only cover `{` and `}`
2024-11-05 10:59:10 +00:00
- Code(Zero) at (prev + 2, 5) to (start + 0, 6)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(85, Add)) at (prev + 2, 9) to (start + 0, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c7 + c8)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(70, Add)) at (prev + 0, 16) to (start + 0, 29)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c5 + c6)
- Code(Counter(7)) at (prev + 0, 30) to (start + 2, 6)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(47, Sub)) at (prev + 2, 15) to (start + 0, 28)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c5 + c6) - c7)
- Code(Counter(8)) at (prev + 1, 12) to (start + 0, 25)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(49, Sub)) at (prev + 0, 29) to (start + 0, 42)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c8 - c14)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(50, Sub)) at (prev + 0, 46) to (start + 0, 60)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c8 - (c14 + c15))
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(55, Add)) at (prev + 0, 61) to (start + 2, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c14 + c15) + c16)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(54, Sub)) at (prev + 2, 9) to (start + 0, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c8 - ((c14 + c15) + c16))
- Code(Counter(8)) at (prev + 1, 9) to (start + 0, 23)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(69, Sub)) at (prev + 2, 13) to (start + 0, 32)
= ((c5 + c6) - (c7 + c8))
- Code(Expression(69, Sub)) at (prev + 0, 35) to (start + 0, 44)
= ((c5 + c6) - (c7 + c8))
- Code(Expression(69, Sub)) at (prev + 1, 9) to (start + 0, 17)
= ((c5 + c6) - (c7 + c8))
- Code(Expression(69, Sub)) at (prev + 0, 18) to (start + 0, 27)
= ((c5 + c6) - (c7 + c8))
- Code(Expression(69, Sub)) at (prev + 1, 9) to (start + 0, 15)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c5 + c6) - (c7 + c8))
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(86, Add)) at (prev + 3, 9) to (start + 0, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c9 + c10)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(85, Add)) at (prev + 0, 16) to (start + 0, 29)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c7 + c8)
- Code(Counter(9)) at (prev + 0, 30) to (start + 2, 6)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(74, Sub)) at (prev + 2, 15) to (start + 0, 28)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c7 + c8) - c9)
- Code(Counter(10)) at (prev + 1, 12) to (start + 0, 25)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(76, Sub)) at (prev + 0, 29) to (start + 0, 42)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c10 - c11)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(77, Sub)) at (prev + 0, 46) to (start + 0, 60)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c10 - (c11 + c12))
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(82, Add)) at (prev + 0, 61) to (start + 2, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c11 + c12) + c13)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(81, Sub)) at (prev + 2, 9) to (start + 0, 10)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= (c10 - ((c11 + c12) + c13))
- Code(Counter(10)) at (prev + 1, 9) to (start + 0, 23)
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
- Code(Expression(84, Sub)) at (prev + 2, 9) to (start + 0, 15)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
= ((c7 + c8) - (c9 + c10))
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Counter(0)) at (prev + 2, 1) to (start + 0, 2)
coverage: Eliminate more counters by giving them to unreachable nodes When preparing a function's coverage counters and metadata during codegen, any part of the original coverage graph that was removed by MIR optimizations can be treated as having an execution count of zero. Somewhat counter-intuitively, if we give those unreachable nodes a _higher_ priority for receiving physical counters (instead of counter expressions), that ends up reducing the total number of physical counters needed. This works because if a node is unreachable, we don't actually create a physical counter for it. Instead that node gets a fixed zero counter, and any other node that would have relied on that physical counter in its counter expression can just ignore that term completely.
2025-02-11 03:09:11 +00:00
Highest counter ID seen: c10
Copy most of `tests/run-coverage` into `tests/coverage-map/status-quo` The output of these tests is too complicated to comfortably verify by hand, but we can still use them to observe changes to the underlying mappings produced by codegen/LLVM. If these tests fail due to non-coverage changes (e.g. in HIR-to-MIR lowering or MIR optimizations), it should usually be OK to just `--bless` them, as long as the `run-coverage` test suite still works.
2023-08-14 11:29:41 +00:00
Reference in New Issue Copy Permalink