2023-07-22 08:23:39 +00:00
|
|
|
use crate::coverageinfo::ffi::{Counter, CounterExpression, ExprKind};
|
2020-07-29 06:09:16 +00:00
|
|
|
|
2023-04-19 10:57:17 +00:00
|
|
|
use rustc_index::{IndexSlice, IndexVec};
|
2023-07-05 08:04:58 +00:00
|
|
|
use rustc_middle::bug;
|
2020-08-15 11:42:13 +00:00
|
|
|
use rustc_middle::mir::coverage::{
|
2023-06-29 02:36:19 +00:00
|
|
|
CodeRegion, CounterId, ExpressionId, MappedExpressionIndex, Op, Operand,
|
2020-08-15 11:42:13 +00:00
|
|
|
};
|
2020-07-25 04:14:28 +00:00
|
|
|
use rustc_middle::ty::Instance;
|
|
|
|
use rustc_middle::ty::TyCtxt;
|
2020-07-02 18:27:15 +00:00
|
|
|
|
2021-03-13 00:00:00 +00:00
|
|
|
#[derive(Clone, Debug, PartialEq)]
|
2020-10-05 23:36:10 +00:00
|
|
|
pub struct Expression {
|
2023-06-26 12:28:48 +00:00
|
|
|
lhs: Operand,
|
2020-08-15 11:42:13 +00:00
|
|
|
op: Op,
|
2023-06-26 12:28:48 +00:00
|
|
|
rhs: Operand,
|
2020-10-05 23:36:10 +00:00
|
|
|
region: Option<CodeRegion>,
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Collects all of the coverage regions associated with (a) injected counters, (b) counter
|
|
|
|
/// expressions (additions or subtraction), and (c) unreachable regions (always counted as zero),
|
2023-06-29 02:14:04 +00:00
|
|
|
/// for a given Function. This struct also stores the `function_source_hash`,
|
2020-07-25 04:14:28 +00:00
|
|
|
/// computed during instrumentation, and forwarded with counters.
|
2020-06-22 06:29:08 +00:00
|
|
|
///
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Note, it may be important to understand LLVM's definitions of `unreachable` regions versus "gap
|
|
|
|
/// regions" (or "gap areas"). A gap region is a code region within a counted region (either counter
|
|
|
|
/// or expression), but the line or lines in the gap region are not executable (such as lines with
|
|
|
|
/// only whitespace or comments). According to LLVM Code Coverage Mapping documentation, "A count
|
|
|
|
/// for a gap area is only used as the line execution count if there are no other regions on a
|
|
|
|
/// line."
|
2021-05-01 21:56:48 +00:00
|
|
|
#[derive(Debug)]
|
2020-10-05 23:36:10 +00:00
|
|
|
pub struct FunctionCoverage<'tcx> {
|
|
|
|
instance: Instance<'tcx>,
|
2020-07-02 18:27:15 +00:00
|
|
|
source_hash: u64,
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
is_used: bool,
|
2023-06-29 02:36:19 +00:00
|
|
|
counters: IndexVec<CounterId, Option<CodeRegion>>,
|
2023-06-29 02:14:04 +00:00
|
|
|
expressions: IndexVec<ExpressionId, Option<Expression>>,
|
2020-08-15 11:42:13 +00:00
|
|
|
unreachable_regions: Vec<CodeRegion>,
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
2020-10-05 23:36:10 +00:00
|
|
|
impl<'tcx> FunctionCoverage<'tcx> {
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
/// Creates a new set of coverage data for a used (called) function.
|
2020-10-05 23:36:10 +00:00
|
|
|
pub fn new(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>) -> Self {
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
Self::create(tcx, instance, true)
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Creates a new set of coverage data for an unused (never called) function.
|
|
|
|
pub fn unused(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>) -> Self {
|
|
|
|
Self::create(tcx, instance, false)
|
|
|
|
}
|
|
|
|
|
|
|
|
fn create(tcx: TyCtxt<'tcx>, instance: Instance<'tcx>, is_used: bool) -> Self {
|
2021-05-12 03:56:23 +00:00
|
|
|
let coverageinfo = tcx.coverageinfo(instance.def);
|
2020-10-05 23:36:10 +00:00
|
|
|
debug!(
|
2021-05-12 03:56:23 +00:00
|
|
|
"FunctionCoverage::create(instance={:?}) has coverageinfo={:?}. is_used={}",
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
instance, coverageinfo, is_used
|
2020-10-05 23:36:10 +00:00
|
|
|
);
|
2020-07-02 18:27:15 +00:00
|
|
|
Self {
|
2020-10-05 23:36:10 +00:00
|
|
|
instance,
|
2020-07-02 18:27:15 +00:00
|
|
|
source_hash: 0, // will be set with the first `add_counter()`
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
is_used,
|
2020-07-29 00:45:58 +00:00
|
|
|
counters: IndexVec::from_elem_n(None, coverageinfo.num_counters as usize),
|
|
|
|
expressions: IndexVec::from_elem_n(None, coverageinfo.num_expressions as usize),
|
2020-07-25 04:14:28 +00:00
|
|
|
unreachable_regions: Vec::new(),
|
2020-07-02 18:27:15 +00:00
|
|
|
}
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
/// Returns true for a used (called) function, and false for an unused function.
|
|
|
|
pub fn is_used(&self) -> bool {
|
|
|
|
self.is_used
|
|
|
|
}
|
|
|
|
|
2020-10-25 18:13:16 +00:00
|
|
|
/// Sets the function source hash value. If called multiple times for the same function, all
|
|
|
|
/// calls should have the same hash value.
|
2020-10-05 23:36:10 +00:00
|
|
|
pub fn set_function_source_hash(&mut self, source_hash: u64) {
|
|
|
|
if self.source_hash == 0 {
|
|
|
|
self.source_hash = source_hash;
|
|
|
|
} else {
|
|
|
|
debug_assert_eq!(source_hash, self.source_hash);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Adds a code region to be counted by an injected counter intrinsic.
|
2023-06-29 02:36:19 +00:00
|
|
|
pub fn add_counter(&mut self, id: CounterId, region: CodeRegion) {
|
2021-03-13 00:00:00 +00:00
|
|
|
if let Some(previous_region) = self.counters[id].replace(region.clone()) {
|
|
|
|
assert_eq!(previous_region, region, "add_counter: code region for id changed");
|
|
|
|
}
|
2020-07-02 18:27:15 +00:00
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Both counters and "counter expressions" (or simply, "expressions") can be operands in other
|
2023-06-29 02:14:04 +00:00
|
|
|
/// expressions. These are tracked as separate variants of `Operand`, so there is no ambiguity
|
|
|
|
/// between operands that are counter IDs and operands that are expression IDs.
|
2020-07-02 18:27:15 +00:00
|
|
|
pub fn add_counter_expression(
|
|
|
|
&mut self,
|
2023-06-29 02:14:04 +00:00
|
|
|
expression_id: ExpressionId,
|
2023-06-26 12:28:48 +00:00
|
|
|
lhs: Operand,
|
2020-08-15 11:42:13 +00:00
|
|
|
op: Op,
|
2023-06-26 12:28:48 +00:00
|
|
|
rhs: Operand,
|
2020-10-05 23:36:10 +00:00
|
|
|
region: Option<CodeRegion>,
|
2020-06-22 06:29:08 +00:00
|
|
|
) {
|
2020-10-05 23:36:10 +00:00
|
|
|
debug!(
|
|
|
|
"add_counter_expression({:?}, lhs={:?}, op={:?}, rhs={:?} at {:?}",
|
|
|
|
expression_id, lhs, op, rhs, region
|
|
|
|
);
|
2021-05-01 21:56:48 +00:00
|
|
|
debug_assert!(
|
2023-06-29 02:14:04 +00:00
|
|
|
expression_id.as_usize() < self.expressions.len(),
|
|
|
|
"expression_id {} is out of range for expressions.len() = {}
|
2021-05-01 21:56:48 +00:00
|
|
|
for {:?}",
|
2023-06-29 02:14:04 +00:00
|
|
|
expression_id.as_usize(),
|
2021-05-01 21:56:48 +00:00
|
|
|
self.expressions.len(),
|
|
|
|
self,
|
|
|
|
);
|
2023-06-29 02:14:04 +00:00
|
|
|
if let Some(previous_expression) = self.expressions[expression_id].replace(Expression {
|
2021-03-13 00:00:00 +00:00
|
|
|
lhs,
|
|
|
|
op,
|
|
|
|
rhs,
|
|
|
|
region: region.clone(),
|
|
|
|
}) {
|
|
|
|
assert_eq!(
|
|
|
|
previous_expression,
|
|
|
|
Expression { lhs, op, rhs, region },
|
|
|
|
"add_counter_expression: expression for id changed"
|
|
|
|
);
|
|
|
|
}
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Add a region that will be marked as "unreachable", with a constant "zero counter".
|
2020-08-15 11:42:13 +00:00
|
|
|
pub fn add_unreachable_region(&mut self, region: CodeRegion) {
|
2020-08-02 03:03:59 +00:00
|
|
|
self.unreachable_regions.push(region)
|
2020-07-02 18:27:15 +00:00
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Return the source hash, generated from the HIR node structure, and used to indicate whether
|
|
|
|
/// or not the source code structure changed between different compilations.
|
2020-07-02 18:27:15 +00:00
|
|
|
pub fn source_hash(&self) -> u64 {
|
|
|
|
self.source_hash
|
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
/// Generate an array of CounterExpressions, and an iterator over all `Counter`s and their
|
|
|
|
/// associated `Regions` (from which the LLVM-specific `CoverageMapGenerator` will create
|
|
|
|
/// `CounterMappingRegion`s.
|
2021-12-14 02:52:35 +00:00
|
|
|
pub fn get_expressions_and_counter_regions(
|
|
|
|
&self,
|
|
|
|
) -> (Vec<CounterExpression>, impl Iterator<Item = (Counter, &CodeRegion)>) {
|
2020-10-05 23:36:10 +00:00
|
|
|
assert!(
|
coverage bug fixes and optimization support
Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to
address multiple, somewhat related issues.
Fixed a significant flaw in prior coverage solution: Every counter
generated a new counter variable, but there should have only been one
counter variable per function. This appears to have bloated .profraw
files significantly. (For a small program, it increased the size by
about 40%. I have not tested large programs, but there is anecdotal
evidence that profraw files were way too large. This is a good fix,
regardless, but hopefully it also addresses related issues.
Fixes: #82144
Invalid LLVM coverage data produced when compiled with -C opt-level=1
Existing tests now work up to at least `opt-level=3`. This required a
detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR
when compiled with coverage, and a lot of trial and error with codegen
adjustments.
The biggest hurdle was figuring out how to continue to support coverage
results for unused functions and generics. Rust's coverage results have
three advantages over Clang's coverage results:
1. Rust's coverage map does not include any overlapping code regions,
making coverage counting unambiguous.
2. Rust generates coverage results (showing zero counts) for all unused
functions, including generics. (Clang does not generate coverage for
uninstantiated template functions.)
3. Rust's unused functions produce minimal stubbed functions in LLVM IR,
sufficient for including in the coverage results; while Clang must
generate the complete LLVM IR for each unused function, even though
it will never be called.
This PR removes the previous hack of attempting to inject coverage into
some other existing function instance, and generates dedicated instances
for each unused function. This change, and a few other adjustments
(similar to what is required for `-C link-dead-code`, but with lower
impact), makes it possible to support LLVM optimizations.
Fixes: #79651
Coverage report: "Unexecuted instantiation:..." for a generic function
from multiple crates
Fixed by removing the aforementioned hack. Some "Unexecuted
instantiation" notices are unavoidable, as explained in the
`used_crate.rs` test, but `-Zinstrument-coverage` has new options to
back off support for either unused generics, or all unused functions,
which avoids the notice, at the cost of less coverage of unused
functions.
Fixes: #82875
Invalid LLVM coverage data produced with crate brotli_decompressor
Fixed by disabling the LLVM function attribute that forces inlining, if
`-Z instrument-coverage` is enabled. This attribute is applied to
Rust functions with `#[inline(always)], and in some cases, the forced
inlining breaks coverage instrumentation and reports.
2021-03-15 23:32:45 +00:00
|
|
|
self.source_hash != 0 || !self.is_used,
|
|
|
|
"No counters provided the source_hash for used function: {:?}",
|
2020-10-05 23:36:10 +00:00
|
|
|
self.instance
|
|
|
|
);
|
2020-07-25 04:14:28 +00:00
|
|
|
|
|
|
|
let counter_regions = self.counter_regions();
|
2020-07-29 00:45:58 +00:00
|
|
|
let (counter_expressions, expression_regions) = self.expressions_with_regions();
|
2020-07-25 04:14:28 +00:00
|
|
|
let unreachable_regions = self.unreachable_regions();
|
|
|
|
|
|
|
|
let counter_regions =
|
|
|
|
counter_regions.chain(expression_regions.into_iter().chain(unreachable_regions));
|
2020-07-29 00:45:58 +00:00
|
|
|
(counter_expressions, counter_regions)
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
2021-12-14 02:52:35 +00:00
|
|
|
fn counter_regions(&self) -> impl Iterator<Item = (Counter, &CodeRegion)> {
|
2020-07-29 00:45:58 +00:00
|
|
|
self.counters.iter_enumerated().filter_map(|(index, entry)| {
|
2020-07-25 04:14:28 +00:00
|
|
|
// Option::map() will return None to filter out missing counters. This may happen
|
|
|
|
// if, for example, a MIR-instrumented counter is removed during an optimization.
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
entry.as_ref().map(|region| (Counter::counter_value_reference(index), region))
|
2020-07-25 04:14:28 +00:00
|
|
|
})
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
fn expressions_with_regions(
|
2021-12-14 02:52:35 +00:00
|
|
|
&self,
|
|
|
|
) -> (Vec<CounterExpression>, impl Iterator<Item = (Counter, &CodeRegion)>) {
|
2020-07-25 04:14:28 +00:00
|
|
|
let mut counter_expressions = Vec::with_capacity(self.expressions.len());
|
|
|
|
let mut expression_regions = Vec::with_capacity(self.expressions.len());
|
2020-10-05 23:36:10 +00:00
|
|
|
let mut new_indexes = IndexVec::from_elem_n(None, self.expressions.len());
|
2020-10-25 08:53:44 +00:00
|
|
|
|
|
|
|
// This closure converts any `Expression` operand (`lhs` or `rhs` of the `Op::Add` or
|
|
|
|
// `Op::Subtract` operation) into its native `llvm::coverage::Counter::CounterKind` type
|
2023-06-26 12:28:48 +00:00
|
|
|
// and value.
|
2020-10-25 08:53:44 +00:00
|
|
|
//
|
|
|
|
// Expressions will be returned from this function in a sequential vector (array) of
|
|
|
|
// `CounterExpression`, so the expression IDs must be mapped from their original,
|
2023-06-29 02:14:04 +00:00
|
|
|
// potentially sparse set of indexes.
|
2020-10-25 08:53:44 +00:00
|
|
|
//
|
|
|
|
// An `Expression` as an operand will have already been encountered as an `Expression` with
|
|
|
|
// operands, so its new_index will already have been generated (as a 1-up index value).
|
|
|
|
// (If an `Expression` as an operand does not have a corresponding new_index, it was
|
|
|
|
// probably optimized out, after the expression was injected into the MIR, so it will
|
|
|
|
// get a `CounterKind::Zero` instead.)
|
|
|
|
//
|
|
|
|
// In other words, an `Expression`s at any given index can include other expressions as
|
2020-07-25 04:14:28 +00:00
|
|
|
// operands, but expression operands can only come from the subset of expressions having
|
2020-10-05 23:36:10 +00:00
|
|
|
// `expression_index`s lower than the referencing `Expression`. Therefore, it is
|
2020-07-25 04:14:28 +00:00
|
|
|
// reasonable to look up the new index of an expression operand while the `new_indexes`
|
|
|
|
// vector is only complete up to the current `ExpressionIndex`.
|
2023-06-29 02:14:04 +00:00
|
|
|
type NewIndexes = IndexSlice<ExpressionId, Option<MappedExpressionIndex>>;
|
2023-06-26 12:28:48 +00:00
|
|
|
let id_to_counter = |new_indexes: &NewIndexes, operand: Operand| match operand {
|
|
|
|
Operand::Zero => Some(Counter::zero()),
|
2023-06-29 02:36:19 +00:00
|
|
|
Operand::Counter(id) => Some(Counter::counter_value_reference(id)),
|
2023-06-26 12:28:48 +00:00
|
|
|
Operand::Expression(id) => {
|
2020-12-30 03:19:09 +00:00
|
|
|
self.expressions
|
2023-06-29 02:14:04 +00:00
|
|
|
.get(id)
|
2020-12-30 03:19:09 +00:00
|
|
|
.expect("expression id is out of range")
|
|
|
|
.as_ref()
|
|
|
|
// If an expression was optimized out, assume it would have produced a count
|
|
|
|
// of zero. This ensures that expressions dependent on optimized-out
|
|
|
|
// expressions are still valid.
|
2023-06-29 02:14:04 +00:00
|
|
|
.map_or(Some(Counter::zero()), |_| new_indexes[id].map(Counter::expression))
|
2020-12-30 03:19:09 +00:00
|
|
|
}
|
|
|
|
};
|
2020-07-25 04:14:28 +00:00
|
|
|
|
2020-10-05 23:36:10 +00:00
|
|
|
for (original_index, expression) in
|
2020-07-29 00:45:58 +00:00
|
|
|
self.expressions.iter_enumerated().filter_map(|(original_index, entry)| {
|
2020-07-25 04:14:28 +00:00
|
|
|
// Option::map() will return None to filter out missing expressions. This may happen
|
|
|
|
// if, for example, a MIR-instrumented expression is removed during an optimization.
|
2020-10-05 23:36:10 +00:00
|
|
|
entry.as_ref().map(|expression| (original_index, expression))
|
2020-07-25 04:14:28 +00:00
|
|
|
})
|
|
|
|
{
|
2020-10-05 23:36:10 +00:00
|
|
|
let optional_region = &expression.region;
|
|
|
|
let Expression { lhs, op, rhs, .. } = *expression;
|
2020-07-25 04:14:28 +00:00
|
|
|
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
if let Some(Some((lhs_counter, mut rhs_counter))) = id_to_counter(&new_indexes, lhs)
|
|
|
|
.map(|lhs_counter| {
|
2020-07-25 04:14:28 +00:00
|
|
|
id_to_counter(&new_indexes, rhs).map(|rhs_counter| (lhs_counter, rhs_counter))
|
|
|
|
})
|
|
|
|
{
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
if lhs_counter.is_zero() && op.is_subtract() {
|
|
|
|
// The left side of a subtraction was probably optimized out. As an example,
|
|
|
|
// a branch condition might be evaluated as a constant expression, and the
|
|
|
|
// branch could be removed, dropping unused counters in the process.
|
|
|
|
//
|
|
|
|
// Since counters are unsigned, we must assume the result of the expression
|
|
|
|
// can be no more and no less than zero. An expression known to evaluate to zero
|
|
|
|
// does not need to be added to the coverage map.
|
|
|
|
//
|
|
|
|
// Coverage test `loops_branches.rs` includes multiple variations of branches
|
|
|
|
// based on constant conditional (literal `true` or `false`), and demonstrates
|
|
|
|
// that the expected counts are still correct.
|
|
|
|
debug!(
|
|
|
|
"Expression subtracts from zero (assume unreachable): \
|
|
|
|
original_index={:?}, lhs={:?}, op={:?}, rhs={:?}, region={:?}",
|
|
|
|
original_index, lhs, op, rhs, optional_region,
|
|
|
|
);
|
|
|
|
rhs_counter = Counter::zero();
|
|
|
|
}
|
2020-10-05 23:36:10 +00:00
|
|
|
debug_assert!(
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
lhs_counter.is_zero()
|
|
|
|
// Note: with `as usize` the ID _could_ overflow/wrap if `usize = u16`
|
|
|
|
|| ((lhs_counter.zero_based_id() as usize)
|
|
|
|
<= usize::max(self.counters.len(), self.expressions.len())),
|
|
|
|
"lhs id={} > both counters.len()={} and expressions.len()={}
|
|
|
|
({:?} {:?} {:?})",
|
|
|
|
lhs_counter.zero_based_id(),
|
|
|
|
self.counters.len(),
|
|
|
|
self.expressions.len(),
|
|
|
|
lhs_counter,
|
|
|
|
op,
|
|
|
|
rhs_counter,
|
2020-10-05 23:36:10 +00:00
|
|
|
);
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
|
2020-10-05 23:36:10 +00:00
|
|
|
debug_assert!(
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
rhs_counter.is_zero()
|
|
|
|
// Note: with `as usize` the ID _could_ overflow/wrap if `usize = u16`
|
|
|
|
|| ((rhs_counter.zero_based_id() as usize)
|
|
|
|
<= usize::max(self.counters.len(), self.expressions.len())),
|
|
|
|
"rhs id={} > both counters.len()={} and expressions.len()={}
|
|
|
|
({:?} {:?} {:?})",
|
|
|
|
rhs_counter.zero_based_id(),
|
|
|
|
self.counters.len(),
|
|
|
|
self.expressions.len(),
|
|
|
|
lhs_counter,
|
|
|
|
op,
|
|
|
|
rhs_counter,
|
2020-10-05 23:36:10 +00:00
|
|
|
);
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
|
2020-07-25 04:14:28 +00:00
|
|
|
// Both operands exist. `Expression` operands exist in `self.expressions` and have
|
|
|
|
// been assigned a `new_index`.
|
2020-07-29 00:45:58 +00:00
|
|
|
let mapped_expression_index =
|
|
|
|
MappedExpressionIndex::from(counter_expressions.len());
|
Updates to experimental coverage counter injection
This is a combination of 18 commits.
Commit #2:
Additional examples and some small improvements.
Commit #3:
fixed mir-opt non-mir extensions and spanview title elements
Corrected a fairly recent assumption in runtest.rs that all MIR dump
files end in .mir. (It was appending .mir to the graphviz .dot and
spanview .html file names when generating blessed output files. That
also left outdated files in the baseline alongside the files with the
incorrect names, which I've now removed.)
Updated spanview HTML title elements to match their content, replacing a
hardcoded and incorrect name that was left in accidentally when
originally submitted.
Commit #4:
added more test examples
also improved Makefiles with support for non-zero exit status and to
force validation of tests unless a specific test overrides it with a
specific comment.
Commit #5:
Fixed rare issues after testing on real-world crate
Commit #6:
Addressed PR feedback, and removed temporary -Zexperimental-coverage
-Zinstrument-coverage once again supports the latest capabilities of
LLVM instrprof coverage instrumentation.
Also fixed a bug in spanview.
Commit #7:
Fix closure handling, add tests for closures and inner items
And cleaned up other tests for consistency, and to make it more clear
where spans start/end by breaking up lines.
Commit #8:
renamed "typical" test results "expected"
Now that the `llvm-cov show` tests are improved to normally expect
matching actuals, and to allow individual tests to override that
expectation.
Commit #9:
test coverage of inline generic struct function
Commit #10:
Addressed review feedback
* Removed unnecessary Unreachable filter.
* Replaced a match wildcard with remining variants.
* Added more comments to help clarify the role of successors() in the
CFG traversal
Commit #11:
refactoring based on feedback
* refactored `fn coverage_spans()`.
* changed the way I expand an empty coverage span to improve performance
* fixed a typo that I had accidently left in, in visit.rs
Commit #12:
Optimized use of SourceMap and SourceFile
Commit #13:
Fixed a regression, and synched with upstream
Some generated test file names changed due to some new change upstream.
Commit #14:
Stripping out crate disambiguators from demangled names
These can vary depending on the test platform.
Commit #15:
Ignore llvm-cov show diff on test with generics, expand IO error message
Tests with generics produce llvm-cov show results with demangled names
that can include an unstable "crate disambiguator" (hex value). The
value changes when run in the Rust CI Windows environment. I added a sed
filter to strip them out (in a prior commit), but sed also appears to
fail in the same environment. Until I can figure out a workaround, I'm
just going to ignore this specific test result. I added a FIXME to
follow up later, but it's not that critical.
I also saw an error with Windows GNU, but the IO error did not
specify a path for the directory or file that triggered the error. I
updated the error messages to provide more info for next, time but also
noticed some other tests with similar steps did not fail. Looks
spurious.
Commit #16:
Modify rust-demangler to strip disambiguators by default
Commit #17:
Remove std::process::exit from coverage tests
Due to Issue #77553, programs that call std::process::exit() do not
generate coverage results on Windows MSVC.
Commit #18:
fix: test file paths exceeding Windows max path len
2020-09-01 23:15:17 +00:00
|
|
|
let expression = CounterExpression::new(
|
2020-08-15 11:42:13 +00:00
|
|
|
lhs_counter,
|
|
|
|
match op {
|
|
|
|
Op::Add => ExprKind::Add,
|
|
|
|
Op::Subtract => ExprKind::Subtract,
|
|
|
|
},
|
|
|
|
rhs_counter,
|
Updates to experimental coverage counter injection
This is a combination of 18 commits.
Commit #2:
Additional examples and some small improvements.
Commit #3:
fixed mir-opt non-mir extensions and spanview title elements
Corrected a fairly recent assumption in runtest.rs that all MIR dump
files end in .mir. (It was appending .mir to the graphviz .dot and
spanview .html file names when generating blessed output files. That
also left outdated files in the baseline alongside the files with the
incorrect names, which I've now removed.)
Updated spanview HTML title elements to match their content, replacing a
hardcoded and incorrect name that was left in accidentally when
originally submitted.
Commit #4:
added more test examples
also improved Makefiles with support for non-zero exit status and to
force validation of tests unless a specific test overrides it with a
specific comment.
Commit #5:
Fixed rare issues after testing on real-world crate
Commit #6:
Addressed PR feedback, and removed temporary -Zexperimental-coverage
-Zinstrument-coverage once again supports the latest capabilities of
LLVM instrprof coverage instrumentation.
Also fixed a bug in spanview.
Commit #7:
Fix closure handling, add tests for closures and inner items
And cleaned up other tests for consistency, and to make it more clear
where spans start/end by breaking up lines.
Commit #8:
renamed "typical" test results "expected"
Now that the `llvm-cov show` tests are improved to normally expect
matching actuals, and to allow individual tests to override that
expectation.
Commit #9:
test coverage of inline generic struct function
Commit #10:
Addressed review feedback
* Removed unnecessary Unreachable filter.
* Replaced a match wildcard with remining variants.
* Added more comments to help clarify the role of successors() in the
CFG traversal
Commit #11:
refactoring based on feedback
* refactored `fn coverage_spans()`.
* changed the way I expand an empty coverage span to improve performance
* fixed a typo that I had accidently left in, in visit.rs
Commit #12:
Optimized use of SourceMap and SourceFile
Commit #13:
Fixed a regression, and synched with upstream
Some generated test file names changed due to some new change upstream.
Commit #14:
Stripping out crate disambiguators from demangled names
These can vary depending on the test platform.
Commit #15:
Ignore llvm-cov show diff on test with generics, expand IO error message
Tests with generics produce llvm-cov show results with demangled names
that can include an unstable "crate disambiguator" (hex value). The
value changes when run in the Rust CI Windows environment. I added a sed
filter to strip them out (in a prior commit), but sed also appears to
fail in the same environment. Until I can figure out a workaround, I'm
just going to ignore this specific test result. I added a FIXME to
follow up later, but it's not that critical.
I also saw an error with Windows GNU, but the IO error did not
specify a path for the directory or file that triggered the error. I
updated the error messages to provide more info for next, time but also
noticed some other tests with similar steps did not fail. Looks
spurious.
Commit #16:
Modify rust-demangler to strip disambiguators by default
Commit #17:
Remove std::process::exit from coverage tests
Due to Issue #77553, programs that call std::process::exit() do not
generate coverage results on Windows MSVC.
Commit #18:
fix: test file paths exceeding Windows max path len
2020-09-01 23:15:17 +00:00
|
|
|
);
|
|
|
|
debug!(
|
2020-10-05 23:36:10 +00:00
|
|
|
"Adding expression {:?} = {:?}, region: {:?}",
|
|
|
|
mapped_expression_index, expression, optional_region
|
Updates to experimental coverage counter injection
This is a combination of 18 commits.
Commit #2:
Additional examples and some small improvements.
Commit #3:
fixed mir-opt non-mir extensions and spanview title elements
Corrected a fairly recent assumption in runtest.rs that all MIR dump
files end in .mir. (It was appending .mir to the graphviz .dot and
spanview .html file names when generating blessed output files. That
also left outdated files in the baseline alongside the files with the
incorrect names, which I've now removed.)
Updated spanview HTML title elements to match their content, replacing a
hardcoded and incorrect name that was left in accidentally when
originally submitted.
Commit #4:
added more test examples
also improved Makefiles with support for non-zero exit status and to
force validation of tests unless a specific test overrides it with a
specific comment.
Commit #5:
Fixed rare issues after testing on real-world crate
Commit #6:
Addressed PR feedback, and removed temporary -Zexperimental-coverage
-Zinstrument-coverage once again supports the latest capabilities of
LLVM instrprof coverage instrumentation.
Also fixed a bug in spanview.
Commit #7:
Fix closure handling, add tests for closures and inner items
And cleaned up other tests for consistency, and to make it more clear
where spans start/end by breaking up lines.
Commit #8:
renamed "typical" test results "expected"
Now that the `llvm-cov show` tests are improved to normally expect
matching actuals, and to allow individual tests to override that
expectation.
Commit #9:
test coverage of inline generic struct function
Commit #10:
Addressed review feedback
* Removed unnecessary Unreachable filter.
* Replaced a match wildcard with remining variants.
* Added more comments to help clarify the role of successors() in the
CFG traversal
Commit #11:
refactoring based on feedback
* refactored `fn coverage_spans()`.
* changed the way I expand an empty coverage span to improve performance
* fixed a typo that I had accidently left in, in visit.rs
Commit #12:
Optimized use of SourceMap and SourceFile
Commit #13:
Fixed a regression, and synched with upstream
Some generated test file names changed due to some new change upstream.
Commit #14:
Stripping out crate disambiguators from demangled names
These can vary depending on the test platform.
Commit #15:
Ignore llvm-cov show diff on test with generics, expand IO error message
Tests with generics produce llvm-cov show results with demangled names
that can include an unstable "crate disambiguator" (hex value). The
value changes when run in the Rust CI Windows environment. I added a sed
filter to strip them out (in a prior commit), but sed also appears to
fail in the same environment. Until I can figure out a workaround, I'm
just going to ignore this specific test result. I added a FIXME to
follow up later, but it's not that critical.
I also saw an error with Windows GNU, but the IO error did not
specify a path for the directory or file that triggered the error. I
updated the error messages to provide more info for next, time but also
noticed some other tests with similar steps did not fail. Looks
spurious.
Commit #16:
Modify rust-demangler to strip disambiguators by default
Commit #17:
Remove std::process::exit from coverage tests
Due to Issue #77553, programs that call std::process::exit() do not
generate coverage results on Windows MSVC.
Commit #18:
fix: test file paths exceeding Windows max path len
2020-09-01 23:15:17 +00:00
|
|
|
);
|
|
|
|
counter_expressions.push(expression);
|
2020-10-05 23:36:10 +00:00
|
|
|
new_indexes[original_index] = Some(mapped_expression_index);
|
|
|
|
if let Some(region) = optional_region {
|
|
|
|
expression_regions.push((Counter::expression(mapped_expression_index), region));
|
|
|
|
}
|
|
|
|
} else {
|
Translate counters from Rust 1-based to LLVM 0-based counter ids
A colleague contacted me and asked why Rust's counters start at 1, when
Clangs appear to start at 0. There is a reason why Rust's internal
counters start at 1 (see the docs), and I tried to keep them consistent
when codegenned to LLVM's coverage mapping format. LLVM should be
tolerant of missing counters, but as my colleague pointed out,
`llvm-cov` will silently fail to generate a coverage report for a
function based on LLVM's assumption that the counters are 0-based.
See:
https://github.com/llvm/llvm-project/blob/main/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp#L170
Apparently, if, for example, a function has no branches, it would have
exactly 1 counter. `CounterValues.size()` would be 1, and (with the
1-based index), the counter ID would be 1. This would fail the check
and abort reporting coverage for the function.
It turns out that by correcting for this during coverage map generation,
by subtracting 1 from the Rust Counter ID (both when generating the
counter increment intrinsic call, and when adding counters to the map),
some uncovered functions (including in tests) now appear covered! This
corrects the coverage for a few tests!
2021-04-02 07:08:48 +00:00
|
|
|
bug!(
|
|
|
|
"expression has one or more missing operands \
|
|
|
|
original_index={:?}, lhs={:?}, op={:?}, rhs={:?}, region={:?}",
|
|
|
|
original_index,
|
|
|
|
lhs,
|
|
|
|
op,
|
|
|
|
rhs,
|
|
|
|
optional_region,
|
|
|
|
);
|
2020-07-02 18:27:15 +00:00
|
|
|
}
|
|
|
|
}
|
2020-07-25 04:14:28 +00:00
|
|
|
(counter_expressions, expression_regions.into_iter())
|
2020-06-22 06:29:08 +00:00
|
|
|
}
|
2020-07-02 18:27:15 +00:00
|
|
|
|
2021-12-14 02:52:35 +00:00
|
|
|
fn unreachable_regions(&self) -> impl Iterator<Item = (Counter, &CodeRegion)> {
|
2020-07-25 04:14:28 +00:00
|
|
|
self.unreachable_regions.iter().map(|region| (Counter::zero(), region))
|
|
|
|
}
|
2020-07-02 18:27:15 +00:00
|
|
|
}
|