If a sub-view has already been rendered, it's helpful to re-render the
expansion site before rendering the next expansion view. Make this fact
explicit in the rendering interface, instead of hiding it behind an
awkward Optional<LineRef> parameter.
llvm-svn: 273789
This makes it easier to add renderers for new kinds of output formats.
- Define and document a pure-virtual coverage rendering interface.
- Move the text-based rendering logic into its a new file.
- Re-work the API to better reflect the presentation/formatting split.
llvm-svn: 273767
A SourceName can be a file or a function. It makes sense to attach this
information to a SourceCoverageView, seeing as views (1) already point
to the text corresponding to the relevant source code and (2) are
already used to render that text along with the SourceNames.
This is a nice cleanup which is independent of the upcoming html patch.
While we're at it, document the fields in SourceCoverageView.
llvm-svn: 273634
Pull LineCoverageInfo out of SourceCoverageView and rename it so that it
doesn't conflict with another class of the same name in
CoverageSummaryInfo.h.
This cuts down on the amount of code we have to move into a `protected`
section of SourceCoverageView for the upcoming html patch. It also makes
the code a bit clearer: having two LineCoverageInfo's is strange.
llvm-svn: 273633
llvm-cov was truncating numbers that were larger than a particular
fixed width, which is as confusing as it is useless. Instead, we use
engineering notation with SI prefix for magnitude.
llvm-svn: 237307
This splits the logic for actually looking up coverage information
from the logic that displays it. These were tangled rather thoroughly
so this change is a bit large, but it mostly consists of moving things
around. The coverage lookup logic itself now lives in the library,
rather than being spread between the library and the tool.
llvm-svn: 218184
This encapsulates how we handle the coverage regions of a file or
function. In the old model, the user had to deal with nested regions,
so they needed to maintain their own auxiliary data structures to get
any useful information out of this. The new API provides a sequence of
non-overlapping coverage segments, which makes it possible to render
coverage information in a single pass and avoids a fair amount of
extra work.
llvm-svn: 217975
It isn't always useful to skip blank lines, as evidenced by the
somewhat awkward use of line_iterator in llvm-cov. This adds a knob to
control whether or not to skip blanks.
llvm-svn: 217960
SourceCoverageView currently has "Kind" and a list of child views, all
of which must have either an expansion or an instantiation Kind. In
addition to being an error-prone design, this makes it awkward to
differentiate between the two child types and adds a number of
optionally used members to the type.
Split the subview types into their own separate objects, and maintain
lists of each rather than one combined "Children" list.
llvm-svn: 217940
This changes the debug output of the llvm-cov tool to consistently
write to stderr, and moves the highlighting output closer to where
it's relevant.
llvm-svn: 217838
In r217746, though it was supposed to be NFC, I broke llvm-cov's
handling of showing regions without showing counts. This should've
shown up in the existing tests, except they were checking debug output
that was displayed regardless of what was actually output. I've moved
the relevant debug output to a more appropriate place so that the
tests catch this kind of thing.
llvm-svn: 217835
llvm-cov had a SourceRange type that was nearly identical to a
CountedRegion except that it shaved off a couple of fields. There
aren't likely to be enough of these for the minor memory savings to be
worth the extra complexity here.
llvm-svn: 217417
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
Vedant Kumar