tests/run-make/coverage/overflow.rs

   1 #![allow(unused_assignments)]
   2 // expect-exit-status-101
   3
   4 fn might_overflow(to_add: u32) -> u32 {
   5     if to_add > 5 {
   6         println!("this will probably overflow");
   7     }
   8     let add_to = u32::MAX - 5;
   9     println!("does {} + {} overflow?", add_to, to_add);
  10     let result = to_add + add_to;
  11     println!("continuing after overflow check");
  12     result
  13 }
  14
  15 fn main() -> Result<(),u8> {
  16     let mut countdown = 10;
  17     while countdown > 0 {
  18         if countdown == 1 {
  19             let result = might_overflow(10);
  20             println!("Result: {}", result);
  21         } else if countdown < 5 {
  22             let result = might_overflow(1);
  23             println!("Result: {}", result);
  24         }
  25         countdown -= 1;
  26     }
  27     Ok(())
  28 }
  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|}