- Notifications
You must be signed in to change notification settings - Fork 13.8k
Closed
Labels
A-visibilityArea: Visibility / privacyArea: Visibility / privacyT-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.
Description
code | rustdoc |
---|---|
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
Metadata
Metadata
Assignees
Labels
A-visibilityArea: Visibility / privacyArea: Visibility / privacyT-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.Relevant to the rustdoc team, which will review and decide on the PR/issue.