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