Module support 

support — inert cargo across a consumption boundary

A declaration expands where it stands, while some of its generated material belongs only in a test or benchmark target. Compiling that material in the declaring crate as well as in the target would erase the boundary the declaration asked for. This home owns the exported carrier that preserves that boundary.

Responsibilities

The parent retains only declaration and schema-pin vocabulary shared across the crossing. Carried material, its promotion, and its axes remain distinct from the checked join that assembles them and from the carrier that renders and delivers the result. That separation prevents rendering machinery from inventing cargo and prevents cargo from bypassing the relationships the join establishes.

The boundary

Authority enters as one captured declaration, terminal deliveries already proved by the compiler, the producer’s published schema expectation, and an optional address chosen by the declaration. The home admits only cargo read from the delivery that proved it and assembles every carried part under one declaration and one delivery form. What leaves is an exported macro definition whose body remains inert until a consumption target invokes it.

The carrier is machinery, not a second declaration language. It owns the vehicle, the coupling of its seats, and the proof that the cargo came from the deliveries it names. The descriptor adapter owns the material placed in those seats, and the harness owns the gate and the destination vocabulary released on a matching schema.

One coupled crossing

The schema gate governs the declaration-shaped material and the opaque target cargo together. A matching publication releases both seats of the selected form, while a mismatch releases neither. This coupling prevents a target from receiving half of a delivery under a schema that did not admit the other half.

The schema expectation is fixed by the producer rather than supplied by each declaration. Its independent currency observation compares both published copies with the identity derived from the harness declaration, because agreement between two copies establishes coherence and not freshness.

Proved cargo only

Opaque cargo is promoted from a closed terminal’s own delivery. The promotion records the terminal, its declaration, its destination, and the digest of the delivered bytes as one informed value. Assembly then verifies the relationships across every carried axis before any shell can be rendered.

The rendered carrier is named from its plan identity so declarations sharing one crate do not choose competing machinery names. An author-facing alias normally forwards its input whole and changes no cargo. Where opaque cargo names items in the declaring crate, the alias reads that target-supplied physical path only to reach the hidden carrier and forwards the same binding into the cargo; it interprets no semantic material.

Composition

The descriptor doors read first-party declarations, close their generated outputs, and hand this home only proved deliveries and declaration-owned material. This home composes the carrier and walks it through the same request, rendering, closure, explanation, and binding road as every other generated unit. The proc host only emits the resulting declaration-site unit beside the item it was given.

At the consumption boundary, the harness gate proves that the supplied harness path reaches the publishing crate and that the producer’s schema expectation matches the published one before either seat reaches type checking. The gate transports opaque cargo without interpreting it.

Evidence ceiling

An assembled carrier establishes producer-side parentage, singular delivery, one declaration, one form, and the published expectation used to render the shell. It does not establish that a target invokes the carrier, that the published schema is current, that opaque cargo is semantically correct, or that the consuming target succeeds. Those claims belong to external carrier-road, schema-currency, compile-refusal, proc, package, and consumption observations.

This home also makes no performance claim. Generated-token growth, compile cost, packaged outside consumption, renamed paths, and target behavior remain adopter-facing evidence planes rather than constants or prose claims here.

Structs

AssemblyError

The complete assembly refusal.

BoundPath

A rendered path rooted at a declared crate facing.

DeclaredCargo

One terminal’s proved declaration-site body, its parentage, and the matcher clauses it consumes.

DeferredCargo

The tokens one opaque seat receives before promotion.

ProvedCargo

One terminal’s proved cargo and parentage.

SchemaId

A generated-support schema identity.

ShellName

The full-width plan-keyed exported name.

SupportAssembly

The verified whole one exported carrier is rendered from.

SupportAxes

The complete three-axis input to assembly.

SupportCarrier

The carrier request kind.

SupportName

The public alias a consumer invokes.

SupportShell

The rendered inert exported shell.

WallName

An owner namespace and spelling.

Enums

AssemblyIssue

One way closed outputs do not compose into one carrier.

AxisCargo

What one axis carries, or why it carries nothing.

CargoAxis

The cargo axes one carrier composes.

CrateFacing

The crate at which a rendered path is rooted.

DeclarationError

A support-declaration refusal.

DeliveryForm

The coupled gate-seat form.

ShellError

A carrier-shell refusal.

Constants

ASSEMBLY_FACT

The fact this owner declares.

ASSEMBLY_ISSUE_LIMIT

Issues one assembly refusal carries before counting the rest.

EXPECTED_CLAUSE

The gate’s clause carrying the producer’s own expectation.

EXPECTED_SCHEMA_ID

The compiler’s pinned generated-support schema expectation.

GATE_MACRO

The gate a carrier’s body invokes.

PATH_SEGMENT_LIMIT

The maximum rendered path depth after its crate root.

Functions

delivered

Walk one carrier request from a verified assembly to the sealed expansion its exported carrier rides out of.

expectation_roster

The producer’s expectation, as the bracketed roster of decimal byte values the gate’s opening arm matches.

exported_shell

The exported carrier: a hidden definition under the mangled name, with one rule matching what the delivery consumes and expanding to the body it guards.

gate_invocation

The gate invocation a carrier’s body IS: the producer’s expectation, the binding, and the form’s coupled pair of seats.

matched_clause

One <name>: $<name>:<fragment>, clause of a carrier’s matcher.

matcher

A carrier’s matcher: the binding every rendered path is rooted at, and exactly the clauses the declared cargo consumes.

public_alias

The author-chosen address: an exported definition under the spelling a declaration chose, whose one rule forwards its whole input to the hidden carrier.

rendered_identifier

The rendered-identifier admission roads. Whether one spelling is a single Rust identifier a rendering is willing to write.

rendered_name

The rendered-identifier admission roads. Whether one spelling can NAME a rendered item: a single identifier the language has not already taken.

rendered_path

One path a caller declared, spelled from the crate it was rooted at.