Instead of stripping the longest common prefix off of the filenames in a
report, strip out the longest chain of redundant path components. This
fixes the case in PR31982, where there are two files with the same
prefix, and stripping out the LCP makes things less intelligible.
llvm-svn: 296029
This commit makes llvm-cov avoid showing 0% (0/0) coverage for things
like file function coverage, etc. in reports and HTML output. This can happen
for files like headers that have macros but no functions. This commit makes
llvm-cov report - (0/0) instead.
rdar://29246480
Differential Revision: https://reviews.llvm.org/D26615
llvm-svn: 287539
Rework getLongestCommonPrefixLen() so that it doesn't access string null
terminators. The old version with std::mismatch would do this:
|
v
Strings[0] = ['a', nil]
Strings[1] = ['a', 'a', nil]
^
|
This should silence a warning from the MSVC runtime (PR30515). As
before, I tested this out by preparing a coverage report for FileCheck.
Thanks to Yaron Keren for the report!
llvm-svn: 282422
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.
llvm-svn: 282281
These are distinct statistics which are useful to look at separately.
Example: say you have a template function "foo" with 5 instantiations
and only 3 of them are covered. Then this contributes (1/1) to the total
function coverage and (3/5) to the total instantiation coverage. I.e,
the old "Function Coverage" column has been renamed to "Instantiation
Coverage", and the new "Function Coverage" aggregates information from
the various instantiations of a function.
One benefit of making this switch is that the Line and Region coverage
columns will start making sense. Let's continue the example and assume
that the 5 instantiations of "foo" cover {2, 4, 6, 8, 10} out of 10
lines respectively. The new line coverage for "foo" is (10/10), not
(30/50). The old scenario got confusing because we'd report that there
were more lines in a file than what was actually possible.
llvm-svn: 281875
This drops some redundant calls to get{UniqueSourceFiles,
CoveredFunctions}. We can figure out the right column widths without
re-doing this expensive work.
This isn't NFC, but I don't want to check in another binary *.covmapping
file with long filenames in it. I tested this locally on a project with
some long filenames (FileCheck).
llvm-svn: 281873
Treat filenames the same way in the text index as we do in the html
index. This is a follow-up to r281008 (an attempt to unbreak the
native_separators.c test on Windows).
Patch by Maggie Yi!
llvm-svn: 281062
It would be nice to prepare file reports (using the CoverageReport API)
without actually rendering them to the console. I plan on using this to
flesh out the 'index' files in the coverage views.
llvm-svn: 281009
Use the same color for counts and percentages. There doesn't seem to be
a reason for them to be different, and the summary looks more consistent
this way.
llvm-svn: 280765
The llvm-cov ‘report' command displays a summary of the coverage of a binary file.
The summary report currently only includes covered regions and covered functions.
This patch adds the coverage of lines in the summary report.
Differential Revision: https://reviews.llvm.org/D22569
llvm-svn: 276409
Previously, we only expanded function and filename column widths when
rendering file reports. This commit makes the change for function
reports as well.
llvm-svn: 250900
Change the output of llvm-cov s.t it does not truncate function names
and file paths when printing coverage reports.
Differential Revision: http://reviews.llvm.org/D12647
rdar://22531141
llvm-svn: 247635
This code didn't really make sense as is. If a filename is passed in,
the user obviously wants the coverage *for that file*, not *for
everything*.
llvm-svn: 229217
PR22575 occurred because we were unsafely storing references into a
std::vector. If the vector moved because it grew, we'd be left
iterating through garbage memory. This avoids the issue by simplifying
the logic to gather coverage information as we go, rather than storing
it and iterating over it.
I'm relying on the existing tests showing that this is semantically
NFC, since it's difficult to hit the issue this fixes without
relatively large covered programs.
llvm-svn: 229215
utils/sort_includes.py.
I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.
llvm-svn: 225974
This commit fixes llvm-cov's function coverage metric by using the number of executed functions instead of the number of fully covered functions.
Differential Revision: http://reviews.llvm.org/D5196
llvm-svn: 218672
This commit expands llvm-cov's functionality by adding support for a new code coverage
tool that uses LLVM's coverage mapping format and clang's instrumentation based profiling.
The gcov compatible tool can be invoked by supplying the 'gcov' command as the first argument,
or by modifying the tool's name to end with 'gcov'.
Differential Revision: http://reviews.llvm.org/D4445
llvm-svn: 216300
Zachary Turner