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

Consider omitting "some variants omitted" in enum documentation if enum is non_exhaustive #108925

Closed
dtolnay opened this issue Mar 8, 2023 · 3 comments · Fixed by #109007
Closed
Assignees
Labels
A-visibility Area: Visibility / privacy. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@dtolnay
Copy link
Member

dtolnay commented Mar 8, 2023

coderustdoc
pub enum Enum1 {
    A,
    B,
    #[doc(hidden)]
    C,
}
#[non_exhaustive]
pub enum Enum2 {
    A,
    B,
}
#[non_exhaustive]
pub enum Enum3 {
    A,
    B,
    #[doc(hidden)]
    C,
}

Would it be reasonable for Rustdoc to produce exactly the same output for Enum2 and Enum3? I think so. These two types have an identical public API.

Separately, would it be reasonable for Rustdoc to produce exactly the same output for Enum1 and Enum2? Whether that means printing a synthetic #[non_exhaustive] attribute on Enum1 instead of the // some variants omitted comment, or some other approach that unifies all three of these outputs.

Meta

rustc --version --verbose:

rustc 1.70.0-nightly (e3dfeeaa4 2023-03-07)
binary: rustc
commit-hash: e3dfeeaa45f117281b19773d67f3f253de65cee1
commit-date: 2023-03-07
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 15.0.7
@dtolnay dtolnay added T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. A-visibility Area: Visibility / privacy. labels Mar 8, 2023
@Ezrashaw
Copy link
Contributor

Ezrashaw commented Mar 10, 2023

IMHO, #[non_exhaustive] for both is more clear. It better conveys meaning.

I'm happy to work on this but I've never touched rustdoc before so I might need some help.
@rustbot claim

EDIT: is it acceptable to literally .push() a new attribute onto it.attrs?

@jsha
Copy link
Contributor

jsha commented Mar 11, 2023

I think it's important that the docs not disagree with behavior users can observe from the compiler. So we shouldn't document a #[non_exhaustive] attribute when none exists because a user could write an exhaustive match and not get a compile error (even though they might have had to look at the source to do so).

I think it would be reasonable for Enum2 and Enum3 to render as Enum2 is today:

For Enum1, I think there should be a doc lint warning if there is a doc(hidden) variant without the enum being marked #[non_exhaustive].

@Ezrashaw
Copy link
Contributor

@jsha I agree, a doc lint sounds like the best idea because semantically Enum1 is #[non_exhaustive] even if not technically so.

I see that you are the reviewer on the linked PR, I've marked it as a draft for now and will re-implement with your suggestion. I assume that @dtolnay broadly agrees from the OP?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-visibility Area: Visibility / privacy. 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