Tracking issue for stabilizing the #[coverage(..)]
attribute
#134749
Labels
A-code-coverage
Area: Source-based code coverage (-Cinstrument-coverage)
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
This is a sub-issue of #84605 for tracking the remaining obstacles to stabilization of the coverage attribute. The
#[coverage(off)]
and#[coverage(on)]
attributes provide hints for whether-Cinstrument-coverage
should instrument a particular function or not.The feature gate for the issue is
#![feature(coverage_attribute)]
.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.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.
Steps
#[coverage(..)]
attribute error messages to match the current implementation #134750Unresolved Questions
Implementation history
This functionality was originally introduced as an unstable feature, without a formal RFC. After a period of inactivity, there was a user-led push for stabilization, leading to further design and implementation changes.
A stabilization PR was briefly merged on nightly due to a process mixup, then reverted. This tracking issue picks up after that revert.
#[coverage(..)]
apply recursively to nested functions #126721#[coverage(..)]
attribute #134672The text was updated successfully, but these errors were encountered: