Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mention that code coverage can change from release to release #1700

Closed
wants to merge 1 commit into from
Closed

Mention that code coverage can change from release to release #1700

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/attributes/coverage-instrumentation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@
The following [attributes] are used for controlling coverage instrumentation.

> **Note**: Coverage instrumentation is controlled in `rustc` with the [`-C instrument-coverage`] compiler flag.
Exact specifics of how code coverage works or what code is reported in code coverage data may change from release to release.
Copy link
Member

@workingjubilee workingjubilee Dec 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding of what @Zalathar has expressed a desire for, here, is that we call out more specifically that "on" and "off" are "best effort" interpretations, and that "on" will inevitably be contested when there is a new coverage knob that could be enabled by coverage(on). We then will get the following two requests:

  • "This flag is vitally important for useful coverage in my area, I recommend you enable this by default when on is indicated and add some manner of #[coverage(partial)]."
  • "This flag is too costly and doesn't improve useful coverage info in my area, I recommend you disable this by default and require #[coverage(full)] to opt-in."

And that's assuming there aren't like a dozen other requests of subtle variations on these. We have to make someone unhappy.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The approach I would personally like to see is to explicitly say that the syntax of the coverage attribute is stable, in terms of what an individual attribute looks like and where it can be placed, but the actual effect of the attribute on coverage instrumentation is not subject to stability promises and may change in the future.

(And then we would still proceed to document the current behaviour, because we want people to be able to use it.)

I don't know whether that is considered OK or not; as far as I'm aware there hasn't been much discussion of this point.


[`-C instrument-coverage`]: ../../rustc/instrument-coverage.html

Expand Down
Loading