Skip to main content

Module request

Module request 

Source
Expand description

§request — the front door

A request is what you hand this compiler, and an expansion is what comes back. This home owns the consumer-declared door and the complete walk from captured meaning to a sealed expansion.

§The door says who is asking

One door declares the prefix your users read at the head of every line, the stable name of the declaration grammar, the stable name of the entry point, the crate rendered paths are rooted at, and the producer namespace and name generated identities stand under.

Say them once, in a const, and pass a reference from then on. Diagnostics read the diagnostic spellings, rendered paths read the crate binding, and the projection-kind identity reads the producer qualification, so each fact reaches only the product surface it owns.

No consumer spelling lives here. A consumer may rename its dependencies, so a binding this compiler chose for you would name a crate you do not have.

Door is declared here. The crate root and diagnostic::Door remain compatibility navigation to that same request-owned type.

§What a request decides for you

A kind declares its seats, and a request through this door plans one member per seat.

That is the whole selection rule, and it is this home’s own declared fact: what a kind’s roster names is what one request produces. The content binding, semantic key, origin node, and digest contract of each member are derived from the captured bytes, the owner-qualified kind, the content’s canonical bytes, and the seat as each identity grammar requires. They are never supplied, because a caller who could supply them could make a plan agree with content or a rendering it was not planned for.

A kind whose output set varies with what was declared does not use this door. The lower-level homes remain reachable underneath, which is where a conditional membership is built and proved explicitly.

§What you decide

The caller hands over captured material, the kind’s own content, and the door. It may then state the captured dependencies the content stands on, the profile the request runs under, the owner facts the projection assumes, the address of each publishing seat, and the answers to the kind’s own questions. The exact defaults and replacement behavior are the caller contract on Request.

The compiler’s universal questions are answered from the plan and proof, so a caller answers only what its own kind asked.

§How it says no

Every step refuses in the vocabulary of the home that owns it, and this home turns each one into a diagnostic without translating it.

The phase, the family, the class, the first established issue, and the related set all ride on the refusal’s own type. This home supplies the door and the placement, and the placement is always the declaration as a whole: a refusal raised at or after planning is about the declaration, not about a token inside it, and a line naming a position would send a reader somewhere the refusal is not.

There is no partial answer anywhere on the road. A request that fails a step is refused whole, and nothing that did not bind is handed out.

Structs§

CrateBinding
The crate a path rendered through one door is rooted at.
Door
The one value that says who is asking.
Producer
Who is asking, for whatever a door’s expansions are stamped into.
Request
One request: the material it stands over, what that material means, who is asking, and the seats the caller states.

Constants§

RUST_DECLARATION_PROFILE
The profile a request runs under where it selects no other.
SELECTION_FACT
This home’s own declared fact: a kind’s roster is the complete output set of one request through this door.

Functions§

bound_content
Bind one kind’s content to the exact captured declaration and door-qualified kind it was presented under.
committed
The identity of the material one request walked in with.
committed_helper
The identity of one helper capture read beside a semantic declaration.