Reading diagnosticsalpha

What do moxzi's error codes mean and what should I put in a bug report?

moxzi renders diagnostics the way moc does — file:line.col-line.col: kind [Mxxxx], message — using moc's own code numbering, so editor tooling, search results and habits carry over unchanged. A failing build prints its errors; a successful build prints its warnings and then the provenance line. Warning coverage is narrower than moc's — the codes the compiler emits are M0089 (redundant ignore), M0145/M0146 (pattern coverage), M0194/M0198 (unused identifier and field binding), M0254 (a stable field the migration chain does not produce), M0265 (mixin capability) and M0266 (a float literal with more precision than Float holds — a check that found real miscompiles when it was built, so take it seriously). moc's other warning codes are absent: a warning-clean moxzi build is not evidence of a warning-clean moc build.

Anatomy of a diagnostic#

/src/e.mo:1.33-1.37: type error [M0050], literal of type Text does not have expected type Nat

Because the location is a VFS path, moxzi deps is the tool that maps it back to a file on disk.

Codes you will actually meet#

Every one of these was produced by moxzi build on a three-line program:

M0050 and M0096 are the pair worth understanding: moc reserves M0050 for the literal case and uses M0096 for every other check-mode subtype failure, and moxzi follows that split deliberately.

The code space#

mops/mo-langutils/src/ErrorCodes.mo is the canonical list — a port of moc's error_codes.ml. It carries 206 error codes and 42 warning codes, each flagged with whether moc ships a long-form explanation for it.

M9000 is the one code that is not moc's and is always worth reporting. It means the compiler reached a form it has no case for (infer_exp: unimplemented expression form, and similar) rather than that your program is wrong.

Four warning codes ship disabled by default — M0223, M0235, M0236 and M0237, the "redundant type instantiation" and contextual-dot suggestions — matching moc's own defaults.

The parser's depth cap#

The parser refuses to descend past 128 levels and says so before it unwinds:

/src/deep2.mo:1.183-1.184: parse error [M0000], expression nested too deeply (limit 128)
/src/deep2.mo:1.183-1.184: parse error [M0000], expected ) (parens), got (
…

The first line is the real diagnostic; the rest are the parser resynchronising. Hand-written code does not approach this. Machine-generated code should chunk its expressions.

Failures that are not diagnostics#

Two shapes of output mean something other than "your program is wrong":

Here is a real one, on a program moc rejects cleanly:

printf 'persistent actor { public func f() : Nat { 1 } };\n' > oneway.mo
moxzi build oneway.mo -o oneway.wasm

Error: canister trapped: await: oneway body not a block

moc --check oneway.mo

oneway.mo:1.38-1.41: type error [M0035], shared function must have syntactic return type '()' or 'async <typ>'

moc reports M0035 with a location; moxzi crashes in lowering. That gap — a missing front-end check letting a bad program through to a later stage — is exactly what a bug report should capture.

What a good bug report contains#

The template:

moxzi --version                      # moxzi 0.1.0-alpha.3 (7eb76f61c9)
moxzi info                           # compiler + linker paths and sha256
moxzi build bug.mo -o bug.wasm       # the failing command, verbatim output
moc --version && moc --check bug.mo  # the reference compiler's verdict

moc is the oracle for this project. A report that pairs both outputs on one small file is actionable; one that describes the failure in prose usually is not. If the two disagree on which code to emit for the same rejection, that is still a bug — the codes are meant to match.

Things you cannot do#

Next#

• Coming from moc — the rest of the surface, and where the two deliberately differ.
• Compiling and linking — which step a failure came from.
• Projects and packages — turning a /src/… or /pkg/… path back into a file.