Skip to content

Rustdoc displays private internals of associated constants when reexporting types #99630

Closed

Description

@analog-hors

types/src/lib.rs:

pub struct HasPrivateFields {
    _private: (),
}

impl HasPrivateFields {
    pub const ASSOC: Self = Self { _private: () };
}

main/src/lib.rs:

pub use types::HasPrivateFields;

This leaks private fields:
Doc page displaying private fields in associated constant initializers

Tested with cargo clean && cargo +nightly doc.

Note that this also applies to verbose initializers.

This issue was first brought up in #97933. The previous issue was closed due to a hotfix implemented in PR #98814. However, the hotfix fails to handle the case in this issue.

Meta

rustc +nightly --version --verbose:

rustc 1.64.0-nightly (848090dcd 2022-07-22)
binary: rustc
commit-hash: 848090dcd18553b790461132ca9d2a020aeea9a2
commit-date: 2022-07-22
host: x86_64-pc-windows-msvc
release: 1.64.0-nightly
LLVM version: 14.0.6

Activity

  1. fmease commented on Jul 23, 2022

    @fmease
    Member

    Huh, that's unexpected. Let me look into that.

    @rustbot label T-rustdoc A-rustdoc-ui A-cross-crate-reexports
    @rustbot claim

  2. added
    A-cross-crate-reexportsArea: Documentation that has been re-exported from a different crate
    A-rustdoc-uiArea: Rustdoc UI (generated HTML)
    T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.
    on Jul 23, 2022
  3. analog-hors commented on Aug 8, 2022

    @analog-hors
    Author

    By the way, this is currently affecting my crate cozy-chess, which defines associated constants using a macro. The macro expands to a highly verbose expression, which rustdoc then documents, leaving the documents unreadable. I don't particularly like that rustdoc makes assumptions about what the readable form of a constant looks like. Could there be a temporary fix in the meantime?
    image

  4. fmease commented on Aug 8, 2022

    @fmease
    Member

    This is already fixed on nightly (#98814).

    Since you are requiring a stable rustc, one workaround is to move the value of BitBoard::EDGES to a (private) free-standing const item EDGES and then set BitBoard::EDGES to EDGES.
    Sorry for the inconvenience.
    The PR mentioned above sadly wasn't backported to beta (yet).

  5. analog-hors commented on Aug 8, 2022

    @analog-hors
    Author

    To my knowledge, the linked PR does not fix the issue, which occurs when reexporting types.

  6. fmease commented on Aug 8, 2022

    @fmease
    Member

    Ah, I see (cozy-chess ⟷ cozy-chess-types).
    Still, the workaround should work, right?

    This issue will be fixed by my open PR #99688. However it is massive and a bit controversial I think, so reviews have stalled. I am still very eager to land it and I just contacted the relevant people so work on the PR can pick up pace again.

  7. MinusKelvin commented on Aug 8, 2022

    @MinusKelvin

    I think it would be good to have a separate hotfix PR to make the behavior in this case match that implemented in #98814, as this is clearly what was intended in the first place.

    I think it may also be worth noting that there doesn't seem to be anywhere for experimental rustdoc features (I think it is clear that displaying non-trivial constant values is experimental) to live prior to being included in rustdoc proper. Even in nightly, rustc has feature gates, but as far as I'm aware rustdoc has no analogous system. This is further exasperated by the fact that docs.rs uses nightly to build documentation, making nightly rustdoc the de facto production Rust documentation generator.

  8. Nemo157 commented on Aug 16, 2022

    @Nemo157
    Contributor

    We do have some features that change rustdocs behaviour, like doc_auto_cfg, that seems like it could be an ok model to allow opt-in for new features we might want to make default in the future?

    EDIT: though it has the downside that it's unlikely to be widely used unless it's something very useful like the cfg-docs. Having changes rollout to new builds on docs.rs quickly probably results in finding and fixing issues much faster than waiting for them to be stabilized. Less people build and thoroughly inspect docs locally.

  9. removed their assignment
    on Jun 4, 2026
  10. fmease commented on Jun 4, 2026

    @fmease
    Member

    This no longer reproduces and hasn't for quite a while. Not sure which PR fixed it; might need a regression test.

  11. added
    E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc
    E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
    E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.
    and removed
    E-needs-mcveCall for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example
    on Jun 4, 2026
  12. zakrad commented on Aug 8, 2026

    @zakrad
    Contributor

    @rustbot claim

  13. added 2 commits that reference this issue on Aug 9, 2026
    124ec08
    1dc2a9e
  14. added a commit that references this issue on Aug 9, 2026
    c0bbab7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-cross-crate-reexportsArea: Documentation that has been re-exported from a different crateA-rustdoc-uiArea: Rustdoc UI (generated HTML)C-bugCategory: This is a bug.E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustcE-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions