summaryrefslogtreecommitdiffstats
path: root/tests/run-coverage/overflow.coverage
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-05-30 03:59:35 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-05-30 03:59:35 +0000
commitd1b2d29528b7794b41e66fc2136e395a02f8529b (patch)
treea4a17504b260206dec3cf55b2dca82929a348ac2 /tests/run-coverage/overflow.coverage
parentReleasing progress-linux version 1.72.1+dfsg1-1~progress7.99u1. (diff)
downloadrustc-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.coverage126
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|}