Functions sometimes disappear from coverage under MIR opts `+Inline,+ConstProp`

[Zalathar]

(Note that this is almost certainly a bug in coverage, not in MIR opts.)

Consider this coverage report, produced by x test run-coverage --bless on a new test file:

   LL|       |#![feature(coverage_attribute)]
   LL|       |// compile-flags: --edition=2021 -Copt-level=0 -Zmir-opt-level=1 -Zmir-enable-passes=+Inline,+ConstProp
   LL|       |
   LL|      8|#[derive(Debug, PartialEq, Eq)]
   LL|       |struct Foo(u32);
   LL|       |
   LL|      1|fn eq_good() {
   LL|      1|    assert_eq!(Foo(1), Foo(1));
   LL|      1|}
   LL|       |
   LL|      1|fn eq_good_message() {
   LL|      1|    assert_eq!(Foo(1), Foo(1), "message");
                                             ^0
   LL|      1|}
   LL|       |
   LL|       |fn ne_good() {
   LL|       |    assert_ne!(Foo(1), Foo(3));
   LL|       |}
   LL|       |
   LL|       |fn ne_good_message() {
   LL|       |    assert_ne!(Foo(1), Foo(3), "message");
   LL|       |}
   LL|       |
   LL|      1|fn eq_bad() {
   LL|      1|    assert_eq!(Foo(1), Foo(3));
   LL|      0|}
   LL|       |
   LL|       |fn eq_bad_message() {
   LL|       |    assert_eq!(Foo(1), Foo(3), "message");
   LL|       |}
   LL|       |
   LL|      1|fn ne_bad() {
   LL|      1|    assert_ne!(Foo(1), Foo(1));
   LL|      0|}
   LL|       |
   LL|      1|fn ne_bad_message() {
   LL|      1|    assert_ne!(Foo(1), Foo(1), "message");
   LL|      0|}
   LL|       |
   LL|       |#[coverage(off)]
   LL|       |fn main() {
   LL|       |    eq_good();
   LL|       |    eq_good_message();
   LL|       |    ne_good();
   LL|       |    ne_good_message();
   LL|       |
   LL|       |    let _ = std::panic::catch_unwind(eq_bad);
   LL|       |    let _ = std::panic::catch_unwind(eq_bad_message);
   LL|       |    let _ = std::panic::catch_unwind(ne_bad);
   LL|       |    let _ = std::panic::catch_unwind(ne_bad_message);
   LL|       |}

All of these functions should look roughly the same in the coverage report, but instead three of them (ne_good, ne_good_message, eq_bad_message) are completely missing, despite the fact that they are all executed.

The problem also occurs under -Copt-level=2 or -Zmir-opt-level=3, but I narrowed it down to just -Zmir-opt-level=1 plus the Inline and ConstProp passes. If I reduce the MIR opt level to 0, or remove either of those passes, I get the expected output where all functions are reported correctly.

[Zalathar]

@rustbot label +A-code-coverage

[Zalathar]

Mysteriously, if I run the same test file in tests/coverage-map, the mappings seem fine.

So far I haven't tracked down the precise differences between affected binaries and unaffected binaries.

[Zalathar]

The above test file was the result of reducing a much more complicated test file (tests/run-coverage/issue-84561.rs), in which the entire test3 function disappears from coverage.

Unlike my simplified examples above, that test3 function contains a bunch of print statements and also is responsible for panicking out of the entire program, which seems to rule out problems based entirely on small functions with no other effects.

[Zalathar]

I tracked this down to the fact that the coverage_ids_info sometimes returns a max_counter_id that is less than the highest ID actually injected in an llvm.instrprof.increment intrinsic, in the presence of inlining.

Presumably what's happening is that counters are being optimized out of the function's body, even though they remain present in inlined form in other functions. I had assumed that that couldn't happen, but maybe they disappear after MIR opts conclude that no non-inlined form of the function is ever called.

EDIT: No, that's wrong; it turns out that map_data just wasn't censoring optimized-out counter IDs from expression operands.

[Zalathar]

OK, I think this is caused by the fact that map_data will emit expression operands containing counters that are not present in counters_seen.

[Zalathar]

Because I wasn't seeing anything missing/suspicious in the .cov-map files, I figured this might have something to do with llvm-cov.

I was able to apply printf debugging by:

• Adding #include <iostream> and std::cout << ... << std::endl; to the LLVM source to print extra information, which would then appear in the .cov-map files as part of the tool output.
• rm build/aarch64-apple-darwin/llvm/llvm-finished-building ; x build llvm to tell the build system to actually rebuild LLVM with my changes.