You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rustdoc displays private internals of associated constants when reexporting types #99630
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.
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?
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).
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.
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.
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.
Activity
fmease commentedon Jul 23, 2022
Huh, that's unexpected. Let me look into that.
@rustbot label T-rustdoc A-rustdoc-ui A-cross-crate-reexports
@rustbot claim
analog-hors commentedon Aug 8, 2022
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?fmease commentedon Aug 8, 2022
This is already fixed on nightly (#98814).Since you are requiring a stable rustc, one workaround is to move the value of
BitBoard::EDGESto a (private) free-standing const itemEDGESand then setBitBoard::EDGEStoEDGES.Sorry for the inconvenience.
The PR mentioned above sadly wasn't backported to beta (yet).
analog-hors commentedon Aug 8, 2022
To my knowledge, the linked PR does not fix the issue, which occurs when reexporting types.
fmease commentedon Aug 8, 2022
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.
MinusKelvin commentedon Aug 8, 2022
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.
Nemo157 commentedon Aug 16, 2022
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.
fmease commentedon Jun 4, 2026
This no longer reproduces and hasn't for quite a while. Not sure which PR fixed it; might need a regression test.
zakrad commentedon Aug 8, 2026
@rustbot claim
Rollup merge of rust-lang#160748 - zakrad:regr-test-99630, r=Guillaum…
Rollup merge of rust-lang#160748 - zakrad:regr-test-99630, r=Guillaum…
Unrolled build for #160748