2020-06-22 06:29:08 +00:00
|
|
|
//! Metadata from source code coverage analysis and instrumentation.
|
|
|
|
|
2020-08-15 11:42:13 +00:00
|
|
|
use rustc_macros::HashStable;
|
|
|
|
use rustc_span::Symbol;
|
|
|
|
|
|
|
|
use std::cmp::Ord;
|
|
|
|
use std::fmt::{self, Debug, Formatter};
|
|
|
|
|
|
|
|
rustc_index::newtype_index! {
|
2020-10-05 23:36:10 +00:00
|
|
|
/// An ExpressionOperandId value is assigned directly from either a
|
|
|
|
/// CounterValueReference.as_u32() (which ascend from 1) or an ExpressionOperandId.as_u32()
|
|
|
|
/// (which _*descend*_ from u32::MAX). Id value `0` (zero) represents a virtual counter with a
|
|
|
|
/// constant value of `0`.
|
2020-08-15 11:42:13 +00:00
|
|
|
pub struct ExpressionOperandId {
|
|
|
|
derive [HashStable]
|
|
|
|
DEBUG_FORMAT = "ExpressionOperandId({})",
|
|
|
|
MAX = 0xFFFF_FFFF,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
impl ExpressionOperandId {
|
|
|
|
/// An expression operand for a "zero counter", as described in the following references:
|
|
|
|
///
|
2021-10-19 09:09:43 +00:00
|
|
|
/// * <https://github.com/rust-lang/llvm-project/blob/rustc/13.0-2021-09-30/llvm/docs/CoverageMappingFormat.rst#counter>
|
|
|
|
/// * <https://github.com/rust-lang/llvm-project/blob/rustc/13.0-2021-09-30/llvm/docs/CoverageMappingFormat.rst#tag>
|
|
|
|
/// * <https://github.com/rust-lang/llvm-project/blob/rustc/13.0-2021-09-30/llvm/docs/CoverageMappingFormat.rst#counter-expressions>
|
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
|
|
|
///
|
|
|
|
/// This operand can be used to count two or more separate code regions with a single counter,
|
|
|
|
/// if they run sequentially with no branches, by injecting the `Counter` in a `BasicBlock` for
|
|
|
|
/// one of the code regions, and inserting `CounterExpression`s ("add ZERO to the counter") in
|
|
|
|
/// the coverage map for the other code regions.
|
|
|
|
pub const ZERO: Self = Self::from_u32(0);
|
|
|
|
}
|
|
|
|
|
2020-08-15 11:42:13 +00:00
|
|
|
rustc_index::newtype_index! {
|
|
|
|
pub struct CounterValueReference {
|
|
|
|
derive [HashStable]
|
|
|
|
DEBUG_FORMAT = "CounterValueReference({})",
|
|
|
|
MAX = 0xFFFF_FFFF,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
impl CounterValueReference {
|
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
|
|
|
/// Counters start at 1 to reserve 0 for ExpressionOperandId::ZERO.
|
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
|
|
|
pub const START: Self = Self::from_u32(1);
|
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
|
|
|
|
|
|
|
/// Returns explicitly-requested zero-based version of the counter id, used
|
|
|
|
/// during codegen. LLVM expects zero-based indexes.
|
2022-03-08 14:39:52 +00:00
|
|
|
pub fn zero_based_index(self) -> u32 {
|
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
|
|
|
let one_based_index = self.as_u32();
|
|
|
|
debug_assert!(one_based_index > 0);
|
|
|
|
one_based_index - 1
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2020-08-15 11:42:13 +00:00
|
|
|
rustc_index::newtype_index! {
|
2020-10-05 23:36:10 +00:00
|
|
|
/// InjectedExpressionId.as_u32() converts to ExpressionOperandId.as_u32()
|
|
|
|
///
|
|
|
|
/// Values descend from u32::MAX.
|
|
|
|
pub struct InjectedExpressionId {
|
|
|
|
derive [HashStable]
|
|
|
|
DEBUG_FORMAT = "InjectedExpressionId({})",
|
|
|
|
MAX = 0xFFFF_FFFF,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rustc_index::newtype_index! {
|
|
|
|
/// InjectedExpressionIndex.as_u32() translates to u32::MAX - ExpressionOperandId.as_u32()
|
|
|
|
///
|
|
|
|
/// Values ascend from 0.
|
2020-08-15 11:42:13 +00:00
|
|
|
pub struct InjectedExpressionIndex {
|
|
|
|
derive [HashStable]
|
|
|
|
DEBUG_FORMAT = "InjectedExpressionIndex({})",
|
|
|
|
MAX = 0xFFFF_FFFF,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rustc_index::newtype_index! {
|
2020-10-05 23:36:10 +00:00
|
|
|
/// MappedExpressionIndex values ascend from zero, and are recalculated indexes based on their
|
|
|
|
/// array position in the LLVM coverage map "Expressions" array, which is assembled during the
|
|
|
|
/// "mapgen" process. They cannot be computed algorithmically, from the other `newtype_index`s.
|
2020-08-15 11:42:13 +00:00
|
|
|
pub struct MappedExpressionIndex {
|
|
|
|
derive [HashStable]
|
|
|
|
DEBUG_FORMAT = "MappedExpressionIndex({})",
|
|
|
|
MAX = 0xFFFF_FFFF,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl From<CounterValueReference> for ExpressionOperandId {
|
|
|
|
#[inline]
|
|
|
|
fn from(v: CounterValueReference) -> ExpressionOperandId {
|
|
|
|
ExpressionOperandId::from(v.as_u32())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-05 23:36:10 +00:00
|
|
|
impl From<InjectedExpressionId> for ExpressionOperandId {
|
2020-08-15 11:42:13 +00:00
|
|
|
#[inline]
|
2020-10-05 23:36:10 +00:00
|
|
|
fn from(v: InjectedExpressionId) -> ExpressionOperandId {
|
2020-08-15 11:42:13 +00:00
|
|
|
ExpressionOperandId::from(v.as_u32())
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-04 13:52:14 +00:00
|
|
|
#[derive(Clone, PartialEq, TyEncodable, TyDecodable, Hash, HashStable, TypeFoldable)]
|
2020-08-15 11:42:13 +00:00
|
|
|
pub enum CoverageKind {
|
|
|
|
Counter {
|
|
|
|
function_source_hash: u64,
|
|
|
|
id: CounterValueReference,
|
|
|
|
},
|
|
|
|
Expression {
|
2020-10-05 23:36:10 +00:00
|
|
|
id: InjectedExpressionId,
|
2020-08-15 11:42:13 +00:00
|
|
|
lhs: ExpressionOperandId,
|
|
|
|
op: Op,
|
|
|
|
rhs: ExpressionOperandId,
|
|
|
|
},
|
|
|
|
Unreachable,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl CoverageKind {
|
|
|
|
pub fn as_operand_id(&self) -> ExpressionOperandId {
|
2020-10-05 23:36:10 +00:00
|
|
|
use CoverageKind::*;
|
2020-08-15 11:42:13 +00:00
|
|
|
match *self {
|
2020-10-05 23:36:10 +00:00
|
|
|
Counter { id, .. } => ExpressionOperandId::from(id),
|
|
|
|
Expression { id, .. } => ExpressionOperandId::from(id),
|
|
|
|
Unreachable => bug!("Unreachable coverage cannot be part of an expression"),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn is_expression(&self) -> bool {
|
2020-12-24 01:55:21 +00:00
|
|
|
matches!(self, Self::Expression { .. })
|
2020-10-05 23:36:10 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Debug for CoverageKind {
|
|
|
|
fn fmt(&self, fmt: &mut Formatter<'_>) -> fmt::Result {
|
|
|
|
use CoverageKind::*;
|
|
|
|
match self {
|
|
|
|
Counter { id, .. } => write!(fmt, "Counter({:?})", id.index()),
|
|
|
|
Expression { id, lhs, op, rhs } => write!(
|
|
|
|
fmt,
|
|
|
|
"Expression({:?}) = {} {} {}",
|
|
|
|
id.index(),
|
|
|
|
lhs.index(),
|
|
|
|
if *op == Op::Add { "+" } else { "-" },
|
|
|
|
rhs.index(),
|
|
|
|
),
|
|
|
|
Unreachable => write!(fmt, "Unreachable"),
|
2020-08-15 11:42:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-04 13:52:14 +00:00
|
|
|
#[derive(
|
|
|
|
Clone,
|
|
|
|
TyEncodable,
|
|
|
|
TyDecodable,
|
|
|
|
Hash,
|
|
|
|
HashStable,
|
|
|
|
TypeFoldable,
|
|
|
|
PartialEq,
|
|
|
|
Eq,
|
|
|
|
PartialOrd,
|
|
|
|
Ord
|
|
|
|
)]
|
2020-08-15 11:42:13 +00:00
|
|
|
pub struct CodeRegion {
|
|
|
|
pub file_name: Symbol,
|
|
|
|
pub start_line: u32,
|
|
|
|
pub start_col: u32,
|
|
|
|
pub end_line: u32,
|
|
|
|
pub end_col: u32,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Debug for CodeRegion {
|
|
|
|
fn fmt(&self, fmt: &mut Formatter<'_>) -> fmt::Result {
|
|
|
|
write!(
|
|
|
|
fmt,
|
|
|
|
"{}:{}:{} - {}:{}",
|
|
|
|
self.file_name, self.start_line, self.start_col, self.end_line, self.end_col
|
|
|
|
)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-04 13:52:14 +00:00
|
|
|
#[derive(Copy, Clone, Debug, PartialEq, TyEncodable, TyDecodable, Hash, HashStable, TypeFoldable)]
|
2020-08-15 11:42:13 +00:00
|
|
|
pub enum Op {
|
|
|
|
Subtract,
|
|
|
|
Add,
|
2020-06-22 06:29:08 +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
|
|
|
|
|
|
|
impl Op {
|
|
|
|
pub fn is_add(&self) -> bool {
|
|
|
|
matches!(self, Self::Add)
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn is_subtract(&self) -> bool {
|
|
|
|
matches!(self, Self::Subtract)
|
|
|
|
}
|
|
|
|
}
|