rustdoc: Erase #![doc(document_private_items)]
#146495
Merged
+2
−17
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
Collaborator
|
r? @notriddle rustbot has assigned @notriddle. Use |
fmease
removed
the
T-compiler
Member
Author
|
@rfcbot merge |
Collaborator
|
Team member @fmease has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rust-rfcbot
added
proposed-final-comment-period
fmease
changed the title
#![doc(document_private_items)]#![doc(document_private_items)]
Member
Author
|
@Manishearth, @lolbinarycat, @camelid Friendly ping :^) What are we thinking? Side note: I'll probably reissue the pFCP once 3 votes are outstanding given the fact that Nemo is no longer part of the team. |
Member
Author
|
Three votes outstanding (Nemo, camelid, jsha). Nemo is now an alumnus (rust-lang/team#1984). So as announced I'll now cancel the pFCP, reissue it and check the boxes for everyone who already voted in #146495 (comment) (you can see edit history to confirm authenticity)! @rfcbot cancel |
Collaborator
|
@fmease proposal cancelled. |
rust-rfcbot
removed
proposed-final-comment-period
Member
Author
|
Please read:
@rfcbot merge |
Collaborator
|
Team member @fmease has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rust-rfcbot
added
proposed-final-comment-period
Collaborator
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
fmease
added
S-waiting-on-fcp
rust-rfcbot
added
finished-final-comment-period
Collaborator
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Member
|
Thanks everyone! @bors r+ rollup |
Collaborator
bors
added
the
S-waiting-on-bors
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Nov 11, 2025
…s-attr, r=GuillaumeGomez rustdoc: Erase `#![doc(document_private_items)]` I just found out about the existence of `#![doc(document_private_items)]`. Apparently it was added by PR rust-lang#50669 back in 2018 without any tests or docs as a replacement for some specific forms of the removed `#![doc(passes)]` / `#![doc(no_default_passes)]`. However, rustc and rustdoc actually emit the deny-by-default lint `invalid_doc_attributes` for it (but if you allow it, the attribute does function)! To be more precise since PR rust-lang#82708 (1.52, May 2021) which introduced lint `invalid_doc_attributes`, rust{,do}c has emitted a future-incompat warning for this attribute. And since PR rust-lang#111505 (1.78, May 2024) that lint is deny by default. I presume nobody knew this attribute existed and thus it was never allowlisted. Given the fact that since 2021 nobody has ever opened a ticket ([via](https://github.com/rust-lang/rust/issues?q=is%3Aissue+document_private_items)) complaining about the lint emission and the fact that GitHub code search doesn't yield any actual uses ([via](https://github.com/search?q=%2F%23%21%5C%5Bdoc%5C%28.*%3Fdocument_private_items%2F+language%3ARust&type=code&ref=advsearch)), I'm led to believe that nobody knows about and uses this attribute. I don't find the existence of this attribute to be justified since in my view the flag `--document-private-items` is strictly superior: In most if not all cases, you don't want to "couple" your crate with this "mode" even if you gate it behind a cfg; instead, you most likely want to set this manually at invocation time, via a build config file like `.cargo/config.toml` or via a command runner like `just` I'd say. Because of this I propose to wipe this attribute from existence. I don't believe it's worth cratering this (i.e., temporarily emitting a hard error for this attribute and running crater) given the fact that it's been undocumented since forever and led to a warning for years.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Nov 11, 2025
…s-attr, r=GuillaumeGomez rustdoc: Erase `#![doc(document_private_items)]` I just found out about the existence of `#![doc(document_private_items)]`. Apparently it was added by PR rust-lang#50669 back in 2018 without any tests or docs as a replacement for some specific forms of the removed `#![doc(passes)]` / `#![doc(no_default_passes)]`. However, rustc and rustdoc actually emit the deny-by-default lint `invalid_doc_attributes` for it (but if you allow it, the attribute does function)! To be more precise since PR rust-lang#82708 (1.52, May 2021) which introduced lint `invalid_doc_attributes`, rust{,do}c has emitted a future-incompat warning for this attribute. And since PR rust-lang#111505 (1.78, May 2024) that lint is deny by default. I presume nobody knew this attribute existed and thus it was never allowlisted. Given the fact that since 2021 nobody has ever opened a ticket ([via](https://github.com/rust-lang/rust/issues?q=is%3Aissue+document_private_items)) complaining about the lint emission and the fact that GitHub code search doesn't yield any actual uses ([via](https://github.com/search?q=%2F%23%21%5C%5Bdoc%5C%28.*%3Fdocument_private_items%2F+language%3ARust&type=code&ref=advsearch)), I'm led to believe that nobody knows about and uses this attribute. I don't find the existence of this attribute to be justified since in my view the flag `--document-private-items` is strictly superior: In most if not all cases, you don't want to "couple" your crate with this "mode" even if you gate it behind a cfg; instead, you most likely want to set this manually at invocation time, via a build config file like `.cargo/config.toml` or via a command runner like `just` I'd say. Because of this I propose to wipe this attribute from existence. I don't believe it's worth cratering this (i.e., temporarily emitting a hard error for this attribute and running crater) given the fact that it's been undocumented since forever and led to a warning for years.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Nov 11, 2025
…s-attr, r=GuillaumeGomez rustdoc: Erase `#![doc(document_private_items)]` I just found out about the existence of `#![doc(document_private_items)]`. Apparently it was added by PR rust-lang#50669 back in 2018 without any tests or docs as a replacement for some specific forms of the removed `#![doc(passes)]` / `#![doc(no_default_passes)]`. However, rustc and rustdoc actually emit the deny-by-default lint `invalid_doc_attributes` for it (but if you allow it, the attribute does function)! To be more precise since PR rust-lang#82708 (1.52, May 2021) which introduced lint `invalid_doc_attributes`, rust{,do}c has emitted a future-incompat warning for this attribute. And since PR rust-lang#111505 (1.78, May 2024) that lint is deny by default. I presume nobody knew this attribute existed and thus it was never allowlisted. Given the fact that since 2021 nobody has ever opened a ticket ([via](https://github.com/rust-lang/rust/issues?q=is%3Aissue+document_private_items)) complaining about the lint emission and the fact that GitHub code search doesn't yield any actual uses ([via](https://github.com/search?q=%2F%23%21%5C%5Bdoc%5C%28.*%3Fdocument_private_items%2F+language%3ARust&type=code&ref=advsearch)), I'm led to believe that nobody knows about and uses this attribute. I don't find the existence of this attribute to be justified since in my view the flag `--document-private-items` is strictly superior: In most if not all cases, you don't want to "couple" your crate with this "mode" even if you gate it behind a cfg; instead, you most likely want to set this manually at invocation time, via a build config file like `.cargo/config.toml` or via a command runner like `just` I'd say. Because of this I propose to wipe this attribute from existence. I don't believe it's worth cratering this (i.e., temporarily emitting a hard error for this attribute and running crater) given the fact that it's been undocumented since forever and led to a warning for years.
bors
added a commit
that referenced
this pull request
Nov 11, 2025
Rollup of 16 pull requests Successful merges: - #141470 (Add new `function_casts_as_integer` lint) - #143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks) - #146495 (rustdoc: Erase `#![doc(document_private_items)]`) - #147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`) - #147833 (rustdoc-json: move `target` to `json::conversions`) - #147952 (Add a timeout to the `remote-test-client` connection) - #147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers) - #148480 (Add `Steal::risky_hack_borrow_mut`) - #148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`) - #148508 (Provide more context when mutably borrowing an imutably borrowed value) - #148530 (update the bootstrap readme) - #148608 (Add test for --test-builder success path) - #148636 (bootstrap: respect `build.python` on macOS) - #148639 (test(rustdoc): move tests into jump-to-def) - #148647 (Check unsafety for non-macro attributes in `validate_attr`) - #148667 (a few small clippy fixes) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
that referenced
this pull request
Nov 11, 2025
Rollup of 16 pull requests Successful merges: - #141470 (Add new `function_casts_as_integer` lint) - #143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks) - #146495 (rustdoc: Erase `#![doc(document_private_items)]`) - #147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`) - #147833 (rustdoc-json: move `target` to `json::conversions`) - #147952 (Add a timeout to the `remote-test-client` connection) - #147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers) - #148480 (Add `Steal::risky_hack_borrow_mut`) - #148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`) - #148508 (Provide more context when mutably borrowing an imutably borrowed value) - #148530 (update the bootstrap readme) - #148608 (Add test for --test-builder success path) - #148636 (bootstrap: respect `build.python` on macOS) - #148639 (test(rustdoc): move tests into jump-to-def) - #148647 (Check unsafety for non-macro attributes in `validate_attr`) - #148667 (a few small clippy fixes) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
that referenced
this pull request
Nov 11, 2025
Rollup of 15 pull requests Successful merges: - #141470 (Add new `function_casts_as_integer` lint) - #143619 (`c_variadic`: Add future-incompatibility warning for `...` arguments without a pattern outside of `extern` blocks) - #146495 (rustdoc: Erase `#![doc(document_private_items)]`) - #147771 (Rename `*exact_{div,shr,shl}` to `*{div,shr,shl}_exact`) - #147833 (rustdoc-json: move `target` to `json::conversions`) - #147955 (compiletest: Migrate `TestProps` directive handling to a system of named handlers) - #148480 (Add `Steal::risky_hack_borrow_mut`) - #148506 (Special case detecting `'static` lifetime requirement coming from `-> Box<dyn Trait>`) - #148508 (Provide more context when mutably borrowing an imutably borrowed value) - #148530 (update the bootstrap readme) - #148608 (Add test for --test-builder success path) - #148636 (bootstrap: respect `build.python` on macOS) - #148639 (test(rustdoc): move tests into jump-to-def) - #148647 (Check unsafety for non-macro attributes in `validate_attr`) - #148667 (a few small clippy fixes) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
that referenced
this pull request
Nov 11, 2025
Rollup merge of #146495 - fmease:rustdoc-erase-doc-priv-items-attr, r=GuillaumeGomez rustdoc: Erase `#![doc(document_private_items)]` I just found out about the existence of `#![doc(document_private_items)]`. Apparently it was added by PR #50669 back in 2018 without any tests or docs as a replacement for some specific forms of the removed `#![doc(passes)]` / `#![doc(no_default_passes)]`. However, rustc and rustdoc actually emit the deny-by-default lint `invalid_doc_attributes` for it (but if you allow it, the attribute does function)! To be more precise since PR #82708 (1.52, May 2021) which introduced lint `invalid_doc_attributes`, rust{,do}c has emitted a future-incompat warning for this attribute. And since PR #111505 (1.78, May 2024) that lint is deny by default. I presume nobody knew this attribute existed and thus it was never allowlisted. Given the fact that since 2021 nobody has ever opened a ticket ([via](https://github.com/rust-lang/rust/issues?q=is%3Aissue+document_private_items)) complaining about the lint emission and the fact that GitHub code search doesn't yield any actual uses ([via](https://github.com/search?q=%2F%23%21%5C%5Bdoc%5C%28.*%3Fdocument_private_items%2F+language%3ARust&type=code&ref=advsearch)), I'm led to believe that nobody knows about and uses this attribute. I don't find the existence of this attribute to be justified since in my view the flag `--document-private-items` is strictly superior: In most if not all cases, you don't want to "couple" your crate with this "mode" even if you gate it behind a cfg; instead, you most likely want to set this manually at invocation time, via a build config file like `.cargo/config.toml` or via a command runner like `just` I'd say. Because of this I propose to wipe this attribute from existence. I don't believe it's worth cratering this (i.e., temporarily emitting a hard error for this attribute and running crater) given the fact that it's been undocumented since forever and led to a warning for years.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I just found out about the existence of
#![doc(document_private_items)]. Apparently it was added by PR #50669 back in 2018 without any tests or docs as a replacement for some specific forms of the removed#![doc(passes)]/#![doc(no_default_passes)].However, rustc and rustdoc actually emit the deny-by-default lint
invalid_doc_attributesfor it (but if you allow it, the attribute does function)! To be more precise since PR #82708 (1.52, May 2021) which introduced lintinvalid_doc_attributes, rust{,do}c has emitted a future-incompat warning for this attribute. And since PR #111505 (1.78, May 2024) that lint is deny by default. I presume nobody knew this attribute existed and thus it was never allowlisted.Given the fact that since 2021 nobody has ever opened a ticket (via) complaining about the lint emission and the fact that GitHub code search doesn't yield any actual uses (via), I'm led to believe that nobody knows about and uses this attribute.
I don't find the existence of this attribute to be justified since in my view the flag
--document-private-itemsis strictly superior: In most if not all cases, you don't want to "couple" your crate with this "mode" even if you gate it behind a cfg; instead, you most likely want to set this manually at invocation time, via a build config file like.cargo/config.tomlor via a command runner likejustI'd say.Because of this I propose to wipe this attribute from existence. I don't believe it's worth cratering this (i.e., temporarily emitting a hard error for this attribute and running crater) given the fact that it's been undocumented since forever and led to a warning for years.