Skip to content

Conversation

asomers
Copy link
Member

@asomers asomers commented Jan 30, 2019

This commit demonstrates the use of the unstable doc_cfg feature to make
cross-platform documentation. Properly annotated items will be visible
in the documentation regardless of which platform it was built on. But
there are still a few warts:

  • The feature is unstable, so it must be gated by a "nightly-docs"
    feature flag.
  • Rust-2015-style macros must be annotated individually, even if they're
    behind an annotated module.
  • Struct members, even private ones, must be #[cfg()] gated even if
    their struct is already gated.

This commit demonstrates the use of the unstable doc_cfg feature to make
cross-platform documentation.  Properly annotated items will be visible
in the documentation regardless of which platform it was built on.  But
there are still a few warts:

* The feature is unstable, so it must be gated by a "nightly-docs"
  feature flag.
* Rust-2015-style macros must be annotated individually, even if they're
  behind an annotated module.
* Struct members, even private ones, must be #[cfg()] gated even if
  their struct is already gated.
@asomers
Copy link
Member Author

asomers commented Jan 30, 2019

cc @nix-rust/nix-maintainers for review. What do you think? I think this would be tremendously useful to Nix. My only doubt comes from the need to laboriously regate all private struct members. We might be able to fix that in rustdoc.

@Susurrus
Copy link
Contributor

Found the docs for this feature here. Sounds like a great idea. Might make it much more clear for our audience when they see something they expect to work for a platform, but it doesn't, what's going on. I wonder if/when docs.rs will support it.

@asomers
Copy link
Member Author

asomers commented Jan 31, 2019

Actually, docs.rs already supports it, because docs.rs uses the nightly compiler. See for example https://docs.rs/futures-locks/0.3.3/futures_locks/struct.Mutex.html#method.with .

@asomers
Copy link
Member Author

asomers commented Nov 29, 2020

The need for this has largely been eliminated by #1337 .

@asomers asomers closed this Nov 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants