The compile pipelinealpha

Which stage owns which part of the work, and which stage produced my error?

A moxzi compile is a job that moves through a sequence of named phases, each of which owns one transformation and reports its own diagnostics. The job's current phase is a query, not a log line.

The constraint is that the pipeline is a state machine on a job record rather than a stack of function calls. Nothing runs to completion in one go, so "which stage am I in" is observable at every moment — and so is "which stage did that come from".

The phases#

status(id) returns a Status record with phase, plus messages, yields and instructionsUsed. phase moves through this sequence:

A second, older path exists for non-EOP builds — desugar, compile-lower, compile-batch, compile-codegen-done, compile-link — routing through CompileActor / CompileActorNew rather than CompileEnhanced. Everything the four front ends ship uses the EOP path.

Inside compile-enhanced#

phaseDetail carries the stage. The stage list is fixed, and each stage's output is the next stage's input; job.eopStage is the number in the record.

Stages 8–14 are each a pull-driven { step; finish } machine stored on the job: step() processes one declaration synchronously and the message yields by returning, with no calls outstanding. The walk order is identical to the one-shot version, deliberately — order is byte-relevant, because con stamps, fresh ids and $r/0 minting all depend on it.

The pipeline is not "user code only". Stages 0–2 compile the compiler's own internals source on every build, which is why a hello-world still takes 52 messages on-chain.

Which stage produced my error#

On-chain, a trapping message rolls back state, so phaseDetail written inside it is lost — four stage labels were added that way and none ever appeared. Debug output goes to the canister log instead and is retained, which is why each IR pass prints its name before running: the last MEMPROF stage= line in the log names the stage that exceeded the message cap.

Locally, moxzi build --timings and the CLI's periodic step N … phase lines report the same thing without a query.

Where the work actually is#

Measured on the compiler self-compiling, codegen dominates everything else — stage 15 is where a multi-thousand-message build spends most of its messages, and where every memory governor in the system is pointed. The IR passes (8–14) are cheap in instructions but expensive in garbage: each pass rebuilds the whole IR, so the previous IR becomes garbage immediately, and the collector only runs between messages.

Things you cannot do#

Next#

• Resumability — why each of these stages checkpoints internally.
• Architecture — the modules behind each stage, and what happens after done.
• Byte-identical output — why stage order is not free to change.