Tracking issue for stabilizing the `#[coverage(..)]` attribute

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

• Draft and review user-facing documentation (guide-level and reference-level) that describes the feature, and clearly indicates which aspects are stably guaranteed vs subject to change.
• Check that the feature is adequately tested.
• Get clear sign-off from T-lang, including approval of the documented stability boundary.
  • Bring behavior around closures in line with optimize; see https://github.com/rust-lang/rust/pull/157273#issuecomment-4987202013.
• Get clear sign-off from the de-facto code owner (Zalathar) and T-compiler.
• Adjust error messages and error-code documentation to reflect the current design.
  • #134750
• New stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Which aspects of the attribute are stably guaranteed vs subject to change?

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.

• (add earlier PRs here as desired)
• #126721
• #130766
• #134672

Start with this tracking issue, its parent #84605, and the implementation history in #126721, #130766, and #134672. Review the linked stabilization guidance and determine the remaining documentation, testing, error-message, closure-behavior, and team-signoff requirements. Done means the listed steps are completed and a stabilization PR is prepared.