Coverage information is wrong when using tracing
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
So found an interesting thing when developing cargo-tarpaulin and confirmed it exists also with cargo-llvm-cov and using the raw llvm tools. When #[tracing::instrument] is added to a function the function body is not included in the coverage instrumentation. This doesn't happen with #[tokio::main] and I'm yet to create a more minimal reproduction with a less intense proc macro.
Project setup:
cargo new --lib tracing-instrument
cargo add tracing
In src/lib.rs
use tracing::instrument;
#[instrument]
fn instrumented_function() {
println!("Hello");
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn is_it_hit() {
instrumented_function();
}
}
If you run something like cargo llvm-cov --html on this project you'll see only #[instrument] is marked as covered. If we comment out #[instrument] then the function signature, body and closing brace are marked as covered regions of codes.
This suggests to me there's something a bit wrong with the llvm instrumentation setup and how it interacts with procedural macros.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the minimal reproduction in src/lib.rs and run cargo llvm-cov --html, comparing the instrumented and uninstrumented versions. Then investigate how #[tracing::instrument] interacts with coverage instrumentation, using cargo-tarpaulin, cargo-llvm-cov, and the raw llvm tools as comparison points. Done means the function body receives correct coverage regions without regressing the #[tokio::main] case.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100