The CoverageMapping::getInstantiations() API retrieved all function
records corresponding to functions with more than one instantiation (e.g
template functions with multiple specializations). However, there was no
simple way to determine *which* function a given record was an
instantiation of. This was an oversight, since it's useful to aggregate
coverage information over all instantiations of a function.
llvm-cov works around this by building a mapping of source locations to
instantiation sets, but this duplicates logic that libCoverage already
has (see FunctionInstantiationSetCollector).
This change adds a new API, CoverageMapping::getInstantiationGroups(),
which returns a list of InstantiationGroups. A group contains records
for each instantiation of some particular function, and also provides
utilities to get the total execution count within the group, the source
location of the common definition, etc.
This lets removes some hacky logic in llvm-cov by reusing
FunctionInstantiationSetCollector and makes the CoverageMapping API
friendlier for other clients.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@309904 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296029 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@287539 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282422 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
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281875 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281873 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281062 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281009 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the longest common prefix from filenames when printing coverage
summaries. This makes them easier to compare.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280895 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@280765 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276409 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we only expanded function and filename column widths when
rendering file reports. This commit makes the change for function
reports as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@250900 91177308-0d34-0410-b5e6-96231b3b80d8
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*.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229217 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229215 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225974 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216300 91177308-0d34-0410-b5e6-96231b3b80d8
