Expand description
mf2-macros — the tr! proc-macro.
An application never names this crate. mf2-build generates, in the i18n
crate, an exported tr! wrapper that forwards to __tr_impl with the
manifest’s absolute path and hash baked in as literals:
__tr_impl!("<abs path>/manifest.mf2m" 0x<hash>u64 ; $crate ; "id", name = value, …)
__tr_impl!(bytes b"<manifest>" 0x<hash>u64 ; $crate ; "id", …)so that any crate depending on the i18n crate can call tr!, with no
unstable feature and nothing to configure. The manifest is read once
per compiler process, keyed by the path and verified against the baked
hash — a manifest that hashes to anything else is reported as stale, never
used, which is what keeps a long-lived rust-analyzer proc-macro server
honest.
MF2_MACRO_STATS=<file> makes each rustc process write what the macro
cost it — expansions, nanoseconds, manifest reads — which is how the
cache and the macro’s time are measured (stats).
What the macro checks and what it emits is the expand module’s doc; what reaches
the wasm is a MsgId and the argument values, never an id string, an
argument name or a markup name.
Both proc-macros are hidden from the documentation: only the generated
wrapper calls them, and 2.x promises the tr! forms, not these
(docs/versioning.md).
§The user guide
The Rust MF2 book is the user
guide: how the crates fit together, web and native applications, the
command line, and what 2.x promises.
An application calls tr! through the i18n crate that
mf2-build generates, and names mf2.