summaryrefslogtreecommitdiffstats
path: root/tests/coverage-map/status-quo/overflow.rs
diff options
context:
space:
mode:
Diffstat (limited to 'tests/coverage-map/status-quo/overflow.rs')
-rw-r--r--tests/coverage-map/status-quo/overflow.rs63
1 files changed, 0 insertions, 63 deletions
diff --git a/tests/coverage-map/status-quo/overflow.rs b/tests/coverage-map/status-quo/overflow.rs
deleted file mode 100644
index bbb65c1b3..000000000
--- a/tests/coverage-map/status-quo/overflow.rs
+++ /dev/null
@@ -1,63 +0,0 @@
-#![allow(unused_assignments)]
-// failure-status: 101
-
-fn might_overflow(to_add: u32) -> u32 {
- if to_add > 5 {
- println!("this will probably overflow");
- }
- let add_to = u32::MAX - 5;
- println!("does {} + {} overflow?", add_to, to_add);
- let result = to_add + add_to;
- println!("continuing after overflow check");
- result
-}
-
-fn main() -> Result<(), u8> {
- let mut countdown = 10;
- while countdown > 0 {
- if countdown == 1 {
- let result = might_overflow(10);
- println!("Result: {}", result);
- } else if countdown < 5 {
- let result = might_overflow(1);
- println!("Result: {}", result);
- }
- countdown -= 1;
- }
- Ok(())
-}
-
-// Notes:
-// 1. Compare this program and its coverage results to those of the very similar test `assert.rs`,
-// and similar tests `panic_unwind.rs`, abort.rs` and `try_error_result.rs`.
-// 2. This test confirms the coverage generated when a program passes or fails a
-// compiler-generated `TerminatorKind::Assert` (based on an overflow check, in this case).
-// 3. Similar to how the coverage instrumentation handles `TerminatorKind::Call`,
-// compiler-generated assertion failures are assumed to be a symptom of a program bug, not
-// expected behavior. To simplify the coverage graphs and keep instrumented programs as
-// small and fast as possible, `Assert` terminators are assumed to always succeed, and
-// therefore are considered "non-branching" terminators. So, an `Assert` terminator does not
-// get its own coverage counter.
-// 4. After an unhandled panic or failed Assert, coverage results may not always be intuitive.
-// In this test, the final count for the statements after the `if` block in `might_overflow()`
-// is 4, even though the lines after `to_add + add_to` were executed only 3 times. Depending
-// on the MIR graph and the structure of the code, this count could have been 3 (which might
-// have been valid for the overflowed add `+`, but should have been 4 for the lines before
-// the overflow. The reason for this potential uncertainty is, a `CounterKind` is incremented
-// via StatementKind::Counter at the end of the block, but (as in the case in this test),
-// a CounterKind::Expression is always evaluated. In this case, the expression was based on
-// a `Counter` incremented as part of the evaluation of the `if` expression, which was
-// executed, and counted, 4 times, before reaching the overflow add.
-
-// If the program did not overflow, the coverage for `might_overflow()` would look like this:
-//
-// 4| |fn might_overflow(to_add: u32) -> u32 {
-// 5| 4| if to_add > 5 {
-// 6| 0| println!("this will probably overflow");
-// 7| 4| }
-// 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|}