Module features 

The features generator: docs/reference/features.md from the manifests.

The source of truth is the [features] table of atune and atune_core, and — this is the point — the comment block above each feature is its description (D29, docs/design/11-documentation-plan.md §7). Those comments already exist, are already reviewed with the code that reads the feature, and are already the first thing a maintainer updates; a second description in a documentation page would be the copy that rots.

That requirement decides the parser. A serde-shaped toml parse produces a value tree, and a comment is not a value: it is discarded before the generator could see it. toml_edit keeps it as the key’s leaf decoration, which is the only way to read what the manifests already say.

Fail-closed, per §17.6: a feature with no comment block above it is an error naming the feature and the manifest, never a page entry with an empty description.

Structs

FeatureMatrix

Generates the feature reference page.

Constants

GENERATOR 🔒

This generator’s name, for fail-closed error messages.

MANIFESTS 🔒

The manifests whose publishable features are documented, facade first: it is the crate a user depends on, and atune_core’s two features are forwarded through it.

MARKER 🔒

The line that ends the published part of a feature’s comment (D37).

Functions

default_closure 🔒

Every feature of this crate that default turns on, transitively.

description 🔒

The comment block above a feature, as prose — the part above D37’s marker.

feature_members 🔒

What one feature enables, as written.

is_marker 🔒

Is this comment line D37’s split marker — a comment of exactly --?

is_rule 🔒

Is this comment line a section rule — three or more dashes and nothing else?

package_name 🔒

The [package] name of a manifest.

render_manifest 🔒

Writes one crate’s section.