Skip to content
Merged
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
38 changes: 35 additions & 3 deletions doc/book/src/reference/unstable.md
Original file line number Diff line number Diff line change
Expand Up @@ -2384,17 +2384,49 @@ The `pubtime` index field has been stabilized in Rust 1.94.0.
## feature-metadata

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

This allows to use a table when defining features, with a required `enables` key:
This allows defining features with a metadata table.

```toml
cargo-features = ["feature-metadata"]

[package]
# ...

[features]
# same as `foo = []`
foo = { enables = [] }
```

This is equivalent to the array-of-strings syntax.
Support for other keys should be added later.
The required `enables` field is equivalent to the array-of-strings syntax.

For other metadata fields, see the subsections below.

### feature-documentation
Comment thread
weihanglo marked this conversation as resolved.

* 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 adds a `doc` field to the feature table,
which provides documentation for the feature.

```toml
cargo-features = ["feature-metadata"]

[package]
# ...

[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

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