Skip to content

Repr is incorrectly documented for structs with hidden field #128364

Closed

Description

@dtolnay
#[repr(transparent)]
pub struct Public {
    pub field: i32,
}

#[repr(transparent)]
pub struct Private {
    field: i32,
}

#[repr(transparent)]
pub struct Hidden {
    #[doc(hidden)]
    pub field: i32,
}
Screenshot 2024-07-29 at 1 46 31 PM Screenshot 2024-07-29 at 1 46 15 PM Screenshot 2024-07-29 at 1 46 22 PM

Previous discussions of repr documentation:

I believe the intent was that repr(transparent) should only appear in rendered documentation if the field's type is a public API that the documentation reader gets to rely on.

This is the case for repro::Public, and not the case for repro::Private.

I believe repro::Hidden should be treated more like repro::Private for the purpose of documenting repr.

In the standard library, this currently impacts core::pin::Pin. https://doc.rust-lang.org/1.80.0/core/pin/struct.Pin.html

Activity

  1. added
    T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.
    A-attributesArea: Attributes (`#[…]`, `#![…]`)
    C-bugCategory: This is a bug.
    on Jul 29, 2024
  2. added
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Jul 29, 2024
  3. self-assigned this
    on Jul 29, 2024
  4. fmease commented on Jul 29, 2024

    @fmease
    Member

    If I remember correctly my open PR #116882 from Oct '23 addresses this. It's still blocked on design decisions:

    It's not entirely clear to me yet when exactly a repr is considered public or private.
    What I've implemented: A repr is public iff

    1. there exists a variant1 that is not doc(hidden) or there are no variants at all and
    2. for all struct fields (excl. enum variant struct fields) field, field is pub and not doc(hidden)

    (while respecting --document-{private,hidden}-items of course).

    However, it's not clear to me if the quantifiers above are correct, should they be swapped around or sth. else? Moreover, should we take the visibility of enum variant struct fields into account?

    Footnotes

    1. Here, variant refers to a (general) variant of an ADT which includes not only enum variants but also the single synthetic variant of structs and unions ↩

  5. removed
    needs-triageThis issue may need triage. Remove when done. See docs forge.rust-lang.org/release/issue-triaging
    on Jul 29, 2024
  6. added
    A-reprArea: the `#[repr(stuff)]` attribute
    on Nov 2, 2024
  7. added a commit that references this issue on Jun 16, 2025
    5e6424b
  8. added 2 commits that reference this issue on Sep 25, 2025
    16474c6
    a39d513
  9. added a commit that references this issue on Sep 25, 2025
    527cc10
  10. added a commit that references this issue on Sep 26, 2025
    e3873d8
  11. added a commit that references this issue on Dec 21, 2025
    2a0df28
  12. added a commit that references this issue on Dec 29, 2025
    20b6607
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-attributesArea: Attributes (`#[…]`, `#![…]`)A-reprArea: the `#[repr(stuff)]` attributeC-bugCategory: This is a bug.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