This website requires JavaScript.
Explore
Help
Register
Sign In
rust-lang
/
rust
Watch
1
Star
0
Fork
0
You've already forked rust
Code
Issues
Pull Requests
Actions
1
Packages
Projects
Releases
Wiki
Activity
Files
b58afc088f34341cdffad8d12bf1a13331ff7deb
rust
/
src
/
librustc_codegen_ssa
/
coverageinfo
/
mod.rs
4 lines
37 B
Rust
Raw
Normal View
History
Unescape
Escape
add spans to injected coverage counters added regions with counter expressions and counters. Added codegen_llvm/coverageinfo mod for upcoming coverage map Move coverage region collection to CodegenCx finalization Moved from `query coverageinfo` (renamed from `query coverage_data`), as discussed in the PR at: https://github.com/rust-lang/rust/pull/73684#issuecomment-649882503 Address merge conflict in MIR instrument_coverage test The MIR test output format changed for int types. moved debug messages out of block.rs This makes the block.rs calls to add coverage mapping data to the CodegenCx much more concise and readable. move coverage intrinsic handling into llvm impl I realized that having half of the coverage intrinsic handling in `rustc_codegen_ssa` and half in `rustc_codegen_llvm` meant that any non-llvm backend would be bound to the same decisions about how the coverage-related MIR terminators should be handled. To fix this, I moved the non-codegen portion of coverage intrinsic handling into its own trait, and implemented it in `rustc_codegen_llvm` alongside `codegen_intrinsic_call`. I also added the (required?) stubs for the new intrinsics to `IntrepretCx::emulate_intrinsic()`, to ensure calls to this function do not fail if called with these new but known intrinsics. address PR Feedback on 28 June 2020 2:48pm PDT
2020-06-21 23:29:08 -07:00
pub
mod
map
;
Fixed coverage map issues; better aligned with LLVM APIs Found some problems with the coverage map encoding when testing with more than one counter per function. While debugging, I realized some better ways to structure the Rust implementation of the coverage mapping generator. I refactored somewhat, resulting in less code overall, expanded coverage of LLVM Coverage Map capabilities, and much closer alignment with LLVM data structures, APIs, and naming. This should be easier to follow and easier to maintain.
2020-07-24 21:14:28 -07:00
pub
use
map
::
ExprKind
;
Reference in New Issue
Copy Permalink