nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2025-04-28 11:07:42 +00:00
Code Issues Packages Projects Releases Wiki Activity
master
rust/tests/coverage/conditions.cov-map

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

192 lines
12 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: 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
Raw bytes (533): 0x[01, 01, 47, 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, 97, 01, 0d, 11, 0d, 11, 0d, 11, 0d, 11, 0d, 11, 97, 01, 15, 0d, 11, 19, 45, 19, 8f, 01, 45, 49, 8f, 01, 4d, 45, 49, 19, 8b, 01, 8f, 01, 4d, 45, 49, 97, 01, db, 01, 0d, 11, 15, 19, 15, 19, 15, 19, 1d, 21, 15, 19, db, 01, 1d, 15, 19, 21, 39, 21, d3, 01, 39, 3d, d3, 01, 41, 39, 3d, 21, cf, 01, d3, 01, 41, 39, 3d, db, 01, 97, 02, 15, 19, 1d, 21, 25, 29, 1d, 21, 97, 02, 25, 1d, 21, 29, 2d, 29, 8f, 02, 2d, 31, 8f, 02, 35, 2d, 31, 29, 8b, 02, 8f, 02, 35, 2d, 31, 97, 02, 9b, 02, 1d, 21, 25, 29, 44, 01, 03, 01, 02, 0c, 01, 02, 0d, 02, 06, 00, 02, 05, 00, 06, 03, 03, 09, 00, 0a, 01, 00, 10, 00, 1d, 05, 01, 09, 01, 0a, 06, 02, 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, 01, 12, 2a, 03, 09, 00, 0f, 03, 03, 09, 01, 0c, 03, 01, 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, 97, 01, 03, 08, 00, 0c, 97, 01, 01, 0d, 01, 10, 97, 01, 01, 11, 02, 0a, 00, 02, 09, 00, 0a, 97, 01, 02, 0c, 00, 19, 15, 00, 1a, 02, 0a, 6a, 04, 11, 00, 1e, 19, 01, 10, 00, 1d, 72, 00, 21, 00, 2e, 76, 00, 32, 00, 40, 8b, 01, 00, 41, 02, 0e, 86, 01, 02, 0d, 00, 0e, 19, 01, 0d, 00, 1b, 92, 01, 02, 0d, 00, 13, 00, 02, 05, 00, 06, db, 01, 02, 09, 01, 0c, db, 01, 01, 0d, 02, 06, 00, 02, 05, 00, 06, 97, 02, 02, 09, 00, 0a, db, 01, 00, 10, 00, 1d, 1d, 00, 1e, 02, 06, ae, 01, 02, 0f, 00, 1c, 21, 01, 0c, 00, 19, b6, 01, 00, 1d, 00, 2a, ba, 01, 00, 2e, 00, 3c, cf, 01, 00, 3d, 02, 0a, ca, 01, 02, 09, 00, 0a, 21, 01, 09, 00, 17, d6, 01, 02, 0d, 02, 0f, 9b, 02, 05, 09, 00, 0a, 97, 02, 00, 10, 00, 1d, 25, 00, 1e, 02, 06, ea, 01, 02, 0f, 00, 1c, 29, 01, 0c, 00, 19, f2, 01, 00, 1d, 00, 2a, f6, 01, 00, 2e, 00, 3c, 8b, 02, 00, 3d, 02, 0a, 86, 02, 02, 09, 00, 0a, 29, 01, 09, 00, 17, 92, 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
- file 0 => global file 1
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
Number of expressions: 71
- 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)
- expression 20 operands: lhs = Expression(0, Add), rhs = Expression(37, Add)
- 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)
- expression 26 operands: lhs = Expression(37, Add), rhs = Counter(5)
- expression 27 operands: lhs = Counter(3), rhs = Counter(4)
- expression 28 operands: lhs = Counter(6), rhs = Counter(17)
- expression 29 operands: lhs = Counter(6), rhs = Expression(35, Add)
- expression 30 operands: lhs = Counter(17), rhs = Counter(18)
- expression 31 operands: lhs = Expression(35, Add), rhs = Counter(19)
- expression 32 operands: lhs = Counter(17), rhs = Counter(18)
- expression 33 operands: lhs = Counter(6), rhs = Expression(34, Add)
- expression 34 operands: lhs = Expression(35, Add), rhs = Counter(19)
- expression 35 operands: lhs = Counter(17), rhs = Counter(18)
- expression 36 operands: lhs = Expression(37, Add), rhs = Expression(54, Add)
- expression 37 operands: lhs = Counter(3), rhs = Counter(4)
- expression 38 operands: lhs = Counter(5), rhs = Counter(6)
- expression 39 operands: lhs = Counter(5), rhs = Counter(6)
- expression 40 operands: lhs = Counter(5), rhs = Counter(6)
- expression 41 operands: lhs = Counter(7), rhs = Counter(8)
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: 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 43 operands: lhs = Expression(54, Add), rhs = Counter(7)
- expression 44 operands: lhs = Counter(5), rhs = Counter(6)
- expression 45 operands: lhs = Counter(8), rhs = Counter(14)
- expression 46 operands: lhs = Counter(8), rhs = Expression(52, Add)
- expression 47 operands: lhs = Counter(14), rhs = Counter(15)
- expression 48 operands: lhs = Expression(52, Add), rhs = Counter(16)
- expression 49 operands: lhs = Counter(14), rhs = Counter(15)
- expression 50 operands: lhs = Counter(8), rhs = Expression(51, Add)
- expression 51 operands: lhs = Expression(52, Add), rhs = Counter(16)
- expression 52 operands: lhs = Counter(14), rhs = Counter(15)
- expression 53 operands: lhs = Expression(54, Add), rhs = Expression(69, Add)
- expression 54 operands: lhs = Counter(5), rhs = Counter(6)
- expression 55 operands: lhs = Counter(7), rhs = Counter(8)
- expression 56 operands: lhs = Counter(9), rhs = Counter(10)
- expression 57 operands: lhs = Counter(7), rhs = Counter(8)
- expression 58 operands: lhs = Expression(69, Add), rhs = Counter(9)
- expression 59 operands: lhs = Counter(7), rhs = Counter(8)
- expression 60 operands: lhs = Counter(10), rhs = Counter(11)
- expression 61 operands: lhs = Counter(10), rhs = Expression(67, Add)
- expression 62 operands: lhs = Counter(11), rhs = Counter(12)
- expression 63 operands: lhs = Expression(67, Add), rhs = Counter(13)
- expression 64 operands: lhs = Counter(11), rhs = Counter(12)
- expression 65 operands: lhs = Counter(10), rhs = Expression(66, Add)
- expression 66 operands: lhs = Expression(67, Add), rhs = Counter(13)
- expression 67 operands: lhs = Counter(11), rhs = Counter(12)
- expression 68 operands: lhs = Expression(69, Add), rhs = Expression(70, Add)
- expression 69 operands: lhs = Counter(7), rhs = Counter(8)
- expression 70 operands: lhs = Counter(9), rhs = Counter(10)
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 file 0 mappings: 68
- Code(Counter(0)) at (prev + 3, 1) to (start + 2, 12)
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
- Code(Counter(0)) at (prev + 2, 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: 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
- Code(Counter(1)) at (prev + 1, 9) to (start + 1, 10)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(1, 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
= (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))
- Code(Counter(2)) at (prev + 1, 9) to (start + 1, 18)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(10, Sub)) at (prev + 3, 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: Store each BCB's code regions in one coverage statement If a BCB has more than one code region, those extra regions can now all be stored in the same coverage statement, instead of being stored in additional statements.
2023-09-19 04:15:33 +00:00
- Code(Expression(0, Add)) at (prev + 3, 9) to (start + 1, 12)
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(Expression(0, Add)) at (prev + 1, 13) to (start + 2, 6)
= (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))
- Code(Expression(37, Add)) at (prev + 3, 8) to (start + 0, 12)
= (c3 + c4)
- Code(Expression(37, Add)) at (prev + 1, 13) to (start + 1, 16)
= (c3 + c4)
- Code(Expression(37, Add)) at (prev + 1, 17) to (start + 2, 10)
= (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: 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
- Code(Expression(37, Add)) at (prev + 2, 12) to (start + 0, 25)
= (c3 + c4)
- Code(Counter(5)) at (prev + 0, 26) to (start + 2, 10)
- Code(Expression(26, Sub)) at (prev + 4, 17) to (start + 0, 30)
= ((c3 + c4) - c5)
- Code(Counter(6)) at (prev + 1, 16) to (start + 0, 29)
- Code(Expression(28, Sub)) at (prev + 0, 33) to (start + 0, 46)
= (c6 - c17)
- Code(Expression(29, Sub)) at (prev + 0, 50) to (start + 0, 64)
= (c6 - (c17 + c18))
- Code(Expression(34, Add)) at (prev + 0, 65) to (start + 2, 14)
= ((c17 + c18) + c19)
- Code(Expression(33, Sub)) at (prev + 2, 13) to (start + 0, 14)
= (c6 - ((c17 + c18) + c19))
- Code(Counter(6)) at (prev + 1, 13) to (start + 0, 27)
- Code(Expression(36, Sub)) at (prev + 2, 13) to (start + 0, 19)
= ((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: 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
- Code(Expression(54, Add)) at (prev + 2, 9) to (start + 1, 12)
= (c5 + c6)
- Code(Expression(54, Add)) at (prev + 1, 13) to (start + 2, 6)
= (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: 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
- Code(Expression(69, Add)) at (prev + 2, 9) to (start + 0, 10)
= (c7 + c8)
- Code(Expression(54, Add)) at (prev + 0, 16) to (start + 0, 29)
= (c5 + c6)
- Code(Counter(7)) at (prev + 0, 30) to (start + 2, 6)
coverage: Prefer to visit nodes whose predecessors have been visited
2024-12-05 07:57:17 +00:00
- Code(Expression(43, 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)
- Code(Expression(45, Sub)) at (prev + 0, 29) to (start + 0, 42)
= (c8 - c14)
- Code(Expression(46, Sub)) at (prev + 0, 46) to (start + 0, 60)
= (c8 - (c14 + c15))
- Code(Expression(51, Add)) at (prev + 0, 61) to (start + 2, 10)
= ((c14 + c15) + c16)
- Code(Expression(50, Sub)) at (prev + 2, 9) to (start + 0, 10)
= (c8 - ((c14 + c15) + c16))
- Code(Counter(8)) at (prev + 1, 9) to (start + 0, 23)
- Code(Expression(53, Sub)) at (prev + 2, 13) to (start + 2, 15)
= ((c5 + c6) - (c7 + c8))
- Code(Expression(70, Add)) at (prev + 5, 9) to (start + 0, 10)
= (c9 + c10)
- Code(Expression(69, Add)) at (prev + 0, 16) to (start + 0, 29)
= (c7 + c8)
- Code(Counter(9)) at (prev + 0, 30) to (start + 2, 6)
- Code(Expression(58, Sub)) at (prev + 2, 15) to (start + 0, 28)
= ((c7 + c8) - c9)
- Code(Counter(10)) at (prev + 1, 12) to (start + 0, 25)
- Code(Expression(60, Sub)) at (prev + 0, 29) to (start + 0, 42)
= (c10 - c11)
- Code(Expression(61, Sub)) at (prev + 0, 46) to (start + 0, 60)
= (c10 - (c11 + c12))
- Code(Expression(66, Add)) at (prev + 0, 61) to (start + 2, 10)
= ((c11 + c12) + c13)
- Code(Expression(65, Sub)) at (prev + 2, 9) to (start + 0, 10)
= (c10 - ((c11 + c12) + c13))
- Code(Counter(10)) at (prev + 1, 9) to (start + 0, 23)
- Code(Expression(68, Sub)) at (prev + 2, 9) to (start + 0, 15)
= ((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