llvm-cov tends to highlight too many regions because its policy is to
highlight all region entry segments. This can look confusing to users:
not all region entry segments are interesting and deserve highlighting.
Emitting these highlights only when the region count differs from the
line count is a more user-friendly policy.
llvm-svn: 316109
llvm-cov typically doesn't highlight gap segments, but it should if the
gap occurs after an uncovered region in order to preserve continuity.
llvm-svn: 316107
In r315960, I accidentally assumed that the first line segment is
guaranteed to be the non-gap region entry segment (given that one is
present). It can actually be any segment on the line, and the test I
checked in demonstrates that.
llvm-svn: 315963
Gap areas make it possible to correctly determine when to use counts
from deferred regions. Before gap areas were introduced, llvm-cov needed
to use a heuristic to do this: it ignored counts from segments that
start, but do not end, on a line. This heuristic breaks down on a simple
example (see PR34962).
This patch removes the heuristic and picks counts from any region entry
segment which isn't a gap area.
llvm-svn: 315960
Summary: This version of tests should be working properly.
Reviewers: vsk
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D38889
llvm-svn: 315714
Summary:
Documentation says that user can specify sources for both "show" and
"report" commands. "Show" command respects specified sources, but "report" does
not. It is useful to have both "show" and "report" generated for specified
sources. Also added tests to for both commands with sources specified.
Reviewers: vsk, kcc
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D38860
llvm-svn: 315685
Before this change using any of the -name*= command line options with an output
directory would result in a single file (functions.txt/functions.html)
containing the coverage for those specific functions. Now you get the same
directory structure as when not using any -name*= options.
Differential Revision: https://reviews.llvm.org/D38280
llvm-svn: 314396
Before this change using any of the -name*= command line options with an output
directory would result in a single file (functions.txt/functions.html)
containing the coverage for those specific functions. Now you get the same
directory structure as when not using any -name*= options.
Differential Revision: https://reviews.llvm.org/D38280
llvm-svn: 314310
llvm-cov's report mode does not print any output when -show-functions is
specified and no source files are specified. This can be surprising, so
the tool should at least print out an error message when this happens.
rdar://problem/34636859
llvm-svn: 314175
Passing "-dump" to llvm-cov will now print more detailed information
about function hash and counter mismatches. This should make it easier
to debug *.profdata files which contain incorrect records, and to debug
other scenarios where coverage goes missing due to mismatch issues.
llvm-svn: 313853
After clang started emitting deferred regions (r312818), llvm-cov has
had a hard time picking reasonable line execuction counts. There have
been one or two generic improvements in this area (e.g r310012), but
line counts can still report coverage for whitespace instead of code
(llvm.org/PR34612).
To fix the problem:
* Introduce a new region kind so that frontends can explicitly label
gap areas.
This is done by changing the encoding of the columnEnd field of
MappingRegion. This doesn't substantially increase binary size, and
makes it easy to maintain backwards-compatibility.
* Don't set the line count to a count from a gap area, unless the count
comes from a wrapped segment.
* Don't highlight gap areas as uncovered.
Fixes llvm.org/PR34612.
llvm-svn: 313597
* Fix an unsigned integer overflow in the logic that computes the
number of uncovered lines in a function.
* When aggregating region and line coverage summaries, take into account
that different instantiations may have a different number of regions.
The new test case provides test coverage for both bugs. I also verified
this change by preparing a coverage report for a stage2 build of llc --
the new assertions should detect any outstanding over-counting bugs.
Fixes PR34613.
llvm-svn: 313417
Region coverage is difficult to explain without going deep into how
coverage is implemented. Instantiation coverage is easier to explain,
but probably not useful in most cases (templates don't exist in C, and
most C++ code contains relatively few templates).
This patch adds the options "-show-region-summary" and
"-show-instantiation-summary" to allow hiding those columns.
"-show-instantiation-summary" is turned off by default.
llvm-svn: 312969
On a Windows bot, I see a FileCheck error where the source being matched
over no longer exists, i.e it seems like it's FileCheck'ing some stale
output:
http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/4747
You can see "// CHECK: [[@LINE]]|{{ +}Marker at 19:3 = 1" in the
FileCheck stderr, but that CHECK line doesn't exist.
Remove the input file to FileCheck before running the test, to try and
appease the bot.
llvm-svn: 312825
A coverage segment contains a starting line and column, an execution
count, and some other metadata. Clients of the coverage library use
segments to prepare line-oriented reports.
Users of the coverage library depend on segments being unique and sorted
in source order. Currently this is not guaranteed (this is why the clang
change which introduced deferred regions was reverted).
This commit documents the "unique and sorted" condition and asserts that
it holds. It also fixes the SegmentBuilder so that it produces correct
output in some edge cases.
Testing: I've added unit tests for some edge cases. I've also checked
that the new SegmentBuilder implementation is fully covered. Apart from
running check-profile and the llvm-cov tests, I've successfully used a
stage1 llvm-cov to prepare a coverage report for an instrumented clang
binary.
Differential Revision: https://reviews.llvm.org/D36813
llvm-svn: 312817
Each source region has a start and end location. Report an error when
the end location does not precede the begin location.
The old lineExecutionCounts.covmapping test actually had a buggy source
region in it. This commit introduces a regenerated copy of the coverage
and moves the old copy to malformedRegions.covmapping, for a test.
Differential Revision: https://reviews.llvm.org/D37387
llvm-svn: 312814
Make sure that the text and html emitters always emit the same set of
region markers, and avoid emitting redundant markers for line segments
which don't end on the line they start on.
This is related to D35925, and depends on D36014
Differential Revision: https://reviews.llvm.org/D36020
llvm-svn: 312813
Summary: Add a -name-whitelist option, which behaves in the same way as -name, but it reads in multiple function names from the given input file(s).
Reviewers: vsk
Reviewed By: vsk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37111
llvm-svn: 312227
Summary:
This patch adds the -path-equivalence option (example: llvm-cov show -path-equivalence=/origin/path,/local/path) which maps the source code path from one machine to another when using `llvm-cov show`. This is similar to the -filename-equivalence option, but doesn't require you to specify all the source files on the command line.
This allows you to generate the coverage data on one machine (e.g. in a CI system), and then use llvm-cov on another machine where you have the same code base on a different path.
Reviewers: vsk
Reviewed By: vsk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36391
llvm-svn: 310827
Files which don't contain any functions are likely useless; don't
include them in the main table. Put the links at the bottom of the
page, in case someone wants to figure out coverage for code inside
a macro.
Not sure if this is the best solution, but it seems like an
improvement.
Differential Revision: https://reviews.llvm.org/D36298
llvm-svn: 310518
This patch makes a slight change to the way llvm-cov determines line
execution counts. If there are multiple line segments on a line, the
line count is the max count among the regions which start *and* end on
the line. This avoids an issue posed by deferred regions which start on
the same line as a terminated region, e.g:
if (false)
return; //< The line count should be 0, even though a new region
//< starts at the semi-colon.
foo();
Another change is that counts from line segments which don't correspond
to region entries are considered. This enables the first change, and
corrects an outstanding issue (see the showLineExecutionCounts.cpp test
change).
This is related to D35925.
Testing: check-profile, llvm-cov lit tests
Differential Revision: https://reviews.llvm.org/D36014
llvm-svn: 310012
The coverage tool needs to know which slice to look at when it's handed
a universal binary. Some projects need to look at aggregate coverage
reports for a variety of slices in different binaries: this patch adds
support for these kinds of projects to llvm-cov.
rdar://problem/33579007
llvm-svn: 309747
PR30735 reports an issue where llvm-cov hangs with a worker thread
waiting on a condition, and the main thread waiting to join() the
workers. While this doesn't appear to be a bug in llvm-cov or the
ThreadPool implementation, it would be helpful to disable the use of
threading in the llvm-cov tests where no test coverage is added.
More context: https://bugs.llvm.org/show_bug.cgi?id=30735
llvm-svn: 307610
When an output directory is specified, llvm-cov spawns some threads to
speed up the process of writing out file reports. Add an option which
allows users to control how many threads llvm-cov uses.
A CommandGuide.rst update + test is included.
llvm-svn: 307609
The order in which GCOV file info is printed depends on the string hash
function. This makes some GCOV tests brittle, because the tests must be
updated whenever the hash function changes.
Sort the filenames before printing out the file info to solve the
problem. This should be relatively cheap.
Differential Revision: https://reviews.llvm.org/D32512
llvm-svn: 301371
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
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.
llvm-svn: 285043
... so that they don't show up in the index. This came up because polly
contains a .git directory and some other unmapped input in its source
dir.
llvm-svn: 282282
Vedant Kumar