coverage: Anonymize line numbers in run-coverage test snapshots
This makes the test snapshots less sensitive to lines being added/removed.
This commit is contained in:
Zalathar
parent
07438b0928
commit
bfb16545a3
46 changed files with 2672 additions and 2655 deletions
|
|
@ -1,64 +1,64 @@
|
|||
1| |#![allow(unused_assignments)]
|
||||
2| |// failure-status: 101
|
||||
3| |
|
||||
4| 4|fn might_overflow(to_add: u32) -> u32 {
|
||||
5| 4| if to_add > 5 {
|
||||
6| 1| println!("this will probably overflow");
|
||||
7| 3| }
|
||||
8| 4| let add_to = u32::MAX - 5;
|
||||
9| 4| println!("does {} + {} overflow?", add_to, to_add);
|
||||
10| 4| let result = to_add + add_to;
|
||||
11| 4| println!("continuing after overflow check");
|
||||
12| 4| result
|
||||
13| 4|}
|
||||
14| |
|
||||
15| 1|fn main() -> Result<(),u8> {
|
||||
16| 1| let mut countdown = 10;
|
||||
17| 11| while countdown > 0 {
|
||||
18| 11| if countdown == 1 {
|
||||
19| 1| let result = might_overflow(10);
|
||||
20| 1| println!("Result: {}", result);
|
||||
21| 10| } else if countdown < 5 {
|
||||
22| 3| let result = might_overflow(1);
|
||||
23| 3| println!("Result: {}", result);
|
||||
24| 6| }
|
||||
25| 10| countdown -= 1;
|
||||
26| | }
|
||||
27| 0| Ok(())
|
||||
28| 0|}
|
||||
29| |
|
||||
30| |// Notes:
|
||||
31| |// 1. Compare this program and its coverage results to those of the very similar test `assert.rs`,
|
||||
32| |// and similar tests `panic_unwind.rs`, abort.rs` and `try_error_result.rs`.
|
||||
33| |// 2. This test confirms the coverage generated when a program passes or fails a
|
||||
34| |// compiler-generated `TerminatorKind::Assert` (based on an overflow check, in this case).
|
||||
35| |// 3. Similar to how the coverage instrumentation handles `TerminatorKind::Call`,
|
||||
36| |// compiler-generated assertion failures are assumed to be a symptom of a program bug, not
|
||||
37| |// expected behavior. To simplify the coverage graphs and keep instrumented programs as
|
||||
38| |// small and fast as possible, `Assert` terminators are assumed to always succeed, and
|
||||
39| |// therefore are considered "non-branching" terminators. So, an `Assert` terminator does not
|
||||
40| |// get its own coverage counter.
|
||||
41| |// 4. After an unhandled panic or failed Assert, coverage results may not always be intuitive.
|
||||
42| |// In this test, the final count for the statements after the `if` block in `might_overflow()`
|
||||
43| |// is 4, even though the lines after `to_add + add_to` were executed only 3 times. Depending
|
||||
44| |// on the MIR graph and the structure of the code, this count could have been 3 (which might
|
||||
45| |// have been valid for the overflowed add `+`, but should have been 4 for the lines before
|
||||
46| |// the overflow. The reason for this potential uncertainty is, a `CounterKind` is incremented
|
||||
47| |// via StatementKind::Counter at the end of the block, but (as in the case in this test),
|
||||
48| |// a CounterKind::Expression is always evaluated. In this case, the expression was based on
|
||||
49| |// a `Counter` incremented as part of the evaluation of the `if` expression, which was
|
||||
50| |// executed, and counted, 4 times, before reaching the overflow add.
|
||||
51| |
|
||||
52| |// If the program did not overflow, the coverage for `might_overflow()` would look like this:
|
||||
53| |//
|
||||
54| |// 4| |fn might_overflow(to_add: u32) -> u32 {
|
||||
55| |// 5| 4| if to_add > 5 {
|
||||
56| |// 6| 0| println!("this will probably overflow");
|
||||
57| |// 7| 4| }
|
||||
58| |// 8| 4| let add_to = u32::MAX - 5;
|
||||
59| |// 9| 4| println!("does {} + {} overflow?", add_to, to_add);
|
||||
60| |// 10| 4| let result = to_add + add_to;
|
||||
61| |// 11| 4| println!("continuing after overflow check");
|
||||
62| |// 12| 4| result
|
||||
63| |// 13| 4|}
|
||||
LL| |#![allow(unused_assignments)]
|
||||
LL| |// failure-status: 101
|
||||
LL| |
|
||||
LL| 4|fn might_overflow(to_add: u32) -> u32 {
|
||||
LL| 4| if to_add > 5 {
|
||||
LL| 1| println!("this will probably overflow");
|
||||
LL| 3| }
|
||||
LL| 4| let add_to = u32::MAX - 5;
|
||||
LL| 4| println!("does {} + {} overflow?", add_to, to_add);
|
||||
LL| 4| let result = to_add + add_to;
|
||||
LL| 4| println!("continuing after overflow check");
|
||||
LL| 4| result
|
||||
LL| 4|}
|
||||
LL| |
|
||||
LL| 1|fn main() -> Result<(),u8> {
|
||||
LL| 1| let mut countdown = 10;
|
||||
LL| 11| while countdown > 0 {
|
||||
LL| 11| if countdown == 1 {
|
||||
LL| 1| let result = might_overflow(10);
|
||||
LL| 1| println!("Result: {}", result);
|
||||
LL| 10| } else if countdown < 5 {
|
||||
LL| 3| let result = might_overflow(1);
|
||||
LL| 3| println!("Result: {}", result);
|
||||
LL| 6| }
|
||||
LL| 10| countdown -= 1;
|
||||
LL| | }
|
||||
LL| 0| Ok(())
|
||||
LL| 0|}
|
||||
LL| |
|
||||
LL| |// Notes:
|
||||
LL| |// 1. Compare this program and its coverage results to those of the very similar test `assert.rs`,
|
||||
LL| |// and similar tests `panic_unwind.rs`, abort.rs` and `try_error_result.rs`.
|
||||
LL| |// 2. This test confirms the coverage generated when a program passes or fails a
|
||||
LL| |// compiler-generated `TerminatorKind::Assert` (based on an overflow check, in this case).
|
||||
LL| |// 3. Similar to how the coverage instrumentation handles `TerminatorKind::Call`,
|
||||
LL| |// compiler-generated assertion failures are assumed to be a symptom of a program bug, not
|
||||
LL| |// expected behavior. To simplify the coverage graphs and keep instrumented programs as
|
||||
LL| |// small and fast as possible, `Assert` terminators are assumed to always succeed, and
|
||||
LL| |// therefore are considered "non-branching" terminators. So, an `Assert` terminator does not
|
||||
LL| |// get its own coverage counter.
|
||||
LL| |// 4. After an unhandled panic or failed Assert, coverage results may not always be intuitive.
|
||||
LL| |// In this test, the final count for the statements after the `if` block in `might_overflow()`
|
||||
LL| |// is 4, even though the lines after `to_add + add_to` were executed only 3 times. Depending
|
||||
LL| |// on the MIR graph and the structure of the code, this count could have been 3 (which might
|
||||
LL| |// have been valid for the overflowed add `+`, but should have been 4 for the lines before
|
||||
LL| |// the overflow. The reason for this potential uncertainty is, a `CounterKind` is incremented
|
||||
LL| |// via StatementKind::Counter at the end of the block, but (as in the case in this test),
|
||||
LL| |// a CounterKind::Expression is always evaluated. In this case, the expression was based on
|
||||
LL| |// a `Counter` incremented as part of the evaluation of the `if` expression, which was
|
||||
LL| |// executed, and counted, 4 times, before reaching the overflow add.
|
||||
LL| |
|
||||
LL| |// If the program did not overflow, the coverage for `might_overflow()` would look like this:
|
||||
LL| |//
|
||||
LL| |// 4| |fn might_overflow(to_add: u32) -> u32 {
|
||||
LL| |// 5| 4| if to_add > 5 {
|
||||
LL| |// 6| 0| println!("this will probably overflow");
|
||||
LL| |// 7| 4| }
|
||||
LL| |// 8| 4| let add_to = u32::MAX - 5;
|
||||
LL| |// 9| 4| println!("does {} + {} overflow?", add_to, to_add);
|
||||
LL| |// 10| 4| let result = to_add + add_to;
|
||||
LL| |// 11| 4| println!("continuing after overflow check");
|
||||
LL| |// 12| 4| result
|
||||
LL| |// 13| 4|}
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue