The current llvm-cov error message for kind `coveragemap_error::malforme`, just gives the issue kind without any reason for what caused the issue. This patch is aimed at improving the llvm-cov error message to help identify what caused the issue.
Reviewed By: MaskRay
Close: https://github.com/llvm/llvm-project/pull/65264
This is a GSoC 2023 project ([discourse link](https://discourse.llvm.org/t/coverage-support-a-hierarchical-directory-structure-in-generated-coverage-html-reports/68239)).
llvm-cov currently generates a single top-level index HTML file, which causes rendering scalability issues in large projects. This patch adds support for hierarchical directory structure into the HTML reports to solve scalability issues by introducing the following changes:
- Added a new command line option `--show-directory-coverage` for `llvm-cov show`. It works both for `--format=html` and `--format=text`.
- Two new classes: `CoveragePrinterHTMLDirectory` and `CoveragePrinterTextDirectory` was added to support the new option.
- A tool class `DirectoryCoverageReport` was added to support the two classes above.
- Updated the document.
- Added a new regression test for `--show-directory-coverage`.
Reviewed By: phosek, gulfem
Differential Revision: https://reviews.llvm.org/D151283
Previously the --path-equivalence parameter would allow to specify a single remap pair (coverage data path - local source file path). This patch changes this allowing to pass as many remaps as needed.
Reviewed By: keith
Differential Revision: https://reviews.llvm.org/D154223
clang<11 intended to use a GCC 4.2 compatible format but that turned out
to make some mistakes. After instrumentation side format changes,
c8b082a3abe44138fff4ef824300270dd6e8bc77 kept supporting the legacy
format, originally intended for 1 or 2 major releases.
Remove an obsoleted comment as GCC 12 uses length==12 for
GCOV_TAG_FUNCTION in .gcda files.
`llvm-cov convert-for-testing` is used to build the .covmapping files used in its regression tests. However the current implementation only works when there's only one source file in the mapping information data. If there are more than 1 source files, `llvm-cov convert-for-testing` can still produce a .covmapping file, but when read it back, `llvm-cov` will report:
```
error: Failed to load coverage: 'main.covmapping': Malformed coverage data
```
This is because the output .covmapping file doesn't have any mark to indicate the boundary between file records and function records, and current implementation jsut assume there's only one file record in the .covmapping file.
Changes to the code:
- Make `llvm-cov convert-for-testing` output a LEB128 number before file records to indicate its size.
- Change the testing format parsing code correspondingly.
- Update existing .covmapping files.
Reviewed By: gulfem
Differential Revision: https://reviews.llvm.org/D156611
We were producing inconsistent results when a file appeared multiple
times in gcno/gcda files if the instances had differing relative paths.
This patch unifies filenames, so coverage results are merged.
Patch by Oleksii Odynochenko. Thanks!
Differential Revision: https://reviews.llvm.org/D152453
This is a follow-up to b71edfaa4ec3c998aadb35255ce2f60bba2940b0
since I forgot the lit.local.cfg files in that one.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: barannikov88, kwk
Differential Revision: https://reviews.llvm.org/D150762
This small patch adds a '--skip-branches' option to the llvm-cov export
options. This option allows branch coverage information to be skipped from the
exported LCOV directives if it's not needed. For now, this only works when
exporting LCOV (which is noted in the option description), but it can be
extended for JSON later if it makes sense.
Differential Revision: https://reviews.llvm.org/D135986
If error occurs on constructing coverage info for one of the object files, it prints the name of the object file, so that users know which one is the cause of error.
Differential Revision: https://reviews.llvm.org/D130196
When profdata is missing on report and export commands, the error message is
indistinguishable from missing instrumented binary file. This adds the error
message for report and export commands.
Differential Revision: https://reviews.llvm.org/D129791
We already remove dots from collected paths and path mappings. This
makes it difficult to match paths inside the profile which contain
dots. For example, we would never match /path/to/../file.c because
the collected path is always be normalized to /path/file.c. This
change enables dot removal for paths inside the profile to address
the issue.
Differential Revision: https://reviews.llvm.org/D123164
We already remove dots from collected paths and path mappings. This
makes it difficult to match paths inside the profile which contain
dots. For example, we would never match /path/to/../file.c because
the collected path is always be normalized to /path/file.c. This
change enables dot removal for paths inside the profile to address
the issue.
Differential Revision: https://reviews.llvm.org/D122750
In the case you pass multiple universal binaries to llvm-cov, assume
that if only 1 architecture is passed, it should be used for all the
passed binaries.
This makes it easier to use multiple multi-arch binaries, since it's
likely very rare that your architectures mismatch significantly if you
also have multiple binaries in a single llvm-cov invocation. If the
architecture is invalid for any of the passed binaries, it will still
fail later.
Differential Revision: https://reviews.llvm.org/D121667
Template functions share the same lines in source files, so the common
container of lines' properties cannot be used to calculate the coverage
statistics of individual functions.
> cat tmpl.cpp
template <int N> int test() { return N; }
int main() { return test<1>() + test<2>(); }
> clang++ --coverage tmpl.cpp -o tmpl
> ./tmpl
> llvm-cov gcov tmpl.cpp -f
...
Function '_Z4testILi1EEiv'
Lines executed:100.00% of 1
Function '_Z4testILi2EEiv'
Lines executed:-nan% of 0
...
> llvm-cov-patched gcov tmpl.cpp -f
...
Function '_Z4testILi1EEiv'
Lines executed:100.00% of 1
Function '_Z4testILi2EEiv'
Lines executed:100.00% of 1
...
Differential Revision: https://reviews.llvm.org/D121390
Renamed the option for llvm-cov and changed variable names to use more
inclusive terms. Also changed the binary for the test.
Reviewed By: alanphipps
Differential Revision: https://reviews.llvm.org/D112816
This test covers acts as a regression test for these fixes:
c75a0a1e9dc29be4e00d37d0d00288afc1a6153f
dd388ba3e0b0a5f06565d0bcb6e1aebb5daac065
Differential Revision: https://reviews.llvm.org/D108805
Commit 9f2967bcfe2f7d1fc02281f0098306c90c2c10a5 introduced support for
branch coverage including export to the LCOV format.
This commit corrects the LCOV field name for branches from BFH to BRH.
The mistake seems to have slipped in as typo because the correct field
name BRH is used in the comment section at the beginning of the file.
Differential Revision: https://reviews.llvm.org/D108358
Much like other LLVM binary utilities, `llvm-cov` has a symlink compatibility feature where it runs in `gcov` compatibility mode if the binary name ends in `gcov`. This is identical to invoking `llvm-cov gcov ...`.
Differential Revision: https://reviews.llvm.org/D102299
When making compilation relocatable, for example in distributed
compilation scenarios, we want to set compilation dir to a relative
value like `.` but this presents a problem when generating reports
because if the file path is relative as well, for example `..`, you
may end up writing files outside of the output directory.
This change introduces a flag that allows overriding the compilation
directory that's stored inside the profile with a different value that
is absolute.
Differential Revision: https://reviews.llvm.org/D100232
Originally landed in: 6400905a615282c83a2fc6e49e57ff716aa8b4de
Reverted in: 668dccc396da4f593ac87c92dc0eb7bc983b5762
Fix branch coverage merging in FunctionCoverageSummary::get() for instantiation
groups.
This change corrects the implementation for the branch coverage summary to do
the same thing for branches that is done for lines and regions. That is,
across function instantiations in an instantiation group, the maximum branch
coverage found in any of those instantiations is returned, with the total
number of branches being the same across instantiations.
Differential Revision: https://reviews.llvm.org/D102193
groups.
This change corrects the implementation for the branch coverage
summary to do the same thing for branches that is done for lines and regions.
That is, across function instantiations in an instantiation group, the maximum
branch coverage found in any of those instantiations is returned, with the
total number of branches being the same across instantiations.
Differential Revision: https://reviews.llvm.org/D102193
We currently always store absolute filenames in coverage mapping. This
is problematic for several reasons. It poses a problem for distributed
compilation as source location might vary across machines. We are also
duplicating the path prefix potentially wasting space.
This change modifies how we store filenames in coverage mapping. Rather
than absolute paths, it stores the compilation directory and file paths
as given to the compiler, either relative or absolute. Later when
reading the coverage mapping information, we recombine relative paths
with the working directory. This approach is similar to handling
ofDW_AT_comp_dir in DWARF.
Finally, we also provide a new option, -fprofile-compilation-dir akin
to -fdebug-compilation-dir which can be used to manually override the
compilation directory which is useful in distributed compilation cases.
Differential Revision: https://reviews.llvm.org/D95753
We currently always store absolute filenames in coverage mapping. This
is problematic for several reasons. It poses a problem for distributed
compilation as source location might vary across machines. We are also
duplicating the path prefix potentially wasting space.
This change modifies how we store filenames in coverage mapping. Rather
than absolute paths, it stores the compilation directory and file paths
as given to the compiler, either relative or absolute. Later when
reading the coverage mapping information, we recombine relative paths
with the working directory. This approach is similar to handling
ofDW_AT_comp_dir in DWARF.
Finally, we also provide a new option, -fprofile-compilation-dir akin
to -fdebug-compilation-dir which can be used to manually override the
compilation directory which is useful in distributed compilation cases.
Differential Revision: https://reviews.llvm.org/D95753
This is an enhancement to LLVM Source-Based Code Coverage in clang to track how
many times individual branch-generating conditions are taken (evaluate to TRUE)
and not taken (evaluate to FALSE). Individual conditions may comprise larger
boolean expressions using boolean logical operators. This functionality is
very similar to what is supported by GCOV except that it is very closely
anchored to the ASTs.
Differential Revision: https://reviews.llvm.org/D84467
The static_assert in "libcxx/include/memory" was the main offender here,
but then I figured I might as well `git grep -i instantat` and fix all
the instances I found. One was in user-facing HTML documentation;
the rest were in comments or tests.
This is to enable `--allow-unused-duplicates=false`. These prefixes
appear to be outdated and intentionally unused.
Reviewed By: vsk
Differential Revision: https://reviews.llvm.org/D90423
When all provided source files are filtered out either due to `--ignore-filename-regex` or not part of binary, don't generate coverage reults for all source files. Because if users want to generate coverage results for all source files, they don't even need to provid selected source files or `--ignore-filename-regex`.
Differential Revision: https://reviews.llvm.org/D89359
This reverts commit c2bd20ef652 and the follow up fix 16605bba6fb.
The tools/llvm-cov/warnings.h continues to fail on Windows platforms even
after the follow up, for example on the llvm-clang-win-x-armv7l builder:
http://lab.llvm.org:8011/#/builders/60/builds/94
`/dev/null` is treated as regualar file on Windows.
native_separators.c line 11 used relative path which was not correct but worked before because when `SourceFiles` is empty, it add all source files into `SourceFiles`.
When all provided source files are filtered out either due to `--ignore-filename-regex` or not part of binary, don't generate coverage reults for all source files. Because if users want to generate coverage results for all source files, they don't even need to provid selected source files or `--ignore-filename-regex`.
Differential Revision: https://reviews.llvm.org/D89359
llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make the error
message more specific.
(This version of the patch avoids using llvm::none_of -- the way I used
the utility caused compile errors on many bots, possibly because the
wrong overload of `none_of` was selected.)
rdar://40312677
This reverts commit b81d4bfb44c14575130bb06c047728b69c3213aa.
It's causing some bots to fail to build due to: "error: no matching
function for call to ‘__iterator_category".
llvm-cov reports a poor error message when the -arch specifier is
missing or invalid, and a binary has multiple slices. Make the error
message more specific.
rdar://40312677
Currently, -object takes a comma separated list of objects as an
argument, which prevents it working with path names that contain a
comma. Drop comma-separated support, which requires to set pass the
-object flag multiple times to set multiple objects.
Patch by Andrew Gallagher!
Differential Revision: https://reviews.llvm.org/D87003
