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.

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

Repr is incorrectly documented for structs with hidden field #128364

Open
dtolnay opened this issue Jul 29, 2024 · 1 comment · May be fixed by #116882
Open

Repr is incorrectly documented for structs with hidden field #128364

dtolnay opened this issue Jul 29, 2024 · 1 comment · May be fixed by #116882
Assignees
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@dtolnay
Copy link
Member

dtolnay commented Jul 29, 2024

#[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

@dtolnay dtolnay added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. A-attributes Area: Attributes (`#[…]`, `#![…]`) C-bug Category: This is a bug. labels Jul 29, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jul 29, 2024
@fmease fmease self-assigned this Jul 29, 2024
@fmease
Copy link
Member

fmease commented Jul 29, 2024

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

@fmease fmease removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jul 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) C-bug Category: This is a bug. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants