Skip to main content
Next (unreleased) · docs c218d875 · core f63c1e69 · built 2026-10-26 22:39 UTC

Elaboration

The pass between type checking and evaluation: it resolves method-call dispatch statically wherever possible, so the evaluator can skip a runtime aspect-registry lookup at those call sites. Owning crate: metel-frontend. Defined in elaborator/. See ADR-0037.

Model​

Typing establishes what a receiver can do; elaboration turns that fact into an execution decision. A call whose receiver and selected implementation are known becomes an inherent or aspect dispatch, carrying the aspect identity where relevant. The evaluator consumes that decision rather than repeating semantic selection. Calls that genuinely lack enough type information remain dynamic, which keeps the boundary explicit instead of making the runtime guess. The checkable form of this contract is the dispatch requirement.

Verifiable architecture claims

Owner metel-frontend unless a requirement names another.

Requirement №1​

Elaboration resolves each method call's dispatch from Dynamic to Aspect { aspect_id } when the receiver's type gets the method through that aspect (by SymbolId), else to Inherent, including for a receiver with no nameable type; a method shared by two aspects is ambiguous (T0013).

Implemented by (1)
  • elaborate metel-frontend/src/pipeline/elaboration/mod.rs
Tested by (6)

Known limitations​

knownLIMIT-ELABORATION-001 — ElaboratedModuleGraph's field is fully public, unlike NormalizedModuleGraph's. ElaboratedModuleGraph's field is public, so code outside the frontend can build one without running elaboration, unlike NormalizedModuleGraph. Open record ↗