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

docs: enable feature(doc_cfg) when on nightly #440

Closed
hawkw opened this issue Nov 20, 2019 · 1 comment · Fixed by #537
Closed

docs: enable feature(doc_cfg) when on nightly #440

hawkw opened this issue Nov 20, 2019 · 1 comment · Fixed by #537
Assignees
Labels
good first issue Good for newcomers help wanted Extra attention is needed kind/docs

Comments

@hawkw
Copy link
Member

hawkw commented Nov 20, 2019

Feature Request

Crates

All

Motivation

Several tracing crates have a number of feature flags. Some of these feature flags control the presence of public API types, functions, etc. Currently, we attempt to list in the documentation what feature flag(s) are required to enable what APIs. However, it's easy to overlook this when reading the API docs, and it is relatively error-prone: it's possible to add a new feature-flagged API and forget to document the feature gates.

Proposal

The doc_cfg nightly feature allows RustDoc to be more aware of feature flags. When that feature is enabled, RustDoc will add a special banner indicating what feature flag(s) are required by an item with a conditional compilation attribute.

For example, the tracing-subscriber docs could look like this:
Screen Shot 2019-11-20 at 10 29 49 AM
Screen Shot 2019-11-20 at 10 30 05 AM

Since doc_cfg is an unstable feature, it requires the nightly toolchain. Therefore, we would need some way of enabling it only on nightly. A feature flag could be used, but this would have the disadvantage of breaking the build with --all-features on the stable toolchain, which is not ideal. As an alternative, other crates such as tonic use a RustDoc --cfg flag instead:
https://github.com/hyperium/tonic/blob/354d4fdc35dc51575f4c685fc04354f2058061ff/tonic/src/lib.rs#L77
https://github.com/hyperium/tonic/blob/354d4fdc35dc51575f4c685fc04354f2058061ff/tonic/src/lib.rs#L86

This --cfg flag can be added to the docs.rs metadata in the crate's Cargo.toml to cause docs.rs to enable the flag when building the docs:
https://github.com/hyperium/tonic/blob/354d4fdc35dc51575f4c685fc04354f2058061ff/tonic/Cargo.toml#L81-L83

We would probably want to also enable it on Netlify master/PR docs builds.

Alternatives

We could, alternatively, not do this, and continue with the current system of just explaining this in the feature flags in the RustDoc comments. However, I think this is much less clear to users reading the docs, and is probably slightly more work for contributors as well.

Another option is using a feature flag rather than a --cfg argument to enable the doc_cfg feature, but as I discussed, this would mean that building with --all-features would only work on nightly Rust. I don't think that is a good option.

@hawkw
Copy link
Member Author

hawkw commented Jan 8, 2020

@yaahc any progress on this? it would be great to get it in before the next release cycle

hawkw added a commit that referenced this issue Jan 10, 2020
Starts on #440.

This branch adds `doc_cfg` attributes to `tracing` and `tracing-core`,
when a `docsrs` cfg flag is passed to rustdoc. It also adds 
docs.rs crate metadata to configure docs.rs to set that flag, and adds
it to the Netlify config as well.

Signed-off-by: Eliza Weisman <eliza@buoyant.io>

Co-authored-by: Jane Lusby <jlusby42@gmail.com>
hawkw pushed a commit that referenced this issue Jan 15, 2020
Closes #440 

this should be the last of them

* finish doc_cfg for tracing-tower

* finish doc_cfg for tracing-log

* Add cargo metadata to tower and log
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed kind/docs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants