Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions crates/cargo-util-schemas/manifest.schema.json
Original file line number Diff line number Diff line change
Expand Up @@ -649,6 +649,13 @@
"items": {
"type": "string"
}
},
"doc": {
"description": "Documentation for the feature.",
"type": [
"string",
"null"
]
}
},
"required": [
Expand Down
3 changes: 3 additions & 0 deletions crates/cargo-util-schemas/src/manifest/mod.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1520,6 +1520,9 @@ pub struct FeatureMetadata {
/// Features that this feature enables.
pub enables: Vec<String>,

/// Documentation for the feature.
pub doc: Option<String>,
Comment thread
AudaciousAxiom marked this conversation as resolved.

/// This is here to provide a way to see the "unused manifest keys" when deserializing
#[serde(skip_serializing)]
#[serde(flatten)]
Expand Down
20 changes: 20 additions & 0 deletions doc/book/src/reference/unstable.md
Original file line number Diff line number Diff line change
Expand Up @@ -2396,6 +2396,26 @@ foo = { enables = [] }
This is equivalent to the array-of-strings syntax.
Support for other keys should be added later.

### feature-documentation

@AudaciousAxiom AudaciousAxiom Sep 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you expand https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#feature-metadata a bit? Perhaps with a subsection linking to feature-documentation RFC and tracking issue.

I've added a subsection. It's not added to the ToC at the beginning of the page as feature-documentation is not actually an unstable feature.

View changes since the review

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we make the subsection sounds more like a sub-feature udner feature-metadata rather than a separate feature being misplaced at a h3 heading?


* Tracking Issue: [#17445](https://github.com/rust-lang/cargo/issues/17445)
* RFC: [#3485](https://github.com/rust-lang/rfcs/blob/master/text/3485-feature-documentation.md)

This allows providing documentation for the feature inside the table introduced by
[`feature-metadata`](#feature-metadata):

```toml
[features.serde]
enables = []
doc = "Enables support for serialization and deserialization via serde."
Comment thread
weihanglo marked this conversation as resolved.
```

The documentation can be consumed and displayed by tools.
It can be a multi-line TOML string, contain multiple paragraphs, and use Markdown markup,
similarly to Rust doc comments.
Tools may only display the first paragraph in some contexts, which should therefore be
relatively short and make sense without the rest of the description.

## lockfile-path

Support for `resolver.lockfile-path` config field has been stabilized in Rust 1.97.0.
Expand Down
62 changes: 62 additions & 0 deletions tests/testsuite/features.rs
Original file line number Diff line number Diff line change
Expand Up @@ -2681,3 +2681,65 @@ c = [
[("Cargo.toml", normalized_manifest)],
);
}

#[cargo_test]
fn feature_documentation_is_unstable() {
let p = project()
.file(
"Cargo.toml",
r#"
[package]
name = "foo"
edition = "2015"

[features]
foo = { enables = [], doc = "Enables foo." }
"#,
)
.file("src/main.rs", "fn main() {}")
.build();

p.cargo("check")
.with_status(101)
.with_stderr_data(str![[r#"
[ERROR] failed to parse manifest at `[ROOT]/foo/Cargo.toml`

Caused by:
feature `feature-metadata` is required

The package requires the Cargo feature called `feature-metadata`, but that feature is not stabilized in this version of Cargo ([..]).
Consider trying a newer version of Cargo (this may require the nightly release).
See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#feature_metadata for more information about the status of this feature.

"#]])
.run();
}

#[cargo_test]
fn feature_has_documentation() {
let p = project()
.file(
"Cargo.toml",
r#"
cargo-features = ["feature-metadata"]

[package]
name = "foo"
edition = "2015"

[features]
foo = { enables = [], doc = "Enables foo." }
Comment thread
weihanglo marked this conversation as resolved.
"#,
)
.file("src/main.rs", "fn main() {}")
.build();

p.cargo("check")
.masquerade_as_nightly_cargo(&["feature-metadata"])
.with_stderr_data(str![[r#"
[CHECKING] foo v0.0.0 ([ROOT]/foo)
[FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s

"#]])
.run();

@AudaciousAxiom AudaciousAxiom Sep 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should there be a check of the new key being parsed?

View changes since the review

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this can similarily be split into two (test, fix) commits, so that we don't need a verification but the test diff showing that it was an unused manifest key.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we had a cargo metadata integration, then we'll have a verification for the consumption side (yeah we should continue the design discussion).

Or we can also add cargo-info integration for feature metadata in a follow-up as part of the verification. @0xPoe any opinion on this? I am not sure whether it should be behind a unstable flag though, given cargo-info is purely for human not programmable.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this can similarily be split into two (test, fix) commits, so that we don't need a verification but the test diff showing that it was an unused manifest key.

I've split the PR: the feature_has_documentation test case is now introduced in the first commit, triggers the "unused key" warning, which then disappears in the second commit as support for the key is added.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or we can also add cargo-info integration for feature metadata in a follow-up as part of the verification. @0xPoe any opinion on this? I am not sure whether it should be behind a unstable flag though, given cargo-info is purely for human not programmable.

Sounds interesting. I believe docs may also be helpful for human use. However, the biggest challenge would be the UI design. In the current cargo-info output, it is difficult to display the documents directly within the existing layout.

}
Loading