diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-30 03:59:35 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-30 03:59:35 +0000 |
commit | d1b2d29528b7794b41e66fc2136e395a02f8529b (patch) | |
tree | a4a17504b260206dec3cf55b2dca82929a348ac2 /tests/run-coverage/overflow.coverage | |
parent | Releasing progress-linux version 1.72.1+dfsg1-1~progress7.99u1. (diff) | |
download | rustc-d1b2d29528b7794b41e66fc2136e395a02f8529b.tar.xz rustc-d1b2d29528b7794b41e66fc2136e395a02f8529b.zip |
Merging upstream version 1.73.0+dfsg1.
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'tests/run-coverage/overflow.coverage')
-rw-r--r-- | tests/run-coverage/overflow.coverage | 126 |
1 files changed, 63 insertions, 63 deletions
diff --git a/tests/run-coverage/overflow.coverage b/tests/run-coverage/overflow.coverage index 950437591..2d60316e2 100644 --- a/tests/run-coverage/overflow.coverage +++ b/tests/run-coverage/overflow.coverage @@ -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|} |