Summary:
That allows to get the same data as produced by "llvm-cov report",
but in JSON format, which is better for further processing by end users.
Reviewers: vsk
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D41085
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320435 91177308-0d34-0410-b5e6-96231b3b80d8
There's a bug in the way the line and region summary objects are merged.
It would have been less likely to occur if those objects kept some data
private.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313416 91177308-0d34-0410-b5e6-96231b3b80d8
The "NotCovered" fields in the region and line summary structs are
redundant. We should remove them to make the code clearer.
As a follow-up, the "NotCovered" entries should be removed from the
reports as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313415 91177308-0d34-0410-b5e6-96231b3b80d8
When we load coverage data from multiple objects, we don't have a way to
attribute a source object to a function record. Printing out the object
filename next to the source filename is already not very useful: soon,
it'll actually become misleading. Stop printing out the filename now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285043 91177308-0d34-0410-b5e6-96231b3b80d8
We used to append filenames into a vector of std::string, and then
append a reference to each string into a separate vector. This made it
easier to work with the getUniqueSourceFiles API. But it's buggy.
std::string has a small-string optimization, so you can't expect to
capture a reference to one if you're copying it into a growing vector.
Add a test that triggers this invalid reference to std::string scenario,
and kill the issue with fire by just using ArrayRef<std::string>
everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282281 91177308-0d34-0410-b5e6-96231b3b80d8
Test that Windows path separators are escaped properly. Add a round-trip
test to verify the JSON produced by the exporter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276832 91177308-0d34-0410-b5e6-96231b3b80d8
This enables users to export coverage information as portable JSON for use by
analysis tools and storage in document based databases.
The export sub-command is invoked just like the others:
llvm-cov export -instr-profile path/to/foo.profdata path/to/foo.binary
The resulting JSON contains a list of files and functions. Every file object
contains a list of segments, expansions, and a summary of the file's region,
function, and line coverage. Every function object contains the function's name
and regions. There is also a total summary for the entire object file.
Changes since the initial commit (r276813):
- Fixed the regexes in the tests to handle Windows filepaths.
Patch by Eddie Hurtig!
Differential Revision: https://reviews.llvm.org/D22651
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276818 91177308-0d34-0410-b5e6-96231b3b80d8
This enables users to export coverage information as portable JSON for use by
analysis tools and storage in document based databases.
The export sub-command is invoked just like the others:
llvm-cov export -instr-profile path/to/foo.profdata path/to/foo.binary
The resulting JSON contains a list of files and functions. Every file object
contains a list of segments, expansions, and a summary of the file's region,
function, and line coverage. Every function object contains the function's name
and regions. There is also a total summary for the entire object file.
Patch by Eddie Hurtig!
Differential Revision: https://reviews.llvm.org/D22651
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276813 91177308-0d34-0410-b5e6-96231b3b80d8
