llvm-cov writes out an index file in '-output-dir' mode, albeit not a
very informative one. Try to fix that by using the CoverageReport API to
include some basic summary information in the index file.
llvm-svn: 281011
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
The text and html coverage views take different approaches to emitting
highlighted regions. That's because this problem is easier in the text
view: there's no need to worry about escaping text or adding tooltip
content to a highlighted snippet.
Unfortunately, the html view didn't get region highlighting quite right.
This patch fixes the situation, bringing parity between the two views.
llvm-svn: 280981
In r279628, we made SourceCoverageView list the binary associated with a
view and started adding labels (e.g "Source: foo" or "Function: bar") to
everything. Condense this information a bit to unclutter reports.
llvm-svn: 280896
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
This patch provides easy navigation to find the zero count lines, especially useful when the source file is very large.
Differential Revision: https://reviews.llvm.org/D23277
llvm-svn: 280739
The coverage reports contain the source or binary file paths. On Windows,
the file path might contain the seperators of both '/' and '\'. This patch
uses the native path in the coverage reports. For example, on Windows,
all '/' are converted to '\'.
Differential Revision: https://reviews.llvm.org/D23922
llvm-svn: 280061
This patch includes the following changes:
- Included header "Code coverage report" and include the date that the report was created.
- Included title (as specified in a command line option, (i.e llvm-cov -project-title="Simple Test")
- In the summary, list the elf files that the source code file has contributed to.
- Used column heading for "Line No.", "Count No.", Source".
Differential Revision: https://reviews.llvm.org/D23345
llvm-svn: 279628
In the coverage report, the line and count columns have been swapped to make it more readable.
A follow-up commit in compiler-rt is needed
Differential Revision: https://reviews.llvm.org/D23281
llvm-svn: 278152
When using orbis-llvm-cov.exe to generate the HTML report, the HTML report
can look quite different to the source file if it includes tabs.The default
tab size is 2 spaces instead of 8 spaces. A command line switch is
be added to set the tab size.
Differential Revision: https://reviews.llvm.org/D23087
llvm-svn: 277715
This fixes the highlighting for lines without any coverage segments. I
don't have a neat way of testing this yet, but am working on it.
llvm-svn: 276906
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
llvm-svn: 276818
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
llvm-svn: 276813
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
This makes it easy to swap out the default stylesheet for a custom one.
It also shaves ~6.62 MB out of the report directory for a full coverage
build of llvm+clang.
While we're at it, prune the CSS and add tests for it.
llvm-svn: 276359
Add an option to specify a symbol demangler (as well as options to the
demangler). This can be used to make reports more human-readable.
This option is especially useful in -output-dir mode, since it isn't as
easy to manually pipe reports into a demangler in this mode.
llvm-svn: 275640
Taking a lock before appending to a vector does no good unless threads
reading from the vector also take the lock, because the vector could be
re-sized.
I don't have a good isolated test for this. I found the issue with ASan
while testing a large project. I'm working on a bot that does this.
llvm-svn: 275516
Writing `for (StringRef &SourceFile : ...)` is strange to begin with.
Subsequently capturing "SourceFile" by reference is even stranger. Just
copy the StringRef, since that's cheap to do.
llvm-svn: 275515
It's safe to print out source coverage views using multiple threads when
using the -output-dir mode of the `llvm-cov show` sub-command.
While testing this on my development machine, I observed that the speed
up is roughly linear with the number of available cores. Avg. time for
`llvm-cov show ./llvm-as -show-line-counts-or-regions`:
1 thread: 7.79s user 0.33s system 98% cpu 8.228 total
4 threads: 7.82s user 0.34s system 283% cpu 2.880 total
llvm-svn: 275321
In -output-dir mode, file reports are placed into a "coverage"
directory. If filenames in the coverage mapping contain "..", they might
escape out of this directory.
Fix the problem by removing ".." from source filenames (expand the path
component).
llvm-svn: 274135
- Add renderView{Header,Footer}, renderLineSuffix, and hasSubViews to
support creating tables with nested views.
- Move the 'Format' cl::opt to make it easier to extend.
- Just create one function view file, instead of overwriting the same
file for every new function. Add a regression test for this.
llvm-svn: 274086
This index lists the reports available in the 'coverage' sub-directory.
This will help navigate coverage output from large projects.
This commit factors the file creation code out of SourceCoverageView and
into CoveragePrinter.
llvm-svn: 274029
Passing -output-dir path/to/dir to llvm-cov show creates path/to/dir if
it doesn't already exist, and prints reports into that directory.
In function view mode, all views are written into
path/to/dir/functions.$EXTENSION. In file view mode, all views are
written into path/to/dir/coverage/$PATH.$EXTENSION.
Changes since the initial commit:
- Avoid accidentally closing stdout twice.
llvm-svn: 273985
This reverts commit r273971. test/profile/instrprof-visibility.cpp is
failing because of an uncaught error in SafelyCloseFileDescriptor.
llvm-svn: 273978
Passing -output-dir path/to/dir to llvm-cov show creates path/to/dir if
it doesn't already exist, and prints reports into that directory.
In function view mode, all views are written into
path/to/dir/functions.$EXTENSION. In file view mode, all views are
written into path/to/dir/coverage/$PATH.$EXTENSION.
llvm-svn: 273971
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
looking for it along $PATH. This allows installs of LLVM tools outside of
$PATH to find the symbolizer and produce pretty backtraces if they crash.
llvm-svn: 272232
Transition InstrProf and Coverage over to the stricter Error/Expected
interface.
Changes since the initial commit:
- Fix error message printing in llvm-profdata.
- Check errors in loadTestingFormat() + annotateAllFunctions().
- Defer error handling in InstrProfIterator to InstrProfReader.
- Remove the base ProfError class to work around an MSVC ICE.
Differential Revision: http://reviews.llvm.org/D19901
llvm-svn: 270020
Coverage mapping data is organized in a sequence of blocks, each of which is expected
to be aligned by 8 bytes. This feature is used when reading those blocks, see
VersionedCovMapFuncRecordReader::readFunctionRecords(). If a misaligned covearge
mapping data has more than one block, it causes llvm-cov to fail.
Differential Revision: http://reviews.llvm.org/D20285
llvm-svn: 269887
Transition InstrProf and Coverage over to the stricter Error/Expected
interface.
Changes since the initial commit:
- Address undefined-var-template warning.
- Fix error message printing in llvm-profdata.
- Check errors in loadTestingFormat() + annotateAllFunctions().
- Defer error handling in InstrProfIterator to InstrProfReader.
Differential Revision: http://reviews.llvm.org/D19901
llvm-svn: 269694
Transition InstrProf and Coverage over to the stricter Error/Expected
interface.
Changes since the initial commit:
- Fix error message printing in llvm-profdata.
- Check errors in loadTestingFormat() + annotateAllFunctions().
- Defer error handling in InstrProfIterator to InstrProfReader.
Differential Revision: http://reviews.llvm.org/D19901
llvm-svn: 269491
Transition InstrProf and Coverage over to the stricter Error/Expected
interface.
Differential Revision: http://reviews.llvm.org/D19901
llvm-svn: 269462
Produce the first specific error message for a malformed Mach-O file describing
the problem instead of the generic message for object_error::parse_failed of
"Invalid data was encountered while parsing the file”. Many more good error
messages will follow after this first one.
This is built on Lang Hames’ great work of adding the ’Error' class for
structured error handling and threading Error through MachOObjectFile
construction. And making createMachOObjectFile return Expected<...> .
So to to get the error to the llvm-obdump tool, I changed the stack of
these methods to also return Expected<...> :
object::ObjectFile::createObjectFile()
object::SymbolicFile::createSymbolicFile()
object::createBinary()
Then finally in ParseInputMachO() in MachODump.cpp the error can
be reported and the specific error message can be printed in llvm-objdump
and can be seen in the existing test case for the existing malformed binary
but with the updated error message.
Converting these interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. To contain the changes for now use of
errorToErrorCode() and errorOrToExpected() are used where the callers
are yet to be converted.
Also there some were bugs in the existing code that did not deal with the
old ErrorOr<> return values. So now with Expected<> since they must be
checked and the error handled, I added a TODO and a comment:
“// TODO: Actually report errors helpfully” and a call something like
consumeError(ObjOrErr.takeError()) so the buggy code will not crash
since needed to deal with the Error.
Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along
with this that I will commit right after this. So expect lld not to built
after this commit and before the next one.
llvm-svn: 265606
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
llvm-svn: 258861
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
The reason we need to search by name rather than by Triple::ArchType
is to handle subarchitecture correclty. There is no different ArchType
for the x86_64h architecture (it identifies itself as x86_64), or for
the various ARM subarches. The only way to get to the subarch slice
in an universal binary is to search by name.
This issue led to hard to debug and transient symbolication failures
in Asan tests (it mostly works, because the files are very similar).
This also affects the Profiling infrastucture as it is the other user
of that API.
Reviewers: samsonov, bogner
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10604
llvm-svn: 240339
In r233132 we started requiring a subcommand in llvm-cov, but this
made `llvm-cov --version` invalid, which is kind of silly. Print
version information in this case, as most people would expect.
llvm-svn: 238897
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.
Call sites were found with the ASTMatcher + some semi-automated cleanup.
memberCallExpr(
argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
hasArgument(0, bindTemporaryExpr(
hasType(recordDecl(hasNonTrivialDestructor())),
has(constructExpr()))),
unless(isInTemplateInstantiation()))
No functional change intended.
llvm-svn: 238602
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
A while ago llvm-cov gained support for clang's instrumentation based
profiling in addition to its gcov support, and subcommands were added
to choose which behaviour to use. When no subcommand was specified, we
fell back to gcov compatibility with a warning that a subcommand would
be required in the future. Now, we require the subcommand.
Note that if the basename of llvm-cov is gcov (via symlink or
hardlink, for example), we still use the gcov compatible behaviour
with no subcommand required.
llvm-svn: 233132
This is an ugly hack to fix the configure --enable-shared build. It
turns out that *every cl::opt in LLVM* shows up in *every tool* in
that configuration, which is hopelessly broken. This skirts around the
issue by not colliding with another option's name, for now.
I've also simplified the option implementation - the other "color"
option used cl::boolOrDefault and was much nicer than what I'd written
before.
llvm-svn: 232704
The clang-hexagon elf bot was complaining that "Option 'color'
registered more than once!":
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/24425
I don't understand why this error is happening, and I don't see it on
any other bots or on my own machine, so I'm kind of grasping at
straws. Try using an unscoped enum and specifying a cl::init to see if
they help.
llvm-svn: 232698
When multiple regions start on the same line, llvm-cov was just
showing the count of the last one as the line count. This can be
confusing and misleading for things like one-liner loops, where the
count at the end isn't very interesting, or even "if" statements with
an opening brace at the end of the line.
Instead, use the maximum of all of the region start counts.
llvm-svn: 230263
Vedant Kumar