docs(book): document the table syntax of features - #17446
Draft
AudaciousAxiom wants to merge 2 commits into
Draft
AudaciousAxiom wants to merge 2 commits into
AudaciousAxiom wants to merge 2 commits into
Conversation
AudaciousAxiom
commented
Sep 6, 2026
| ## The `[features]` section | ||
|
|
||
| Features are defined in the `[features]` table in `Cargo.toml`. Each feature | ||
| specifies an array of other features or optional dependencies that it enables. |
Contributor
Author
There was a problem hiding this comment.
Maybe the reference to the array might need to be updated, but the list of features itself is at least still an array.
AudaciousAxiom
force-pushed
the
docs/book-features-table-syntax
branch
from
September 6, 2026 08:33
1983c32 to
6c77ffb
Compare
This was referenced Sep 6, 2026
weihanglo
reviewed
Sep 6, 2026
Member
There was a problem hiding this comment.
A good idea of this documentation hasn't yet come up in my mind. There are things that we want to take into considerations:
- We need to explicitly say that which MSRV supports this, like other manifest fields that has a
MSRV:quote block - We may also want to advocate writing feature documentation in the future, so we actually love to see people migrating to new syntax.
I feel like the two points contradict to each other 😞.
Muscraft
pushed a commit
to Muscraft/cargo
that referenced
this pull request
Sep 14, 2026
…ng#17447) ### What does this PR try to resolve? This implements part of [RFC `feature-documentation`](rust-lang/rfcs#3485), tracked by rust-lang#17445. This only adds support for the new key in the schema. This doesn't add anything to the index as this was decided against. This doesn't not introduce a dedicated unstable feature, as mentioned in rust-lang#17445 (comment), and the new key is simply gated behind the existing `feature-metadata` unstable feature. The exact name of the key is still TBD, but it will be easy to rename either in this PR or later. ## Open questions - How to prepare the documentation for this? Not introducing an unstable feature means there is no dedicated place for that in the book, should it be added to [the existing docs of `feature-metadata` there](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#feature-metadata), or stacked as a separate PR on top of rust-lang#17446? ## Future work At least the following is still to be done for this RFC (I may not have time to tackle this): - Exposing the new key through `cargo metadata`. - Exposing the documentation to humans through `cargo add` (and through other tools/services, like [docs.rs](https://docs.rs)). ### How to test and review this PR? The tests should be enough to review this.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR try to resolve?
This is a follow-up to #15056 (comment), and part of
feature-metadata#14157, that prepares the documentation for when the unstable feature (or the first of its subfeatures) is eventually stabilized (I understand this is not for now, and that this PR will very likely conflict). Sometimes documentation stemming from unstable features can be added to the documentation of the unstable feature itself, as suggested in #15056 (comment), but I think this doesn't really work in this case as this is not purely additive.This should address all occurrences within the book; this can be checked with
rg -A1 '\[features\]' doc/book/.Open questions
feature-documentation), and only documents the old array syntax as a shortcut.How to test and review this PR?
This is a doc-only PR. It's kept as draft until the first subfeature of
feature-metadatais stabilized. Doing this early helped me find a corner-case infeature-visibility. Feel free to edit this PR as needed.