Repository navigation
Open
Labels
A-doc-coverageArea: Calculating how much of a crate has documentationArea: Calculating how much of a crate has documentationB-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCS-tracking-needs-summaryStatus: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Description
FIXME: Write a proper synopsis.
Note
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.
Instead, open a dedicated issue for the specific matter or post in the #t-rustdoc Zulip channel.
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
- Implementation PR
- Stabilization PR
Implementation history
FIXME: Recover the history.
Reacted by Phil Hansch, Ruihang Xia and David Thievon
Metadata
Metadata
Assignees
Labels
A-doc-coverageArea: Calculating how much of a crate has documentationArea: Calculating how much of a crate has documentationB-unstableBlocker: Implemented in the nightly compiler and unstable.Blocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCS-tracking-needs-summaryStatus: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Activity
QuietMisdreavus commentedon Feb 5, 2019
I have a in-progress branch locally that i haven't pushed with this. The current idea is that you send an additional flag to rustdoc that makes it count items in the crate, and print something like the following instead of generating docs:
The reason it counts trait impls separately is because trait impls can have their own documentation, but if you don't add docs it inherits from the trait's own docs.
Right now, the following items are not counted:
#[automatically_derived]attribute)#[doc(hidden)]items (i plan on combining this with--document-private-itemsto get a separate coverage count for private items)pub use/pub extern cratestatements, since those doc comments are not printedThere's an outstanding question on whether we can detect whether a trait impl came from a derive macro (e.g. most of the undocumented trait impls in that sample came from
#[derive(Serialize)]), but detecting that seems to be more difficult than i anticipated.I've also got a thing right now where if you pass both the new flag and
--verbose, it prints the undocumented items it found:...granted, this is very similar to the missing-docs lint, so this may not be completely useful.
GuillaumeGomez commentedon Feb 5, 2019
Maybe not but at least it allows to have an easy option to directly get a documentation coverage result.
sanxiyn commentedon Mar 21, 2019
Fixed by #58626.
[-][rustdoc] add a coverage option[/-][+][rustdoc] Tracking issue for `--show-coverage`[/+]QuietMisdreavus commentedon Mar 21, 2019
Since the feature is unstable, i'm going to reopen this issue to repurpose it as a tracking issue. I want to try adding a JSON output option to it, for ease of automatic checking, and then i'd like to integrate it into bootstrap or our CI if possible.
steveklabnik commentedon Apr 21, 2020
Triage: this flag is still unstable.
Nemo157 commentedon Oct 5, 2020
I don't have time to write a proper bug ticket for it, but when using
--show-coveragewithroaring 0.6.1theimplblocks from other files seem to be ignored, giving a total of 9 items rather than the 50-something there actually are.EDIT: 4 years later: #129007
awwsmm commentedon Dec 5, 2023
Could I bump this? I would really love this feature, and it's been a while since there were any updates here.
GuillaumeGomez commentedon Dec 5, 2023
What do you mean?
EDIT: About the "Could I bump this?"
awwsmm commentedon Dec 5, 2023
I meant "could I refresh the attention of whoever had been working on this." From the comments here, it looks like the effort to stabilize this flag has stalled. I'd offer to help, but I'm pretty new to Rust.
GuillaumeGomez commentedon Dec 5, 2023
Ah I see. Well, we need to make an RFC for that. If you're motivated to write it (which needs to describe exactly which item is part of the count etc), I can help.
crumblingstatue commentedon Oct 21, 2024
Could it be possible for the coverage report to take into account scraped examples (-Zrustdoc-scrape-examples)?
One might not want to make custom examples for all items if scraped examples suffice.
[-][rustdoc] Tracking issue for `--show-coverage`[/-][+]rustdoc: Tracking issue for command-line flag `--show-coverage`[/+]fix: make doc-coverage nightly pin effective (#48)