-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
coverage: Explicitly test the coverage maps produced by codegen/LLVM #114843
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
These commits modify the If this was unintentional then you should revert the changes before this PR is merged. |
I plan to use these tests to help ensure that the changes in #114399 don't regress/bloat the emitted coverage mappings. |
This comment has been minimized.
This comment has been minimized.
2a4d4e3
to
37c010e
Compare
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
37c010e
to
6085e7f
Compare
src/tools/coverage-dump/Cargo.toml
Outdated
[dependencies] | ||
anyhow = "1.0.71" | ||
md5 = { package = "md-5" , version = "0.10.5" } | ||
miniz_oxide = "0.7.1" | ||
regex = "1.8.4" | ||
rustc-demangle = "0.1.23" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of these version numbers are just copied from whatever happened to be in Cargo.lock
at the time, to avoid bumping the existing versions.
6c19230
to
5a5511c
Compare
[[package]] | ||
name = "leb128" | ||
version = "0.2.5" | ||
source = "registry+https://github.com/rust-lang/crates.io-index" | ||
checksum = "884e2677b40cc8c339eaefcb701c32ef1fd2493d71118dc0ca4b6a736c93bd67" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell, leb128
is maintained and published by the same org as gimli
, under the same Apache2/MIT license.
(gimli
previously used leb128
as a dependency, but nowadays it uses its own slightly-modified copy in a submodule.)
5a5511c
to
317c18d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉 its a lot more readable like this :-)
2d68e55
to
33f3722
Compare
33f3722
to
55f2e57
Compare
I decided to remove |
db419f6
to
307d599
Compare
Looks like CI flaked out again on that run. |
Also note that this and #114656 are racing in silent conflict; whichever one lands first will require the other to update |
@bors retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (ab45885): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 628.171s -> 626.58s (-0.25%) |
coverage: Don't bother renumbering expressions on the Rust side The LLVM API that we use to encode coverage mappings already has its own code for removing unused coverage expressions and renumbering the rest. This lets us get rid of our own complex renumbering code, making it easier to change our coverage code in other ways. --- Now that we have tests for coverage mappings (rust-lang#114843), I've been able to verify that this PR doesn't make the coverage mappings worse, thanks to an explicit simplification step.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
These multi-file tests were not copied over in rust-lang#114843 because they weren't working, but it turns out that they just need the correct crate-type.
compiletest: Unify `cmd2procres` with `run_command_to_procres` Historical context: I originally added `run_command_to_procres` in rust-lang#112300 and rust-lang#114843, because I didn't like the overly-specific failure message in `cmd2procres`, but at the time I didn't feel confident enough to change the existing code, so I just added my own similar code. Now I'm going back to remove this redundancy by eliminating `cmd2procress`, and adjusting all callers to use a slightly-tweaked `run_command_to_procres` instead.
compiletest: Unify `cmd2procres` with `run_command_to_procres` Historical context: I originally added `run_command_to_procres` in rust-lang#112300 and rust-lang#114843, because I didn't like the overly-specific failure message in `cmd2procres`, but at the time I didn't feel confident enough to change the existing code, so I just added my own similar code. Now I'm going back to remove this redundancy by eliminating `cmd2procress`, and adjusting all callers to use a slightly-tweaked `run_command_to_procres` instead.
Rollup merge of rust-lang#125753 - Zalathar:procres, r=jieyouxu compiletest: Unify `cmd2procres` with `run_command_to_procres` Historical context: I originally added `run_command_to_procres` in rust-lang#112300 and rust-lang#114843, because I didn't like the overly-specific failure message in `cmd2procres`, but at the time I didn't feel confident enough to change the existing code, so I just added my own similar code. Now I'm going back to remove this redundancy by eliminating `cmd2procress`, and adjusting all callers to use a slightly-tweaked `run_command_to_procres` instead.
Our existing coverage tests verify the output of end-to-end coverage reports, but we don't have any way to test the specific mapping information (code regions and their associated counters) that are emitted by
rustc_codegen_llvm
and LLVM. That makes it harder to to be confident in changes that would modify those mappings (whether deliberately or accidentally).This PR addresses that by adding a new
coverage-map
test suite that does the following:.ll
)src/tools/coverage-dump
) that extracts and decodes coverage mappings, and prints them in a more human-readable formatI recommend excluding the last commit while reviewing the main changes, because that last commit is just ~40 test files copied over from
tests/run-coverage
, plus their blessed coverage-map snapshots and a readme file. Those snapshots aren't really intended to be checked by hand; they're mostly there to increase the chances that an unintended change to coverage maps will be observable (even if it requires relatively specific circumstances to manifest).