Tarpaulin is a code coverage reporting tool for the Cargo build system, named

for a waterproof cloth used to cover cargo on a ship


Tarpaulin is a code coverage reporting tool for the Cargo build system, named for a waterproof cloth used to cover cargo on a ship. Currently, tarpaulin provides working line coverage and while fairly reliable may still contain minor inaccuracies in the results. A lot of work has been done to get it working on a wide range of projects, but often unique combinations of packages and build features can cause issues so please report anything you find that's wrong. Also, check out our roadmap for planned features.

Tarpaulin only supports x86_64 processors running Linux. This is because instrumenting breakpoints into executables and tracing their execution requires processor and OS specific code. It is a goal when greater stability is reached to add wider system support, however this is sufficient to run Tarpaulin on popular CI tools like Travis.

It can also be run in Docker, which is useful for when you don't use Linux but want to run it locally, e.g. during development. See below for how to do that.

Below is the help-text for a thorough explanation of the flags and features available:

Note on tests using signals

If your tests or application make use of unix signals they may not work with tarpaulin. This is because tarpaulin relies on the sigtrap signal to catch when the instrumentation points are hit. The --forward option results in forwarding the signals from process stops not caused by SIGSTOP, SIGSEGV or SIGILL to the test binary.


Below is a list of features currently implemented. As Tarpaulin loads binary files into memory and parses the debugging information, different setups could lead to coverage not working. In this instance, please raise an issue detailing your setup and an example project and I'll attempt to fix it (please link us to a repo and the commit containing your project and paste the verbose output).

  • Line coverage
  • Full compatibility with cargo test CLI arguments
  • Uploading coverage to https://coveralls.io or https://codecov.io
  • HTML report generation and other coverage report types
  • Coverage of tests, doctests, benchmarks and examples possible
  • Excluding irrelevant files from coverage
  • Config file for mutually exclusive coverage settings (see Config file section for details)



Tarpaulin is a command-line program, you install it into your linux development environment with cargo install:

Tarpaulin used to rely on Cargo as a dependency and then require an ssl install as well as other libraries but now it uses your system cargo simplifying the installation and massively reducing the install time on CI.

When using the Nix package manager, the nixpkgs.cargo-tarpaulin package can be used. This ensures that tarpaulin will be built with the same rust version as the rest of your packages.

You can also use cargo-binstall:

Environment Variables

When tarpaulin runs your tests it strives to run them in the same environment as if they were ran via cargo test. In order to achieve this it sets the following environment variables when executing the test binaries:

  • RUST_BACKTRACE - When --verbose flag is used
  • CARGO_MANIFEST_DIR - Path to Cargo.toml From --root | --manifest-path or guessed from the current or parent directory
  • CARGO_PKG_NAME - From Cargo.toml
  • CARGO_PKG_AUTHORS - From Cargo.toml
  • CARGO_PKG_VERSION - From Cargo.toml
  • LLVM_PROFILE_FILE - Used for LLVM coverage

Cargo Manifest

In order for tarpaulin to construct the Cargo environment correctly, tarpaulin needs to find Cargo.toml by either:

  • Using --root or --manifest-path or
  • By invoking Cargo from the current working directory within the project holding Cargo.toml manifest or
  • By invoking Cargo from a sub-directory within the project

If Cargo does not find any Cargo.toml from using either of above methods the run will error "cargo metadata" and exit.

Several RFCs are open in rust-lang to expose more of these directly in order to avoid the issues arising out of this.

Command line

To get detailed help on available arguments when running tarpaulin call:

Currently no options are required, if no root directory is defined Tarpaulin will run in the current working directory.

Below is a Tarpaulin run utilising one of our example projects. This is a relatively simple project to test and if you check the test, you can see the output correctly reports the lines the test hits.

Tarpaulin can also report the change in coverage for each file between runs. If the tests were updated in the previous example to cover all the lines we would expect the following output.

Hint: if using coveralls.io with travis-ci run with the options --ciserver travis-ci --coveralls $TRAVIS_JOB_ID. The coveralls.io repo-token is mainly designed for private repos and it won't generate a badge for the coverage results submitted (although you can still see them on the coveralls web interface). For an example of a project using Tarpaulin, you can check out my crate keygraph-rs.

Ignoring code in files

Before tarpaulin 0.13.4 you could ignore code in blocks with #[cfg_attr(tarpaulin, skip)] this has changed with 0.13.4 and onwards and the new instructions are described below. If you get compiler errors mentioning unknown attribute skip use the --avoid-cfg-tarpaulin flag, this affects a small number of users as it wasn't a largely adopted feature so also look to updating your code or seeing if any of your dependencies are out of date.

Tarpaulin allows you to ignore modules or functions using attributes. Below is an example of ignoring the main function in a project:

However, the skip attribute only allows you to exclude code from coverage it doesn't change the code present in the binaries or what tests are ran. Because of this, --cfg=tarpaulin is used when building your project for Tarpaulin allowing you to also conditionally include/exclude code from compilation entirely. For example to have a test that isn't included in the test binaries when built with tarpaulin and cannot be ran just do:

If you still want the test included in the binary just ignored by default you can use:

There is also nightly support for using tool attributes with tarpaulin for skip. For example:

Continuous Integration Services

Tarpaulin aims to be easy to add to your CI workflow. With well tested support for Travis-CI it also supports sending CI specific meta-data to coveralls.io for Circle, Semaphore, Jenkins and Codeship (though only Jenkins has been tested).

You can also use Tarpaulin on Azure, check out crate-ci/azure-pipelines for an example config.

Travis-ci and Coverage Sites

The expected most common usecase is launching coverage via a CI service to upload to a site like codecov or coveralls. Given the built in support and ubiquity of travis-ci it seems prudent to document the required steps here for new users. To follow these steps you'll first need a travis-ci and a project setup for your coverage reporting site of choice.

We recommend taking the minimal rust .travis.yml, installing the libssl-dev dependency tarpaulin has and then running Tarpaulin with the version of rustc you require. Tarpaulin is installed in before_cache to allow it to be cached and prevent having to reinstall every Travis run. You can also replace cargo test with a verbose run of tarpaulin to see the test results as well as coverage output.

Tarpaulin is ran after success as there are still some unstable features which could cause coverage runs to fail. If you don't rely on any of these features you can alternatively replace cargo test with a call to cargo tarpaulin.

For codecov.io you'll need to export CODECOV_TOKEN are instructions on this in the settings of your codecov project.

If you rely on certain nightly features you may need to change the before_script to before_cache to force tarpaulin to reinstall each time. However, if it can be avoided it will speed up your CI runs.

Alternatively, there are the prebuilt docker images or the travis-install shell script. The travis-install script will install the latest tagged release built on travis to your travis instance and significantly speeds up the travis builds. You can install via that script using bash <(curl https://raw.githubusercontent.com/xd009642/tarpaulin/master/travis-install.sh).

The prebuilt binary is built using github actions ubuntu:latest image, because of this it doesn't work on xenial or trusty, but it works on bionic. You should still keep the rest of the recommended travis settings.

GitHub Actions

File .github/workflows/coverage.yml Example how to run coverage within docker with seccomp in GitHub Actions and push the result to <codecov.io>.


To run tarpaulin on CircleCI you need to run tarpaulin in docker and set the machine flag to true as shown below:

Gitlab Pipelines

To get the coverage results showing up in your Gitlab pipelines add the following regex to the Test coverage parsing section in the CI/CD settings.

Or add the regex to the job definition in .gitlab-ci.yml:

Gitlab can show coverage information in the diff of a merge request. For that, use

and generate a cobertura.xml as described under Pycobertura.

For installation add cargo install cargo-tarpaulin -f to the script section.


Tarpaulin has builds deployed to docker-hub, to run Tarpaulin on any system that has Docker, run this in your project directory:

This builds your project inside Docker and runs Tarpaulin without any arguments. There are also tags available for the latest version on the develop branch in stable or nightly. And versions after 0.5.6 will have the latest release built with the rust stable and nightly compilers. To get the latest development version built with rustc-nightly run the following:

Note that the build might fail if the Docker image doesn't contain any necessary dependencies. In that case, you can install dependencies before, like this:

Config file

Tarpaulin has a config file setting where multiple coverage setups can be encoded in a toml file. This can be provided by an argument or if a .tarpaulin.toml or tarpaulin.toml is present in the same directory as the projects manifest or in the root directory that will be used unless --ignore-config is passed. Below is an example file:

Here we'd create three configurations, one would run your tests with feature_a enabled, and the other with the tests built in release and both feature_a and feature_b enabled. The last configuration uses a reserved configuration name report and this doesn't result in a coverage run but affects the report output. This is a reserved feature name and any non-reporting based options chosen will have no effect on the output of tarpaulin.

For reference on available keys and their types refer to the CLI help text at the start of the readme or src/config/mod.rs for the concrete types if anything is unclear. For arguments to be passed into the test binary that follow -- in tarpaulin use args in the toml file.

Setting the field config will have no effect on the run as it won't be parsed for additional configuration.

For the flags --lib, --examples, --benches, --tests, --all-targets, --doc, --bins use the run-types entry in the config file.

Extending Tarpaulin

There are some tools available which can extend tarpaulin functionality for other potential user needs.

Procedural Macros

Normally, Tarpaulin can't report on code coverage within the code for a procedural macro. You'll need to add a test that expands the macro at run-time in order to get those stats. The runtime-macros crate was made for this purpose, and its documentation describes how to use it with Tarpaulin.


pycobertura is a python library for working with cobertura reports. It offers a report diffing tool as well as its own report implementations.

To generate a cobertura.xml simply run the following tarpaulin command:

Then install pycobertura with pip and execute the desired command.

As tarpaulin doesn't allow you to change the name of the generated cobertura report be mindful of this if diffing reports between multiple commits.

Issues and Contributing

Issues, feature requests and pull requests are always welcome! For a guide on how to approach bugs found in Tarpaulin and adding features please check CONTRIBUTING.

Rust 1.23 introduced a regression in the compiler affecting tarpaulin's accuracy. If you see missing lines or files, check your compiler version.


  • Branch coverage for tests
  • Condition coverage for tests
  • MCDC coverage reports
  • LLVM coverage support
  • Support for embedded targets
  • OSX support
  • Windows support


Tarpaulin is currently licensed under the terms of both the MIT license and the Apache License (Version 2.0). See LICENSE-MIT and LICENSE-APACHE for more details.


Collection of the latest Issues



Comment Icon0

In my CI environment I'm making use of multistaged Docker files to cache dependencies with cargo chef. As my integrationt tests depend on some external resources I do not execute them within my Docker build but still would like to build the tarpaulin binary in there.

How can I achieve that?



Comment Icon0

Describe the bug

Mac with M1Chip, Installed Focal Ubuntu Desktop and tried running the following -

"cargo install cargo-tarpaulin" in terminal

received the following errors -

error[E0412]: cannot find type Persona in this scope --> /home/songy/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-tarpaulin-0.20.1/src/process_handling/linux.rs:25:26 | 25 | const ADDR_NO_RANDOMIZE: Persona = 0x004_0000; | ^^^^^^^ not found in this scope

error[E0412]: cannot find type Persona in this scope --> /home/songy/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-tarpaulin-0.20.1/src/process_handling/linux.rs:26:20 | 26 | const GET_PERSONA: Persona = 0xFFFF_FFFF; | ^^^^^^^ not found in this scope

error[E0412]: cannot find type Persona in this scope --> /home/songy/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-tarpaulin-0.20.1/src/process_handling/linux.rs:75:25 | 75 | fn personality(persona: Persona) -> nix::Result<c_int> { | ^^^^^^^ not found in this scope

error[E0425]: cannot find value INT in this scope --> /home/songy/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-tarpaulin-0.20.1/src/process_handling/breakpoint.rs:60:21 | 60 | intdata |= (INT << self.shift) as i64; | ^^^ not found in this scope

Some errors have detailed explanations: E0412, E0425. For more information about an error, try rustc --explain E0412. error: could not compile cargo-tarpaulin due to 4 previous errors warning: build failed, waiting for other jobs to finish... error: failed to compile cargo-tarpaulin v0.20.1, intermediate artifacts can be found at /tmp/cargo-installkkBgJi



Comment Icon2

I'm trying to set up & configure tarpaulin under GitHub Actions with Codecov. At first, the only problem was that my binary crate wasn't marked as covered despite being tested by an integration test; then, I found the --follow-exec option. Unfortunately, if I pass this option to tarpaulin (using v0.20.1 on Rust stable, beta, & nightly), it segfaults when running the binary crate tests.

Here is my GitHub Actions workflow in which I run tarpaulin:

and here is a link to the segfaulting runs: https://github.com/jwodder/ghrepo-rust/actions/runs/2632179108.



Comment Icon0

Describe the bug We have a Github repository with code coverage run through tarpaulin. A new PR results in a failing CI with the following message: "Jun 03 10:19:23.427 ERROR cargo_tarpaulin: Failed to compile tests! Error: main: linking with clang failed: exit status: 254"

We can reproduce this only in the Github CI. On our local machines everything works as it should. Also the "cargo test" tasks still work fine on the Github CI.

The issue appears in this commit where we use a combination of two macros to generate implementations of generic code for enum variants.

  • how can we identify the problem which causes tarpaulin to fail?
  • Is there a known issue with (lots of) generated code?
  • is there a known issue with Github CI runners?

To Reproduce We can only reproduce the issue on the Github CI. Tarpaulin prints:

For some (unknown) reason it worked once when we changed the tarpaulin timeout from 120 to 240. We tried a larger (and the same) timeout but the CI task keeps failing.

Expected behavior It would be very helpfull to see the previous errors or another indication what went wrong.



Comment Icon1

Describe the bug

Hi there,

Sometimes a structure initialization included in a coverage report but only partially. Whereas sometimes it's not included at all.



I did tried to reproduce it by a minimal example but didn't managed easily.

Sorry if it's a duplicate.

Expected behavior

I suppose the report must be consistent in approach?



Comment Icon0

Describe the bug I use tarpaulin in a bit of an abusive way (as noted here) - I want a breakdown of coverage per test and so i get cargo to give me a list of tests and call tarpaulin for each of those tests. This works fine but i recently noticed that the process of filtering out the excluded tests is very slow.

Example I can't provide the code to generate this (though if required i can spend some time making a non-private example) but i can provide an output showing the timestamps posted below.

We do have a weird test setup where we set a bunch of stuff to ignored and then trigger them 'manually' by specifying the test file and using the ignored flag.

The command that was used to generate the data below is

Two things I don't understand: why some appear repeated and why the filtering is slow.

Expected behavior I would have expected, perhaps naively, that the filtering would be quick. In the above example the filtering is comparable in duration to the test itself.

Possible workaround As noted i know which file each test lives in from getting cargo to list all the tests, is there some way i can feed this information to tarpaulin to tell it to only look in one of the test binaries for each test?

Thanks! Z



Comment Icon0

You can set a failure-threshold per config, however only the state of the last one is reported as an error. When creating this it was intended to be a global config on reporting or a single config file (so global config). However, for a specific configuration (i.e. feature set) a different threshold may be required. Make any failure-threshold failure on a config entry fail the run. Noticed in https://github.com/xd009642/tarpaulin/pull/993



Comment Icon3

Describe the feature Simply said, I would like to use cargo nextest Instead of cargo test

Why? So I love cargo tarpaulin But for running test cargo nextest Is just simply much faster and has things like retires which makes work just more efficient.

Some Ressources:

Now I haven’t dug into the cargo-tarpaulin Code as it doesn’t seem like a 30 min thing to do, so my general questions are. Would it be hard to integration something like this? Do you have any code parts or points to watch out if I would have a go on that?

As it seems —command Can be set to build Or test, how big would the effort be to have a third option?



Comment Icon3

When using a doctest in a README.md file marked with should_panic, tarpaulin executes it but does not seem to parse out the should_panic as it ends in failure. Removing the should_panic flag (and removing the failing assert) and it passes as expected.

My repo is very small so can probably be used as a reproducible sample:

README: https://github.com/nu11ptr/assert_unordered/blame/master/README.md#L25

Code that triggers README test: https://github.com/nu11ptr/assert_unordered/blob/master/src/lib.rs#L40

I was expecting (or at least hoping) the test would pass like it does when executed with cargo test



Comment Icon3

Hi @xd009642 Thank you for tarpaulin.

I was trying to get into DWARF a little bit (not successfully :disappointed: yet) And I was experimenting with ddbug a bit (also uses gimli). And I noticed that it doesn't captures columns in function definitions. Meaning DW_AT_decl_column is not generated. I did verified it via objdump as well.

And then I started to question myself well how tarpaulin does a match between source code and binary code.

From what I've been able to understand its done only via lines and path correct?

The implications of all of these is the following.

Describe the bug

When cargo fmt isn't applied there's a chance that tarpaulin may not cover all functions?

I would expect that both cases have the same coverage. (I might be wrong here though)

The issue I am trying to address is not actually about the coverage.

But it seems like there's a chance that tarpaulin might is not able to locate a correct function which is called in case there's more then 2 functions on the same line because of the issue I described above.

Not sure it might be a duplicate of some kind.

Thanks one more time. Take care.



Comment Icon0


I have some directories that I have intentional excluded from my workspace but I still want to account for the code coverage. Is there an option to do so? I reviewed the command line arguments with no luck. In the example below I would like to run code coverage for member3 and member4. Do I have to run the coverage separately? If so, how?


Thanks in advance. 🙏🏻



Comment Icon4

Hello everyone,


We recently updated our rust stack to 1.59, everything compile just fine. But when we try to collect coverage using Tarpaulin, compilation errors are occurring.

We get the infamous "Error: build-script-build: linking with cc failed: exit status: 1".

Sometimes it fails to compile "log" from rust-lang, sometimes futures-rs or even futures-utils. The bug doesn't seems to target a precise crate but always happen. We use tarpaulin on CI and our local machines (all of them using linux x64).

To Reproduce The smallest thing I did to reproduce was having a Cargo.toml containing the following :

I have only one file in /src which is lib.rs and is empty. I call tarpaulin with the following command : cargo tarpaulin --avoid-cfg-tarpaulin --skip-clean --frozen --ignore-tests -o Xml -o Lcov --workspace --all-features --verbose --line --debug

When we turn on debug and verbose on tarpaulin we get this kind of logs :

Expected behavior Compilation and collection of coverage



Comment Icon2

Thank you for this useful project.

My project’s test suite includes integration tests that can be enabled with feature miltertest-tests.

These tests use the external utility miltertest. miltertest can be installed on Debian and Ubuntu with apt install miltertest or apt install opendkim-tools.

When I try to run these tests with Tarpaulin, they time out after 60 seconds.

I tried with --follow-exec, too, but it didn’t help. I’m on Ubuntu 20.04 using Rust 1.59.0.



Comment Icon5

I've written a crate calloop-subproc that uses the Calloop event loop and async-process to manage subprocesses in an event loop. It's about 700 lines of code with 9 integration tests. In order to run the tests, the test binary has to build another test binary that can serve as the "thing to run as a subprocess" part of the tests.

Without tarpaulin, the tests take about 5s including the extra binary build. Under tarpaulin, they never finish. They don't seem to hang, however — I can gradually let more and more tests finish by increasing the timeout from 1m to 2m, to 10m, to an hour. So far, however, I have not found a long enough duration for the whole set of (9) tests to finish.

I have tried to create a minimal example, but without much luck. It really seems to be a result of the following factors used together:

  • the Calloop event loop
  • the async-process crate
  • test-time building

...and possibly other factors?

Nonetheless, my tarp-test project sort-of shows the problem, where a usually-20s test runs in 230s under tarpaulin (including the one-off build time). It certainly doesn't show the same magnitude of slowdown that the original project shows though.

I initially thought it was due to signals for subprocess management (kill, sigchld etc.) being blocked, but the tests themselves seem to actually work, so I doubt it's that after all.

I'll keep trying to see if I can identify a particular factor that's having such a disproportionate impact.



Comment Icon28

Describe the bug In some cases it appears using --follow-exec can cause test code to not run somehow.

To Reproduce https://github.com/boustrophedon/tarpaulin_missing_coverage/commits/master

The original problem I'm trying to solve is the following: I have tests in tests/ and examples in examples/ and I want to get combined coverage for all of them. If I just run cargo tarpaulin --tests --examples, the examples don't execute because the test runner is used to look for tests rather than execute the examples (related?). I've worked around this by adding a small test in each example that just calls main.

However, one of my example programs calls itself (which, as above, is actually the test runner process) as a subprocess and although it appears the processes are executing (e.g. if I intentionally throw a panic in one, the panic shows up), tarpaulin isn't catching that.

While investigating this I've found a minimal example that shows just by adding and removing the --follow-exec flag that the subprocess code isn't being called somehow.

Expected behavior The subprocess code should run, the file should be written to, and the CI step "Check file was actually created" should pass.

fails: https://github.com/boustrophedon/tarpaulin_missing_coverage/commit/9d91fb202ae08b575528e6aa13c3404e954cd0c9 succeeds: https://github.com/boustrophedon/tarpaulin_missing_coverage/commit/4e92bfe238d5391eac58f3c562b8316796cb4655



Comment Icon1

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 by main.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 and lines 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 in tarpaulin.toml.



Comment Icon1

https://github.com/jonhoo/openssh-rs/pull/26#issuecomment-1025285977 @jonhoo

Investigate the timeouts on openssh-rs, taking a look via the tarpaulin debug trace file it looks like each timed out test had a "vfork, but not each vfork has a corresponding fork event, then they all got a SIGCHLD stop and a continue and the test ended after that - which is probably the rustc test runner killing them :thinking:. Also there's a long running tid which gets some TryContinue's (so either tarpaulin got an event it's not sure about or it's a known fallible-continue).

Some pictures attached with text underneath about them

Screenshot from 2022-01-31 18-45-38

This is fairly early on, showing the long running branch with the TryContinue's every now and then. As well as one test completing and another running fine.

Screenshot from 2022-01-31 18-46-20

Another long running TryContinue but this one doesn't reappear, it happens kinda middle of the run... Bit odd we never hear from it again :thinking:

Screenshot from 2022-01-31 18-46-57

The vforks, only 11707 ends up with a fork child... Others strangely don't

Screenshot from 2022-01-31 18-47-19

End of the vforks and the final events tarpaulin gets



Comment Icon2

Describe the bug tarpaulin versions >0.16.0 crash on projects using mockito. That is, 0.16.0 works but all versions I have tested after that crash with a segfault. The tests built into the mockito crate itself are sufficient to trigger the issue. On my system (CentOS 7 with rustc and cargo versions 1.57), it is 100% reproducable.

To Reproduce Clone the repo and perform coverage test on mockito via:

The error output looks like:

Expected behavior tarpaulin tests should complete without error and produce a coverage report. This is what happens with 0.16.0, and the output looks like:



Comment Icon3

Does tarpaulin support collecting test coverage from wasm targets? specifically when using wasm-bindgen-tests.

When I run cargo tarpaulin with the --target wasm32-unknown-unknown arg. I get the following error:



System Details

Linux xxx 5.11.0-43-generic #47~20.04.2-Ubuntu SMP Mon Dec 13 11:06:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Rustc version

rustc 1.57.0



Comment Icon4

Describe the bug In my coverage report appears src/ui/hud/ability_icon.rs that doesn't used (it doesn't exists because ui module is under feature). Only this module from all my ui appears in my code coverage. I even tried to comment it out from the code just to be sure.

To Reproduce

  1. git clone https://github.com/gardum-game/gardum
  2. Comment out this line (it won't be compiled anyway, but just to be sure)
  3. cargo tarpaulin

You will see the mentioned module in coverage report, it happens always. Sorry for such big example, I just don't see the pattern why exactly this module triggers the issue.

Expected behavior I would expect to not have this module in code coverage.

Version: 0.19.0



Comment Icon1

The result I got after running is only the row coverage, which is not enough in my work. Branch coverage is in the roadmap, so is there a similar plan for function coverage?



Comment Icon6


Describe the bug rustfmt likes to wrap long lines to multiple shorter ones. At the same time, sometimes such wrapping causes tarpaulin to report false uncovered lines.

To Reproduce

Create Cargo.toml like this:

and src/lib.rs like this:

Finally run cargo tarpaulin -v.

Expected behavior

Current output:

Expected output: no uncovered lines. Note that in case

is folded into a single line, then tarpaulin correctly reports no uncovered lines.





Comment Icon0


So, it shouldn't be too hard to do this, in theory it's a case of finding the breakpoint instruction op codes and creating a cfg for INT for aarch64 with that opcode.

Potentially, the opcode will be >1 byte so potentially the opcode should be changed to [u8; 1] for x64 and [u8; N] and the breakpoint code altered to work with this. This is TBD though



Comment Icon2

Describe the bug

Spawning a process for an interactive main programm during integration testing and then communicating with it (e.g. via stdin/stdout) leads to falsely uncovered lines.

Same happens when similarly testing routes of a web server program (my original problem). However, there I even experience tarpaulin crashing ("Failed to get test coverage! Error: ESRCH: No such process"). Although I can imagine this having a similar cause, I should maybe open a separate issue?

To Reproduce



Running cargo tarpaulin --follow-exec


Distro: Ubuntu 20.04 Rustc version: 1.57.0-nightly (b69fe5726 2021-09-10)

Expected behavior

100% coverage


Find the latest versions by id

0.20.1 - May 24, 2022

0.20.0 - Mar 20, 2022

0.19.1 - Jan 16, 2022

0.19.0 - Dec 27, 2021

0.18.5 - Nov 05, 2021

0.18.4 - Nov 04, 2021

0.18.3 - Oct 24, 2021

0.18.2 - Sep 05, 2021

0.18.1 - Sep 03, 2021

0.18.0 - Jun 28, 2021

0.18.0-alpha3 - May 02, 2021

0.18.0-alpha2 - Apr 16, 2021

0.18.0-alpha1 - Feb 14, 2021

0.16.0 - Nov 02, 2020

0.15.0 - Oct 17, 2020

0.14.3 - Aug 31, 2020

0.14.2 - Jul 10, 2020

0.14.1 - Jul 01, 2020

0.14.0 - Jun 25, 2020

0.13.4 - Jun 23, 2020

0.13.3 - Jun 06, 2020

0.13.2 - May 25, 2020

0.13.1 - May 25, 2020

0.13.0 - May 24, 2020

0.12.4 - May 10, 2020

0.12.3 - Apr 16, 2020

0.12.2 - Apr 11, 2020

0.12.1 - Apr 09, 2020

0.12.0 - Apr 06, 2020

0.11.1 - Mar 13, 2020

Information - Updated Jul 22, 2022

Stars: 1.6K
Forks: 133
Issues: 62


A template for writing mods for Quest il2cpp games in Rust using cargo generate to clone the template:


Command line json text parsing and processing utility

parsing json compliant with rust and cargo

Command line json text parsing and processing utility

Clone this repo: git clone

If you don't have Rust and cargo-make installed,

Clone this repo: git clone

Rustup: the Rust installer and version management tool

To test that you have Rust and Cargo installed, you can run this in your terminal of choice: cargo --version

Rustup: the Rust installer and version management tool

Address generator in Rust

If you have Rust: cargo install gemgen

Address generator in Rust

cargo rssc - Rust scripts for crates building

will copy the template_basic into scripts_rssc folder

cargo rssc - Rust scripts for crates building

NES Emulator in Rust-WASM

Requires Rust with cargo, nodejs, and wasm-pack

NES Emulator in Rust-WASM

Terraformer Engine

A 3D game engine but completely in rust/std/cargo

Terraformer Engine

Rustup: the Rust installer and version management tool

To test that you have Rust and Cargo installed, you can run this in your terminal of choice: cargo --version

Rustup: the Rust installer and version management tool

OPM (Oxidized Package Manager) 📦

rust and cargo installed on your machine

OPM (Oxidized Package Manager) 📦

A Neofetch clone written in Rust

&nbsp;&nbsp;download and install Rust and Cargo using Rustup

A Neofetch clone written in Rust
Facebook Instagram Twitter GitHub Dribbble