Inconsistent coverage reports with files with 0% coverage

[Adam-Gleave]

When generating test coverage for a module that is placed behind a feature gate, the source file is omitted from the coverage report unless at least one function has been used in a test. This seems strange, since files that are not behind features are included with 0% test coverage.

Coverage is generated using the steps in the source-based coverage guide, including passing --all-features to cargo test and cargo cov (although I'm unsure if the latter is necessary).

For example, we have an io feature in our codebase. This feature enables the use of the io module:

#[cfg(feature = "io")]
mod io;

If we try and generate a coverage report without making use of anything in this module, but with --all-features enabled, the source file is not included:

genhtml coverage/coverage.info --legend --title="Coverage" --output-directory=coverage
Processing file src/lib.rs
Processing file ...

# `io.rs` is not processed

When we add a test function that uses some element of the io module, it gets included:

genhtml coverage/coverage.info --legend --title="Coverage" --output-directory=coverage
Processing file src/lib.rs
Processing file ...
Processing file src/io.rs

But this is now counted as 100% coverage, although only a couple of lines of code are utilised in the test.

This seems very strange, since we have another file (error.rs) that is not behind any features, and always shows up in coverage results, even though coverage of this file is 0%.

Also, if the #[cfg(feature = "io")] directive before the module include is removed, the problem still persists. It seems very inconsistent, and I'm not quite sure why this is all happening!

Using rustc v1.52.1, on the nightly channel.

[richkadel]

I don't have enough information in this report to understand the problem. Can you provide an MCVE?

-Z instrument-coverage is generally not aware of features. Whatever code actually gets parsed and compiled is passed through the coverage instrumentation. By that time, most features have already been handled.

When you talk about "file coverage", without really understanding the issue, my guesses may be way off base.

But (guessing) one possible factor is "unused function coverage". You could try -Z instrument-coverage=except-unused-functions (or except-unused-generics).

If adding one of those options makes your results more consistent, that's a good clue as to what's going on.

If the file is only processed under certain circumstances, the default is to generate coverage of all known unused functions (parsed but not called).

If the compiler is able to decide a file is not used at all, it may be able to skip the file, in which case there would be no coverage, because nothing in the file would be known to coverage during the code generation step.