feat(metadata): mirror package features in features_v2

[darkraider01]

What does this PR try to resolve?

Closes #17507.

With cargo-features = ["feature-metadata"], cargo metadata --format-version 1 now includes a features_v2 map alongside the existing features map. Each feature has an enables array and, when specified in the manifest, a doc string. The new field is omitted when feature-metadata is not enabled, preserving stable metadata output.

The map includes array-form and table-form features, empty features, and implicit optional-dependency features. Feature documentation is read from the normalized manifest during package serialization; the resolver and Summary remain unchanged.

This branch also preserves feature metadata when a manifest is normalized for packaging, so the metadata remains available after packaging.

How to test and review this PR?

The focused test is metadata::cargo_metadata_features_v2 in tests/testsuite/metadata.rs. Existing metadata snapshots verify that features_v2 is absent without feature-metadata. The output format is documented in doc/book/src/reference/unstable.md.

Validated locally with:

cargo test --test testsuite metadata::
cargo test --test testsuite features_namespaced::json_exposed -- --exact
cargo test --test testsuite script::cargo::
cargo test --test testsuite alt_registry::
cargo fmt --check

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Muscraft, @epage, @weihanglo
• @Muscraft, @epage, @weihanglo expanded to Muscraft, epage, weihanglo
• Random selection from Muscraft, epage, weihanglo

[darkraider01]

I’ve updated this since the original comment: features_v2 is now emitted only when feature-metadata is enabled, so stable cargo metadata output stays unchanged.
I kept it alongside features to preserve the existing format. When enabled, it mirrors every feature, including empty and implicit optional-dependency features, so tools can use one map without merging in documentation separately.
The doc value comes from the normalized manifest during serialization. Summary and the resolver remain unchanged. The keys match the manifest syntax (enables and doc), and doc is omitted when it isn’t supplied.

[weihanglo]

Hi, @darkraider01! One small policy-related question before merging this.

Just noticed a codex/ branch among your recent Cargo works. Using LLM for things like understanding codebase is completely fine. However, our policy has some requirements that if PR was originally created by LLM, a pre-arranged reviewer and a disclosure are required. Also, communication shouldn't be LLM generated at all.

Could you let me know roughly how you used Codex/LLM here, and whether any of them was originally generated by LLM? Thanks!

View changes since the review

[darkraider01]

hi yes, sorry that was something very silly, i mostly use LLMS to review my work to find any other gaps left, so that just my lazy work when also asked it to push it after reviewing. That's why it was in draft, im sorry for the troubles!

[weihanglo]

No worries. Just be sure to follow the policy also for future contributions.

[weihanglo]

No worries. Just be sure to follow the policy also for future contributions.