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

rustdoc should skip unresolvable private members #58411

Open
asomers opened this issue Feb 12, 2019 · 4 comments
Open

rustdoc should skip unresolvable private members #58411

asomers opened this issue Feb 12, 2019 · 4 comments
Labels
A-visibility Area: Visibility / privacy T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@asomers
Copy link
Contributor

asomers commented Feb 12, 2019

When using the doc_cfg feature it's useful to run rustdoc on structures that aren't defined for the running platform. However, compilation will fail if those structures have private members that also aren't defined on the running platform. The only solution is to laboriously #[cfg] gate each private member, even if the struct itself is already gated. This issue severely restricts the usefulness of doc_cfg. Here's an example:

#[cfg(any(target_os = "freebsd", rustdoc))]
struct NewType {
    x: libc::something_freebsd_specific
}

rustdoc will fail unless you add another #[cfg(target_os = "freebsd")] attribute directly on x. It should be possible for rustdoc to simply ignore x, since private members aren't normally documented anyway.

For a real-world example, see https://github.com/nix-rust/nix/pull/1019/files#diff-78f451c970a63ad3a93cab0d2670b05dR12 . That PR only builds because of the extra #[cfg()] gate on the libc::ucontext variable, even though the entire module is already restricted to Linux.

doc_cfg tracking issue: #43781

@Centril Centril added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Feb 15, 2019
@Centril
Copy link
Contributor

Centril commented Feb 15, 2019

cc @QuietMisdreavus

@QuietMisdreavus
Copy link
Member

(@Centril please ping the whole rustdoc team for rustdoc issues @rust-lang/rustdoc)

It's possible to extend everybody_loops (or create a new pretty-print pass and run it after everybody_loops when rustdoc is running) to scrub out private struct/variant members. (cc @pnkfelix) One problem with this approach is that we'd have to only run that when --document-private-items was not passed - otherwise we still have to display that information somehow.

@steveklabnik
Copy link
Member

Triage: no change I'm aware of

@jyn514 jyn514 added the A-visibility Area: Visibility / privacy label Aug 25, 2020
@jyn514
Copy link
Member

jyn514 commented Aug 25, 2020

It's possible to extend everybody_loops (or create a new pretty-print pass and run it after everybody_loops when rustdoc is running) to scrub out private struct/variant members. (cc @pnkfelix) One problem with this approach is that we'd have to only run that when --document-private-items was not passed - otherwise we still have to display that information somehow.

everybody_loops is no longer being run, so I don't think we should reuse that.

One possible way is to special case this in rustc_resolve. However there are already a lot of hacks in resolve and I'm not terribly comfortable adding that. Maybe instead rustdoc could remove private fields of structs in a new AST pass? It would have to keep track of how many were reviewed so it could add /* Some private fields hidden */ in the documentation.

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

No branches or pull requests

5 participants