Closed cceckman closed 2 years ago
Managed to get this running under the VS code debugger. This seems to be landing in this function.
Stepping through, I see remoteLocalPaths
is an empty array []
- I haven't configured the remotePathResolve
property. But the debugger still seems to step into the branch that uses remoteLocalPaths
; remoteFragment
and localFragment
are undefined
, according to the debugger.
All that shakes out fine, oddly enough, for the first several iterations. Eventually, we hit an iteration where fileName
is undefined
. I see this in checkSection
's first argument:
{
lines: {
found: 816,
hit: 0,
details: [
{
line: 283,
hit: 0,
},
... many more ...
],
},
functions: {
hit: 0,
found: 136,
details: [
],
},
branches: {
hit: 0,
found: 0,
details: [
],
},
}
Bumping back up the stack to findSectionsForEditor
, it looks like one of the sections (the last) has the property file: "/rustc/7737e0b5c4103216d6fd8cf941b7ab9bdbaace7c/library/std/src/thread/local.rs"
- which isn't a real file on disk. But that doesn't look like it would apply in this case; here, we actually
Is the LCOV file ill-formed? (If so, I can take that up in Rust fora - I may not be putting it together properly!)
On the coverage-gutters
side, is this the proper / most graceful way to handle this error? FWIW, the watch tooltip just reported "no coverage"; it didn't report a more verbose error, and none of the coverage showed from any file.
@cceckman Thank your for submitting a ticket and the evaluation of the issue!
I'm afraid I don't have a minimal-viable-reproducing example, but any of the lcov files I've managed to get out of this repository have the same stack trace. (Private repository so far- sorry! I've been trying to get a minimal reproducible example but no such luck yet.)
No worries on this front as even a ticket can be a good place for us to start looking at the issue 🤔.
I'm afraid I'm not super familiar with debugging VS Code extensions - any pointers to help get the relevant information for this? (I see these docs and may be able to make some time to give it a try.) Thanks for this lovely extension! What's the best way for me to get more debug info on this?
I am glad you enjoy the extension and were able to get the local debugging working (you were on the right track with the url above).
On the coverage-gutters side, is this the proper / most graceful way to handle this error? FWIW, the watch tooltip just reported "no coverage"; it didn't report a more verbose error, and none of the coverage showed from any file.
You are correct here that the error is producing a state where the extension sees the whole coverage as invalid (thus the no coverage mention in the tooltip). Ideally it should log the "bad" section and move along with consuming all the other good sections that are valid lcov... 🤔 .
I see you put up a PR as well so I can take a look there next!
I believe this has been fixed with #365 (Nice work there!).
With this lcov.info.gz file (uncompressed) in my repository,
coverage-gutters
provides the following output in the VS Code "output" pane- some initial output elided:I'm afraid I don't have a minimal-viable-reproducing example, but any of the
lcov
files I've managed to get out of this repository have the same stack trace. (Private repository so far- sorry! I've been trying to get a minimal reproducible example but no such luck yet.)The
lcov.info
file above is generated from a Rust integration test binary (built with 1.60's new-C instr-coverage
flag), then running theprofraw
file throughllvm-profdata
andllvm-cov
. Same behavior with unit test binaries, though.I'm afraid I'm not super familiar with debugging VS Code extensions - any pointers to help get the relevant information for this? (I see these docs and may be able to make some time to give it a try.)
Thanks for this lovely extension!
What's the best way for me to get more debug info on this?