nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2025-05-14 02:49:40 +00:00
Code Issues Packages Projects Releases Wiki Activity
master
rust/tests/coverage/long_and_wide.cov-map

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

45 lines
1.7 KiB
Plaintext
Raw Permalink Normal View History

Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Function name: long_and_wide::far_function
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Raw bytes (15): 0x[01, 01, 00, 02, 01, 96, 01, 01, 00, 12, 01, 00, 14, 00, 15]
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Number of files: 1
coverage-dump: Dump filenames instead of global file IDs (and bless)
2025-04-24 07:36:50 +00:00
- file 0 => $DIR/long_and_wide.rs
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Number of expressions: 0
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Number of file 0 mappings: 2
- Code(Counter(0)) at (prev + 150, 1) to (start + 0, 18)
- Code(Counter(0)) at (prev + 0, 20) to (start + 0, 21)
coverage: Include the highest counter ID seen in `.cov-map` dumps When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed. (The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
2024-10-08 02:13:05 +00:00
Highest counter ID seen: c0
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Function name: long_and_wide::long_function
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Raw bytes (15): 0x[01, 01, 00, 02, 01, 10, 01, 00, 13, 01, 84, 01, 01, 00, 02]
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Number of files: 1
coverage-dump: Dump filenames instead of global file IDs (and bless)
2025-04-24 07:36:50 +00:00
- file 0 => $DIR/long_and_wide.rs
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Number of expressions: 0
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Number of file 0 mappings: 2
- Code(Counter(0)) at (prev + 16, 1) to (start + 0, 19)
- Code(Counter(0)) at (prev + 132, 1) to (start + 0, 2)
coverage: Include the highest counter ID seen in `.cov-map` dumps When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed. (The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
2024-10-08 02:13:05 +00:00
Highest counter ID seen: c0
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Function name: long_and_wide::main
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Raw bytes (29): 0x[01, 01, 00, 05, 01, 07, 01, 00, 0a, 01, 01, 05, 00, 12, 01, 01, 05, 00, 12, 01, 01, 05, 00, 11, 01, 01, 01, 00, 02]
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Number of files: 1
coverage-dump: Dump filenames instead of global file IDs (and bless)
2025-04-24 07:36:50 +00:00
- file 0 => $DIR/long_and_wide.rs
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Number of expressions: 0
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Number of file 0 mappings: 5
- Code(Counter(0)) at (prev + 7, 1) to (start + 0, 10)
- Code(Counter(0)) at (prev + 1, 5) to (start + 0, 18)
- Code(Counter(0)) at (prev + 1, 5) to (start + 0, 18)
- Code(Counter(0)) at (prev + 1, 5) to (start + 0, 17)
- Code(Counter(0)) at (prev + 1, 1) to (start + 0, 2)
coverage: Include the highest counter ID seen in `.cov-map` dumps When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed. (The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
2024-10-08 02:13:05 +00:00
Highest counter ID seen: c0
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Function name: long_and_wide::wide_function
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Raw bytes (23): 0x[01, 01, 00, 03, 01, 0e, 01, 00, 13, 01, 00, 86, 01, 00, 88, 01, 01, 00, 8a, 01, 00, 8b, 01]
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Number of files: 1
coverage-dump: Dump filenames instead of global file IDs (and bless)
2025-04-24 07:36:50 +00:00
- file 0 => $DIR/long_and_wide.rs
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Number of expressions: 0
coverage: Only merge adjacent coverage spans This also removes some manipulation of the function signature span that only made sense in the context of merging non-adjacent spans.
2025-04-12 07:52:55 +00:00
Number of file 0 mappings: 3
- Code(Counter(0)) at (prev + 14, 1) to (start + 0, 19)
- Code(Counter(0)) at (prev + 0, 134) to (start + 0, 136)
- Code(Counter(0)) at (prev + 0, 138) to (start + 0, 139)
coverage: Include the highest counter ID seen in `.cov-map` dumps When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed. (The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
2024-10-08 02:13:05 +00:00
Highest counter ID seen: c0
Add test suite `coverage-map` to test coverage mappings emitted by LLVM We compile each test file to LLVM IR assembly, and then pass that IR to a dedicated program that can decode LLVM coverage maps and print them in a more human-readable format. We can then check that output against known-good snapshots. This test suite has some advantages over the existing `run-coverage` tests: - We can test coverage instrumentation without needing to run target binaries. - We can observe subtle improvements/regressions in the underlying coverage mappings that don't make a visible difference to coverage reports.
2023-08-14 03:00:28 +00:00
Reference in New Issue Copy Permalink