Closed john-w-phillips closed 2 years ago
Is this the same as #23 ? There is a suggested workaround in that issue that works at least for some usecases. I started working on a fix for issue 23 but I never got around to completing it. You could try it out here https://github.com/snogge/cov/commit/f3729b318e75a70313a1613994880cf41f6e4e38 and let me know if it works for you.
filename
is the coverage data file, for a source file /some/path/src/namespace_a/namespace_b/X.hpp
that would typically be /some/path/src/namespace_a/namespace_b/X.hpp.gcov
. And since file-name-sans-extension
only removes one extension, it would still be X.hpp
that is returned from cov--gcov-parse
.
You are bitten by #23. The fix I linked to in my last response might work for you, but it only fixes #23 for gcov. I'm working on a fix to only use absolute paths in the hash table and coverage data. This should fix #23 properly.
Duplicate of #23 .
The gcov parsing function,
cov--gcov-parse
, returns a cons-cell incompatible with the assoc statement incov--get-buffer-coverage
.Here is
cov--gcov-parse
:The
filename
variable is specifically created to not have an extension. So a file/some/path/src/namespace_a/namespace_b/X.hpp
will be in the alist as just "X". However,cov--get-buffer-coverage
after extracting the coverage alist from the structure in the hashtable, assocs it usingf-filename
, which includes the suffix, along with portions of the pathname:Issues of the path scheme that the code assumes the project must have aside, this has no chance of working with the gcov parser, unless I'm missing something? That's certainly possible.