Open vmiklos opened 2 years ago
An observation I had when looking into a similar issue in my code is that sometimes adding a // ...
comment at the end of the false uncovered line magically gets it removed from cobertura.xml
(instead of having it exist with hits=0
). I immediately tried it out on this minimal example but no, this doesn't happen here. However I swear do see this effect it in my non-trivial, owned-by-employer code. I just tested and re-tested this. Some strange butterfly effect on the compiler?
Rather than raise a new issue, I'm pretty sure I've got the same type of problem occurring to me. I wrote it up on StackOverflow on the assumption that I was at fault.
Running code in the debugger it seems like this might not be tarpaulin's fault as such, but rather that the line information emitted by the Rust compiler itself is inaccurate. If this is the case the issue should be opened in rustc, I guess?
I think a large aspect of the compilation stage involving this is likely in LLVM. Either way it's not something I think could provide a stable interface, and the rustc advice might be use just use the llvm coverage built in. There are some approaches for most of the issues though:
For think problem I think the best solution is just to add to the source analysis module to get the for expressions to be registered as a single logical line which I will make a note of to do before the next release! (I could try milestone issues but I forget about them)
I assume that llvm coverage will solve this: if I understand correctly, then the instrument-coverage
switch will be stabilized in the next rust release and cargo llvm-cov
does not show uncovered lines for the problematic input from the top of this issue.
I experienced what I believe is this same issue when a tuple was broken across lines. Private repo; apologies for not being able to link directly. Image below:
Here, the tuple (Status::Unauthorized, AuthorizationError::OBONotAllowed,)
is passed to Outcome::Failure
(in the Rocket framework fwiw), and Tarpaulin marks only one line -- the first element of the tuple -- as uncovered.
My immediate need for this is gone. Do you prefer to keep the issue open (since it's still a bug) or OK to close this, so you spend your time on issues which are useful to fix in practice?
Well, I for one would still like to see more stable output, if possible.
Hi,
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.
Version:
Thanks!