Is there a problem with the results?

[heisen-li]

Q1：There are large sections of code that are not detected, either red or green.

example test file: ./rand/rand_chacha/src/guts.rs: L108-L127

Q2:Shows that there are four branches here, but there is no response test. But I don't see branches in the code.

example test file: ./rand/src/rngs/mock.rs

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=cb412e3f2dc101799853216a75604f38

[corebreaker]

Yes, me too, block close are covered, it should not be. Maybe cause the droping.

[marco-c]

Are you using gcov-based coverage or source-based coverage?

For Q1, it's probably because of inline.

[corebreaker]

Even if it's caused by something, in any language, block close should not be in coverage result. Closing a block is an element of the structuration of the language.

We cover Rust code not the assembly generated.

[marco-c]

Oh actually it is unrelated to inlining, I think it's simply that those functions are only built on big endian and you are building for a little endian target.
Those functions, effectively, are just like comments for your target.

[marco-c]

Even if it's caused by something, in any language, block close should not be in coverage result. Closing a block is an element of the structuration of the language.

There are likely some instructions behind the block close. It's not really related to grcov though, this kind of thing is decided by the implementation of code coverage in the Rust compiler itself.

[corebreaker]

So what a pity that assembly code is covered, and finally i can't use grcov to cover only the Rust code without the assemby.

[heisen-li]

I submitted more detailed information here.rust-lang/rust#91661

[heisen-li]

Are you using gcov-based coverage or source-based coverage?

For Q1, it's probably because of inline.

I know that the source-based approach does not support branch coverage. However, if branch coverage is not supported, 4 branches shouldn’t be shown here, right?

In addition, I think it is not the reason for inlining, it may be because of conditional compilation.
In the issue I mentioned, one of the same two functions was detected and the other was not.
rust-lang/rust#91661

[Mingun]

rust-lang/rust#91661 is closed, but coverage results still looks strange in some cases:

1. sometimes comments shows as covered/non-covered (they should never fall to either of these categories)
2. sometimes coverage report seems to shifted one line below
3. sometimes the coverage highlight lines that does not contains executable code around it
4. sometimes lines looks just random marked

For example, https://app.codecov.io/gh/tafia/quick-xml/blob/master/src/de/mod.rs:

I use source-based coverage, the full script here: https://github.com/tafia/quick-xml/blob/13d79c0f373172c86d89b009ebfec8055dacc7b1/.github/workflows/rust.yml

Don't known either, it is wrong data in the coverage report or just in the visualization