Struct Settings 

pub struct Settings { /* private fields */ }

What a bless step generates, and the two things only the adopter can say.

The vendor’s document and the adopter’s Overlays are the input and a directory is the output; everything between them is derived. The two settings are the two facts the documents do not carry: which Rust types the adopter already owns for which vendor formats, and what command regenerates the result.

Implementations

impl Settings

pub fn new(document: impl Into<PathBuf>) -> Self

Generate from the vendor’s document, uncorrected.

A path rather than contents: the generated files name every document they came from so that a reader can find them, and the corrected document is written under the vendor document’s own name.

Corrections are layers over it — Settings::overlay, once per layer.

pub fn overlay(self, overlay: impl Into<PathBuf>) -> Self

Lay one Overlay over the document, after every Overlay already named.

Call it once per layer. The order of the calls is the order the layers are applied, because a later layer corrects the document the earlier ones produced — so two layers that touch the same node are not interchangeable, and the last one wins.

A layer that fails names itself, which is the practical reason to have more than one: a tripwire that stops the bless says which file to open.

pub fn replace( self, format: impl Into<String>, rust_type: impl Into<String>, ) -> Self

Emit rust_type wherever the document declares format.

The adopter owns a Rust type for a vendor format — an amount of money, a customer number, a posting key — and wants it in the generated structs rather than the String the document would otherwise produce.

Keying on the format rather than on a schema name is what keeps the substitution honest: the shape being replaced is read out of the document, so the rule the CLI validates against and the rule the Rust type stands for are the same bytes. rust_type is written into the generated source verbatim, so it is a path the generated crate can name.

A named schema carrying the format becomes a newtype over rust_type whenever the schema’s name is not what rust_type ends in, and that wrapper’s impls are written in terms of it: Display forwards to it, FromStr parses into it and names <rust_type as FromStr>::Err as its own error. Where one is written, the generated types assert both traits against rust_type, so a missing one is a single named error rather than the wrapper’s own impls failing. Everywhere else the type stands alone and needs only the Serialize, Deserialize, Clone, Debug and PartialEq every generated type has. docs/generating.md says which case is which, and why the document’s pattern and the type’s own reading are two rules that a test has to hold together.

pub fn regenerated_by(self, command: impl Into<String>) -> Self

Name the command that regenerates, for the header of every written file.

The default is cargo run -p xtask -- bless.

pub fn write_to( &self, crate_dir: impl AsRef<Path>, ) -> Result<Vec<PathBuf>, GenerateError>

Write the four artefacts under crate_dir, and answer with their paths.

The sink is a directory rather than four values the caller places, because the layout is not the caller’s to choose: the generated crate embeds the corrected document and the reduced model by relative path, and the header of each Rust file states where the others are. One argument buys all four files in the arrangement they have to be in.

Every Rust file is handed to rustfmt after it is written, so what lands in the tree is what cargo fmt --check expects and the bless step stays one command.

Trait Implementations

impl Clone for Settings

fn clone(&self) -> Settings

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Settings

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.