Different coverage in free function vs associated methods

[unneon]

Tarpaulin 0.8.4 reports different coverage depending on whether the code is inside a free function or an associated method. Specifically, inside a free function a str::lines call is not included in the output at all, while in an associated method it is reported as missed. The following is a minimal example, originally found here:

struct S;

impl S {
    fn f(a: &str) {
        let _ = a
            .lines()
            .collect::<Vec<_>>();
    }
}

#[test]
fn t() {
    S::f("a\nb\n");
}

fn f(a: &str) {
    let _ = a
        .lines()
        .collect::<Vec<_>>();
}

#[test]
fn t() {
	f("a\nb\n");
}

Ubuntu 19.04, Linux 5.0.0-20-generic. Issue also occurs on Travis CI.
rustc 1.37.0-nightly (5f9c0448d 2019-06-25)

[jstasiak]

I think I've also bumped into this (both zero and unitx methods are used):

https://coveralls.io/builds/24447374/source?filename=src/lib.rs#L27

The full source code: https://github.com/jstasiak/raytracer/blob/818786af2ec9f7622abdb0c4ca1892a90d87a797/src/lib.rs#L19

[jstasiak]

Not sure if related, but in the following code one line is missing from the coverage and I'm only using free functions here:

pub fn fun1() -> i32 {
	1
}

pub fn fun2() -> i32 {
	1 + 1
}

#[test]
fn it_works() {
	let _ = fun1();
	let _ = fun2();
}

[xd009642]

If I had to guess I'd say fun1 is likely inlined by the compiler so doesn't show up as an instrumentable line whereas as fun2 contains an expression it's not inlined with the compiler flags as they are

[jstasiak]

I don't think it's gonna be inlined per se (as the default build is a debug one, I believe? I'm not adding any extra options to cargo tarpaulin invocation) but other than inlining I have zero idea what's going on here. I've found something interesting in cargo-asm output of those two functions though, may be of interest to you: gnzlbg/cargo-asm#129.

[unneon]

The inlining does seem to be the cause as confirmed by adding #[inline(never)], but the output is still interesting. Both .lines() calls in my example are still marked as missed, and in the other example, the line returning the 1 literal is marked as missed while 1+1 is not.

In the --debug tarpaulin output, these three lines are marked as "potentially uncoverable". In tarpaulin's sources I can see some logic responsible for ignoring some false positives, which probably means it just does not handle these cases. I am not familiar with the DWARF format though, so I don't know why it fails on these lines specifically and how to fix it.

[xd009642]

Closed in favour of #351