This is a tracking issue for the MCP "Implement LLVM-compatible source-based code coverage" (rust-lang/compiler-team#278).
Original feature request: Issue #34701.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved Questions
There are no unresolved questions from the MCP.
Some implementation options were debated and, if deferred, were logged as FIXME comments in the compiler source code or tests. FIXME comments related to stabilization have been added as rust-lang/rust issues.
-
If/when stabilized, will the compiler flag be updated to -C instrument-coverage? (If so, the -Z variant could also be supported for some time, to ease migrations for existing users and scripts.)
-
The Rust coverage implementation depends on (and automatically turns on) -Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizing v0 symbol-mangling first? If so, what is the current status and timeline?
-
The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM.
-
What other questions need to be answered before the feature can be stabilized?
Open Issues related to this Tracking Issue
Somewhat ordered by priority:
Also, note the issue tracking label: A-code-coverage
Implementation history
This is a tracking issue for the MCP "Implement LLVM-compatible source-based code coverage" (rust-lang/compiler-team#278).
Original feature request: Issue #34701.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Rustc Dev Guideincludes detailed documentation on the implementation in a new section,LLVM Source-Based Code CoverageRust Unstable Bookat https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/source-based-code-coverage.htmlInside Rust Blogarticle at https://blog.rust-lang.org/inside-rust/2020/11/12/source-based-code-coverage.htmlUnresolved Questions
There are no unresolved questions from the MCP.
Some implementation options were debated and, if deferred, were logged as
FIXMEcomments in the compiler source code or tests.FIXMEcomments related to stabilization have been added asrust-lang/rustissues.If/when stabilized, will the compiler flag be updated to
-C instrument-coverage? (If so, the-Zvariant could also be supported for some time, to ease migrations for existing users and scripts.)The Rust coverage implementation depends on (and automatically turns on)
-Z symbol-mangling-version=v0. Will stabilizing this feature depend on stabilizingv0symbol-mangling first? If so, what is the current status and timeline?The Rust coverage implementation implements the latest version of LLVM's Coverage Mapping Format (version 4), which forces a dependency on LLVM 11 or later. A compiler error is generated if attempting to compile with coverage, and using an older version of LLVM.
What other questions need to be answered before the feature can be stabilized?
Open Issues related to this Tracking Issue
Somewhat ordered by priority:
-Zinstrument-coverage" (Rustdoc doctests should have their file/lines remapped when using-Zinstrument-coverage#79417)#[should_panic]tests andcatch_unwind()handlers" (MIR InstrumentCoverage: Improve coverage of#[should_panic]tests andcatch_unwind()handlers #78544)FakeReadstatements be more consistent?" (MIR InstrumentCoverage - Can the source_info.span forFakeReadstatements be more consistent? #78546)Also, note the issue tracking label: A-code-coverage
Implementation history
nightlychannel as of November 8, 2020.