about summary refs log tree commit diff
path: root/tests/coverage/overflow.rs
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2023-11-08 03:00:14 +0000
committerbors <bors@rust-lang.org>2023-11-08 03:00:14 +0000
commit91cfcb021935853caa06698b759c293c09d1e96a (patch)
treed5dd983288727ef2905faaea5636e416ac86766e /tests/coverage/overflow.rs
parent0d5ec963bb9f3e481bca1d0149d26f1688784341 (diff)
parent4e6f438d2ace2f5297cea2d3e331c6dccd4e18c2 (diff)
downloadrust-91cfcb021935853caa06698b759c293c09d1e96a.tar.gz
rust-91cfcb021935853caa06698b759c293c09d1e96a.zip
Auto merge of #117484 - Zalathar:tests, r=cjgillot
coverage: Unify `tests/coverage-map` and `tests/run-coverage` into `tests/coverage`

Ever since the introduction of the `coverage-map` suite, it's been awkward to have to manage two separate coverage test directories containing dozens of mostly-identical files.

However, those two suites were separate for good reasons. They have very different requirements (since only one of them requires actually running the test program), running only one suite is noticeably faster than running both, and having separate suites allows them to be blessed separately if desired. So while unifying them was an obvious idea, actually doing so was non-trivial.

---

Nevertheless, this PR finds a way to merge the two suites into one directory while retaining almost all of the developer-experience benefits of having two suites. This required non-trivial implementations of `Step`, but the end result works very smoothly.

---

The first 5 commits are a copy of #117340, which has been closed in favour of this PR.
Diffstat (limited to 'tests/coverage/overflow.rs')
-rw-r--r--tests/coverage/overflow.rs64
1 files changed, 64 insertions, 0 deletions
diff --git a/tests/coverage/overflow.rs b/tests/coverage/overflow.rs
new file mode 100644
index 00000000000..1c40771b274
--- /dev/null
+++ b/tests/coverage/overflow.rs
@@ -0,0 +1,64 @@
+#![allow(unused_assignments)]
+// compile-flags: -Coverflow-checks=yes
+// 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|}