Open c-to-the-l opened 2 years ago
So usually people are using 3rd party libraries like prost-build to generate code into the OUT_DIR
which is covered by that libraries tests and don't want it included in the results, especially if it's fickle to changes between compilation or unformated code dumped onto a single line.
Also, previous compilations may have a different OUT_DIR
that doesn't get cleaned up meaning those files could be picked up erroneously by tarpaulin and added to results. I could add a flag with something like --include-generated-code
to allow these to be included into results, the issue then is handling stale OUT_DIR
s versus ones that are there from previous builds and aren't regenerated :thinking:.
Also PRs are welcome and I'll happily provide guidance as I'm not sure when I'll get round to working on this :eyes:
Describe the Bug
Possibly this is my own misunderstanding of features, but I (and friends) have scoured the documentation and cannot see how to approach this problem. If I've missed something in the documentation, I can only apologise in advance.
For projects that generate code using
build.rs
and output generated code into$OUT_DIR
(as recommended by the Cargo book), generated code is not/cannot be included in the coverage statistics for that project.Generating code directly into
src/
can fix the issue, however this is not considered good rust practice, and it would be better if there was some way to specify additional source directories to be considered for coverage.In the example below, code generators output code into the directory specified by the env variable
$OUT_DIR
, which is the "correct" location for intermediate files in the build process, however it is not possible to (or not clear how to) have the tarpaulin coverage account for these files.To reproduce
Here I will provide two examples, which produce different results, despite being ostensibly based on the same code -
Code generator, incomplete code statistics
Using the following example code, where
build.rs
produces code that is then included bymain.rs
and used by tests:Produces the following tarpaulin output:
Code in-line, complete code statistics
In this second example, you can see that tarpaulin correctly picks up all 18 lines of code, whereas the first example only states 5 lines of code, of which 2 lines are tested.
Expected Behaviour
Expected behaviour would be that the
% coverage
andlines covered
would be similar or identical for the two examples above, or that it would be possible to enable this behaviour via a flag or configuration parameter intarpaulin.toml
.