Lines Matching refs:coverage

11 This document explains how to use clang's source-based code coverage feature.
13 information directly. This allows it to generate very precise coverage data.
15 Clang ships two other code coverage implementations:
18   various sanitizers. It can provide up to edge-level coverage.
20 * gcov - A GCC-compatible coverage implementation which operates on DebugInfo.
21   This is enabled by ``-ftest-coverage`` or ``--coverage``.
23 From this point onwards "code coverage" will refer to the source-based kind.
25 The code coverage workflow
28 The code coverage workflow consists of three main steps:
30 * Compiling with coverage enabled.
34 * Creating coverage reports.
53 Compiling with coverage enabled
56 To compile code with coverage enabled, pass ``-fprofile-instr-generate
61     # Step 1: Compile with coverage enabled.
64 Note that linking together code with and without coverage instrumentation is
95   instrumented program crashes, or is killed by a signal, perfect coverage
134 Creating coverage reports
138 coverage reports. This is done using the "merge" tool in ``llvm-profdata``
146 There are multiple different ways to render coverage reports. The simplest
151     # Step 3(b): Create a line-oriented coverage report.
183 sub-views will show detailed branch coverage information in addition to the
207 To generate a file-level summary of coverage statistics instead of a
212     # Step 3(c): Create a coverage summary.
244 Exporting coverage data
254 There are five statistics tracked in a coverage summary:
256 * Function coverage is the percentage of functions which have been executed at
260 * Instantiation coverage is the percentage of function instantiations which
266 * Line coverage is the percentage of code lines which have been executed at
270 * Region coverage is the percentage of code regions which have been executed at
275 * Branch coverage is the percentage of "true" and "false" branches that have
283 Of these five statistics, function coverage is usually the least granular while
284 branch coverage is the most granular. 100% branch coverage for a function
285 implies 100% region coverage for a function. The project-wide totals for each
301   coverage mappings emitted into instrumented binaries. These formats are not
304 * The JSON coverage export format has a (major, minor, patch) version triple.
309 Impact of llvm optimizations on coverage reports
313 impact on coverage report quality. This is due to the fact that the mapping
319 Note that this coverage feature does not rely on information that can degrade
377 Collecting coverage reports for the llvm project
380 To prepare a coverage report for llvm (and any of its sub-projects), add
383 report, run ``llvm/utils/prepare-code-coverage-artifact.py``.
397 * Code coverage does not handle unpredictable changes in control flow or stack
409   coverage tool may mark the ``return`` statement as executed even though it is
416 the clang code coverage implementation.
425 Gap regions are used to eliminate unnatural artifacts in coverage reports, such
432 When viewing branch coverage details in source-based file-level sub-views using
435 conditions.  The coverage summary report will always include these macro-based
436 boolean expressions in the overall branch coverage count for a function or
439 Branch coverage is not tracked for constant folded branch conditions since
444 Branch coverage is tied directly to branch-generating conditions in the source