#moonbit_static_analysis

1. Program-code revision: analyze programs in the fast-evolving MoonBit language (undefined names, unused bindings, type mismatches, dead branches, unreachable code);
2. Static state revision: a generic machine-table audit for multi-layer state machines (src/statecheck) — the audited subject calls this module, feeding its machine tables in as plain data. The reference consumer is riantr/pyroduct (a subject / group / society / evolution state-machine family); its audit package drives this module black-box with its real tables.

#Contents

• Install / Quick start
• The three inspections (pipeline core)
• Use 1: program-code revision (the fast-evolving MoonBit language)
• Use 2: static state revision (machine tables → three inspections)
• Rendering a scan as a diagram (public API)
• Package structure
• Verification
• File kinds (the other MoonBit toolchain suffixes)
• Formal verification (moon prove)
• Publishing
• Analyze another project (without pulling this one in)
• DeepSeek Harness plugin
• Changelog

#Install / Quick start

moon add riantr/moonbit_static_analysis@0.4.31

// Use 1: revise a MoonBit (current-subset) program
let result : @pipeline.PipelineResult = @pipeline.run(source, "main.mbt")
println(@pipeline.render_result(result))

// Use 2: audit a state machine (machine tables come in as plain data)
let spec : @statecheck.MachineSpec = { name: "主体", states: [...], ... }
println(@statecheck.render(spec))

#The three inspections (pipeline core)

#Use 1: program-code revision (the fast-evolving MoonBit language)

moon run src/cli          # demo: 6 samples × 3 inspections

=== undefined.mbt ===
2:10 - error: undefined variable 'missing' (UndefinedName) [structural+type+behavior]
  in main() at undefined.mbt:4
  in g at undefined.mbt:1
Summary: 1 finding(s) (before merge: structural 1, type 2, behavior 1)

#Use 2: static state revision (machine tables → three inspections)

let spec : @statecheck.MachineSpec = { name: "主体", states: [...], ... }
let findings : Array[@report.Report] = @statecheck.audit(spec)
let text : String = @statecheck.render(spec)   // merged text report

规格 | 计数
---|---
状态 | 034
迁移 | 053
触发→槽 | 049 → 8
无路组合（带理由） | 228
修习历程 | 031 站

已知设计（4 条，出处层：设计使然——0.2.0 审计已验证）：
- state '无忆' is never entered: it appears only as a transition source
- state '无筹' is never entered: it appears only as a transition source
- state '无忆' is unreachable from the initial position '立位'
- state '无筹' is unreachable from the initial position '立位'

未预期发现：**0 条**

The pyroduct-shaped sample machine printed at the end of moon run src/cli is this module's own 8-state toy (statecheck.pyroduct_flavored()), not pyroduct's real tables. It carries coordinates like 182:12; those are stable pseudo-spans hashed from the state name by state_span() (the same name always yields the same coordinate), not positions in any source file — don't go looking for that line in pyroduct.

#Rendering a scan as a diagram (public API)

let root = /* the resolved source root */
let prov = @sa.provenance_for("my/module@1.2.3", root)
let text = @sa.mermaid_states(verdicts, @sa.aggregate(verdicts), prov, 8, 25)
println(scan_artifact_name(prov, root))

• a transition label is everything after the first :, so it may not contain one — locations and messages therefore live in the quoted state label, never on the arrow
• MoonBit has no operator continuation, so a source line beginning with + is a parse error; the document is emitted one write_string at a time for that reason alone

#Naming the artifact: what was read, by what, and when

moonbit_static_analysis_0.4.7_0.1.20260920_20261009T155222Z.mmd
moonbitlang-core_0.1.20260920+7d59c7ec9_0.1.20260920_20261009T051925Z.mmd
tree_unknown_0.1.20260920_20261009T051511Z.mmd     # version not determined

moon 0.1.20260920 (914d7da 2026-09-20)

Corrected in this round. The previous version of this section claimed the CLI could not stamp a time at all, because "the only clock is behind an internal package". That was wrong: moonbitlang/async re-exports it publicly as pub using @event_loop {now}, and provenance_for had been calling @async.now() since 0.4.5. The CLI was stamping unknown only because it had been given a hand-rolled empty stamp instead of calling the function that already worked.

• It does not omit what it could not determine. A missing version, toolchain or clock is written as the literal token unknown. Dropping the segment would produce a name that looks complete and is not — and with four fields it is worse than that: the gap would SHIFT, so a reader parsing core_0.1.2_20261009 would take the stamp for the toolchain version.
• It does not produce a dotfile. A name starting with . is invisible to ls on Linux and macOS, and an artifact nobody can list is not one anybody will find again.
• It does not trust the filename as the record. The same three facts are repeated as %% header comments inside the document, because a file gets renamed and once it does its name is no longer evidence of anything.

#Writing one from the CLI: --mmd / --mmd-auto

moonx riantr/moonbit_static_analysis@latest <target> --mmd out/scan.mmd
moonx riantr/moonbit_static_analysis@latest <target> --mmd-auto

• Opt-in, never the default. The drawing is lossy by construction: mermaid_states ranks files by actionable count and stops at its own cap, saying so in a %% THIS DRAWING IS A SUBSET comment. A tool that made the picture the only output would hide that, and would silently break every script grepping SUMMARY.
• --mmd requires its path; --mmd-auto is a separate flag. An optional value is ambiguous here: in <target> --mmd <path> the bare word after --mmd could equally be a second, unexpected target, and there is no way to tell the two apart. Rather than guess and fail with "unexpected extra argument", the value is mandatory.
• The artifact never lands inside the analysed tree. This module's stated invariant is that it only ever reads the target's files; dropping a file into someone's source repository would break that promise and dirty a tree the user may not own.

MMD  _mbcore_0.1.20260920+7d59c7ec9_0.1.20260920_20261009T132547Z.mmd

#Package structure

src/core      Span/Severity/Lens/Family(merge_group contract)/Frame + Family::advice
src/report    Report struct and rendering (union lens tags, vst frames)
src/sa        scan entry + aggregate() + mermaid_states() (public, library)
src/lexer     MoonBit lexer frontend
src/parser    MoonBit syntax → ast
src/ast       MoonBit abstract syntax
src/walk      structural inspection: binding tables + structural findings
src/types     type inspection: Ty/Ty?/Sig inference
src/interp    behavior inspection: AbsVal lattice + dispatch + virtual stacks
src/pipeline  assembly: run the three inspections + merge_group merge
src/moonfiles the other file kinds: .mbt.md per-block three-inspection / .mbti
              interface audit / .mbtp proof lint
src/statecheck use 2: generic machine-table audit (plain-data MachineSpec bridge)
src/samples   demo samples (embedded MoonBit source)
src/cli       executable entry (program demo + file-kind demo + sample machine audit)

#Verification

moon check --target all --deny-warn   # 0 errors, 0 warnings (js / native / wasm / wasm-gc)
moon test --deny-warn                # 1136/1136 on wasm; 1056/1056 on js and wasm-gc
moon run src/cli                     # program demo + file-kind demo + pyroduct-shaped sample machine audit

CI runs --target js only. The "four targets" line above is a local result; CI does not cover native or wasm.

#The one release entry point

powershell -NoProfile -ExecutionPolicy Bypass -File _verify\release.ps1

• -SkipMutations runs everything except the 78 mutation gates — the corpus pins and the own-source self-scan, about eight minutes. Use it when the question is "did the corpus move?", not "is a gate red?".
• -SelfTest exercises the harness's own stage function against a failing body, a throwing body and a passing body. A guard that has never been shown to go red is not a guard, and this is where that is shown.

#File kinds (the other MoonBit toolchain suffixes)

#Formal verification (moon prove)

moon prove src/core --why3-config .why3.conf   # emits 19 VCs for cvc5/alt-ergo

• 21/21 goals VALID (unsat): the 19 lemmas plus the span_at/zero_span automatic safety VCs.
• Known toolchain limitations (all upstream, not this project's code):
  1. A #proof_pure function whose body is a struct literal (pos/span_at/zero_span) lowers to an opaque logic symbol — the body is dropped, so the span-shape law is unprovable in logic today (pinned operationally by tests; see the note in core_proof.mbtp).
  2. The bundled why3server (Windows build) loses the prover's stdout — why3 reports "High failure" with output .; the bare why3 ... prove CLI reproduces it. Per-goal bypass: why3 -o <dir> -P cvc5 <mlw> exports the SMT files, then run cvc5 on each.

#Publishing

• mooncakes.io: published by CI, not from this machine. Pushing the v* tag to GitHub triggers .github/workflows/publish.yml, which resolves the registry index (moon update), checks that moon.mod's version equals the tag and that the repository holds exactly one moon.mod, runs the gate (moon fmt --check, moon check --deny-warn, moon test --target js --deny-warn, moon build --target wasm), runs moon publish, and creates the GitHub Release. The credential is the MOONCAKES_RIANTR_TOKEN secret, whose VALUE is the whole contents of ~/.moon/credentials.json — not a bare token. (After publishing, riantr/moonbit_static_analysis@0.4.31 can be imported by any MoonBit module; src/cli ships a SKILL.md and is listed on skills.mooncakes.io.)
• Gitee / GitHub: git push to both; tags stay in lockstep with the moon.mod version. Gitee is the daily remote and GitHub is the release remote. A tag pushed to Gitee alone publishes nothing — the publish trigger is on GitHub.

#How a release is cut

1. Dependencies go up first. Check mooncakes.io for the latest versions, moon update, then run the whole gate again under the new dependency. A green run on the old pin does not count: the README would then describe a dependency set that is not the one the code was tested against.
2. _verify/release.ps1 is green — all 77 mutation gates, the corpus pins, the own-source self-scan and the published-package self-scan.
3. moon.mod's version is bumped, and every version reference in README.md, README.zh.md and SKILL.md is synced to it.
4. Commit, then push: master to Gitee, the tag to Gitee, then master and the tag to GitHub. The GitHub tag push is what publishes.

#Analyze another project (without pulling this one in)

moonx riantr/moonbit_static_analysis@latest riantr/moonbit_doubleML@latest

#The output says what was UNDERSTOOD, not how much was counted

SCANNED	107 files under ...\ML\CI
CLEAN	.mbti	...\CI/pof/pkg.generated.mbti
PARTIAL	.mbt	defects=2	notices=1	read up to line 36, 57 after it not shown	...\CI/pof/aggregator.mbt
12:3 - error: ... (UndefinedName) [behavior]
PARSED	32/107 files understood (29.9%); 75 more read only up to their first parse error
SUMMARY	files=107	parsed=32	actionable=57	notices=211	unreliable=15759	withheld=6769	total=16027	(actionable+notices+unreliable = total; withheld ⊆ unreliable)

• PARSED is the headline. The frontend covers a SUBSET of MoonBit, so what it cannot read measures the tool's blind spot, not your code.
• A partly-understood file is still worth reading. The parser records the first line it genuinely failed on; findings before it are reported (PARTIAL), and everything after is counted in unreliable and never shown — it comes from a tree that is already wrong, so presenting it as results would reintroduce the exact failure this tool started with.
• Skipped declarations do not move that boundary. "This test block is not analysed" leaves the code after it readable, so such a file is FOUND.
• actionable excludes notices. A declaration form we chose not to analyse is not a defect in your code — otherwise the self-scan once reported "92 problems" where the true count was zero.
• Unparsed files are grouped BY REASON rather than listed one per line.
• actionable + notices + unreliable = total, asserted in the line.

This view is not yet sound, and the flag is opt-in for that reason. The per-function view was measured across the pinned corpora and reported 116 actionable findings, where the module view reports 0. Those 116 are not 116 defects in the analysed code — every one of them sits in a file that moon check accepts, in released, published packages. They were an inventory of what is still wrong with the behavioral lens, and 0.4.31 emptied it.

family	n	what the lens claimed
A	61	a destructured name is bound to the whole tuple, not to an element
B	25	a continue/break that carries a value is unreachable code
C	8	a statement after a loop whose body always terminates is dead
D	10	an extern/FFI call, an omittable parameter read as a positional slot, a name declared twice, and a function with no body — four defects wearing one name
E	5	a trait's method is not a value, so a qualified call is an undefined function
F	4	an integer / is typed as float
G	2	a name bound by an is-pattern as-binding is not bound
H	1	a comprehension does not bind its pattern

What is left is two, and both are the documented limit rather than a defect: a cross-package #doc(hidden) function cannot be indexed from the dependency's source — only from its .mbti — so @locale.LocalePreferences::resolve is still reported as an undefined function in proton 0.3.4 (facade_locale.mbt:70, core/app_command_host.mbt:114). Answering them would mean growing the analyzer into a source indexer, which is a different project. Use the view to see the lens, not to gate a build.

(This note said 58 and "what remains is one class" until 0.4.30 fixed the sibling-file class, and 7 and "four smaller classes" after that. The number kept falling because the note was describing an inventory, and an inventory is not one class of defect — it is eight of them, and measuring them one at a time is what emptied it.)

Where this stands against moon check. On .mbt this tool does NOT compete with the toolchain's compiler: moon check has a real parser and ~90 built-in warnings at 100% coverage — measured 2.3 s for 128 diagnostics, each with file:line:col, the source line and a fix. This tool's .mbt frontend reads a subset, and on moonbitlang/core it parses 173 of 882 .mbt files (19.6%); .mbti and .mbt.md are 100%. The single largest reason used to be that method calls could not be represented in the AST at all — ECall takes a String, so m.set(k, v) had nowhere to go and the parse stopped there. That is fixed (a dedicated EMethodCall node, wired into all three lenses); the blocker went from 34 files to 0. That is the honest headline number, and it is why PARSED is printed first. What this tool can do that the compiler cannot is the three file kinds it does not audit at all — .mbti, .mbt.md, .mbtp — plus cross-package semantics.

An earlier version of this tool reported 529 "unused locals" on that ML/CI source where the compiler reports 8. Those were not a different opinion: they were struct bodies it had never parsed, and it reported the unread fields as unread bindings. It no longer can — a function the frontend truncated is now excluded from the unused-local / unused-param / param-changed audit outright, because "never read" is a claim about a whole function and a half-read function cannot support one. That fix alone took moonbitlang/core from 270 actionable findings to 147, and this repository from 11 to 0.

Reading further, the same principle turned out to apply to the module frame too, and to a class of names the resolver had never been taught: a file the frontend did not finish has a provably incomplete module frame, so "nothing visible binds this name" is not evidence of anything there; and a Type::member path — @debug.Repr::opaque_(v) — is a member reference, not a binding, exactly as a field name and a method name already were. With extern "c" fn modelled as a declaration (it was skipped, which lost the name, so every call site of an extern function read as unbound) and the numeric-literal / enum-constructor gaps closed, moonbitlang/core goes from 270 to 49 actionable with undefined name down from 64 to 17 (published as 0 at the time; that release's own scan contradicts it, since corrected to the measured value), and this repository stays at 0. 0.4.7 then wires the .mbti audit's unknown-type check to the module-wide interface table, clearing the remaining 13 false reports: 36.

moonbitlang/core	files	parsed	actionable	undefined names
0.4.5	1029	305	270	64
0.4.6	1029	320	49	17
0.4.7	1029	320	36	17

#DeepSeek Harness plugin

#Changelog

#What 0.4.7 changes

#0.4.11 — the first external scan: 4 fixes, all measured on real code

moonx riantr/moonbit_static_analysis@latest riantr/pyroduct@latest

#0.4.12 — package-private cross-file resolution: the largest class left is gone

• The 11 names behind those 26 findings (sieve, ridge_fit, ridge_predict, ols_core, normal_cdf, fmt, claim_code, claim_of, phase_code, contains_state, has_state) are all package-private top-level fns in a sibling file of the same directory — 26/26, no exceptions.
• The toolchain confirms the language allows it: in a two-file package where one file calls the other's private fn, moon check and moon test both pass, including across _test.mbt (has_state is exactly that case). So all 26 were false positives about this analyzer.

1. Depth 0 only. A binding inside a function, a test, an extend or an impl block sits at least one brace deep and is never collected. Otherwise a local let could make itself visible package-wide.
2. The name must be the token IMMEDIATELY after the keyword. A destructuring let (a, b) = ... has ( there, so nothing is collected.
3. fn Foo::new is collected whole, not as Foo — Foo may not exist.

#0.4.31 — the 116 findings were an inventory of the lens, and the inventory is empty

#The module view did not move — except on one corpus, and there it moved DOWN

    actionable  48 -> 37
    notices     9988 -> 9988   UNCHANGED
    unreliable  2956 -> 2956   UNCHANGED
    withheld    552 -> 552     UNCHANGED
    parsed      935 -> 935     UNCHANGED
    files       1029 -> 1029   UNCHANGED

#Five mutation gates that this increment's own source changes broke

• 0.4.25's M7 SURVIVED, and the survivor was right. 0495 replaced a falls flag with a list of flows and a join, and the missing-else arm went from assigning the fall-through to contributing one — so it became redundant whenever some branch falls through, which is exactly where 0.4.25's fixture sat. The line still governs the case no fixture covered: a chain with no else where every branch terminates. Measured on the pre-0495 tree, that mutation killed exactly one test; on this tree it killed none. So the fix was a fixture, not a re-anchor — and M7 is killed again.
• 0472's M5 is not expressible any more. The carried values of a continue are the terminator's own payload now, Array[Expr], and an assignment is a Stmt kind — so the mutation cannot be written at all, and the compiler says so. The claim it pinned is now enforced by the type, which is stronger than a line of code; it is retired with that reason, and a new mutation pins the other half of the claim ("the values are read") at the site where it now lives.
• 0493's M3's named test stopped being the right one. A fix elsewhere — an omittable parameter is not a positional slot — made the row it named stop discriminating between the two mechanisms. The row that still discriminates (a label the callee does not have) now names it, and the reason is written down rather than assumed.

#A flag for the enumeration

#The counts, after

    per-function actionable findings   116 -> 2   (the 2 are the documented #doc(hidden) limit)
    module-view corpus pins            UNCHANGED on six corpora; moonbit_core 48 -> 37
    moon test --deny-warn              1136/1136 on wasm; 1056/1056 on js and wasm-gc
    moon check --deny-warn             exit 0
    self-scan (own source)             167/167 parsed, actionable=0
    mutation gates                     78 gates green; one mutation retired with its reason

#0.4.30 — the last 89 findings went to zero, and the behavioral lens turned out to be WRONG

#The frontend read nineteen more grammar forms

#--per-function: the behavioral lens enters at each FUNCTION

#The toolchain renamed the two unsuffixed integer types, and the tables had not followed

#Two corrections, in place

#The dependency moves

#0.4.29 — expr as &Trait is an operator, and the parser had no production for it

69:38 - error: undefined name 'as' (UndefinedName) [structural+type]

#Settled against the compiler, not assumed

#The fix, and what the node deliberately does NOT carry

#The three lenses, and the false positive the fix could have introduced

#Measured

#There is a second route by which the 0 is earned, and it is function-granular

1. Expression-level exclusions that land inside a function body — match (155), if expression (45), anonymous fn (10), short lambda (2), try (1) — 213 in total — switch off the unused check for the whole function. Declaration-level exclusions sit outside every function's extent and do not trigger this: test (429), struct (36), derive (31), enum (14), const (6) — 516 in total. The source says so at walk.mbt:349-351, and backlog.ps1 prints the two classes separately rather than leaving the split to be asserted.
2. Therefore part of actionable = 0 is green because it is not looking — the same shape as the test-body exclusion above, on an axis nobody had written down.

#What the behavior lens actually contributes on real code

#The survivor, and the gate bug it exposed

1. MethodError inside the operand — there is none. 1.nomethod() reports nothing, and the one finding my probe counted was a warning (UnusedParam) that a grep for error: had filtered out.
2. The same idea in a function that is never called. Interp::run_top skips SFunc outright (interp.mbt:389).
3. The same idea in fn main — which is also an SFunc, and is skipped the same way.

#0.4.28 — derive has no body, and a ParseError notice was saying otherwise

derive(Debug, Eq)
struct Box { n : Int }

#The mistake I made, same family as 0.4.27's

#What this release does NOT do

#0.4.27 — a parenthesised function type in return position is no longer read as a tuple

-> (Int) -> String     the `->` is AFTER the matching `)`
-> (() -> Int)         the `->` is INSIDE the parens

#Corpus effect, measured as a two-build A/B on one tree

#My measurement script reported a false zero twice

\bfn\s+[A-Za-z_]\w*\s*\([^()]*\)\s*->\s*\(

pub fn[T] ServiceTask::start(
  self : ServiceTask[T],
  complete : (ServiceTaskResult[T]) -> Unit,
) -> (() -> Unit)? {          ← `-> (`, and an arrow inside

#A settle has to prove it is measuring before anything it says counts

#Mutation gate: four killed, one proved equivalent

• the tuple arm returns "" (parser.mbt:1272)
• the function-type arm returns "(Int)" (fn_type_annotation:1016 — no -> follows, so out stays the parenthesised group)
• ann_to_ty("") == TUnknown (types.mbt:140)
• ann_to_ty("(Int)") is also TUnknown — no arm of ann_to_ty strips the parentheses

#0.4.26 — a tail expression is the return value, and a fix found by reading code instead of by a corpus delta

#The defect: the tail expression's value was thrown away

Interp::exec_stmt   SExpr(e) => { let _ = self.eval(e, env) }
Interp::analyze_fn  let ret = join_vals(self.ret_vals)
join_vals           if vals.length() == 0 { return AType("None") }

fn f() -> Int {
  1
}
fn g() -> Int {
  f() + 1        // reported: no method matching +(None, int)
}

#The fix: a new STail node and a fn_body flag

#The settle: my first version was empty, and empty in two separate ways

1. moon check only type-checks a body REACHED from fn main. With no main, nothing was type-checked at all.
2. The script deleted src/moon.pkg itself (Get-ChildItem src -File | Remove-Item), so from the first case on there was no package to check and moon check printed nothing. Add PowerShell turning a native command writing to stderr into a NativeCommandError, and the merged string came back empty — two independent failures stacked, producing a clean bill of health for a program the compiler rejects.

• while s == "a" { "b" } is 4139 — a loop body's trailing expression is discarded, and only Unit may be discarded silently. My first loop fixture was written exactly that way. A fixture the compiler rejects is not a fixture.
• A tail expression requires a declared return type (4074). Which is precisely why the latent surface is 305: the population this defect can touch is the population the compiler already forces you to annotate.

#A regression I caused, caught only by the six-corpus byte diff

#Mutation gate: 7 mutations, green on the first run

#0.4.25 — the behaviour lens leaked flow between if branches, and a check that could not fire

#The defect: no join between branches

fn f(g : Int?) -> Int {
  guard g is Some(v) else {
    return 0
  }
  return v
}

#The fix: per-branch reset plus a fall-through join

• An enum does not implement Eq by default. self.flow == FNormal reports Type Flow does not implement trait Eq, so priv enum Flow gained derive(Eq).
• for j in (idx + 1)..elseifs.length() parses as (idx+1)..elseifs and then .length() (reported as type Int has no method arr), so walking the remaining else-ifs has to be a while.

#Mutation gate: eight mutations, three rounds to green

#0.4.24 — raise as an expression: the clause's third position

guard config.package_config() is Some(package_config) else {
  raise MissingPackageMetadata
}

#A new SRaise node, deliberately not SReturn

• Infer::scan_returns has SReturn(Some(e)) => acc = ty_join(acc, self.ty_of(e, TUnknown)), which would join the error CONSTRUCTOR's type into the function's return type;
• Interp's SReturn evaluates the operand and pushes it into ret_vals, inventing a return value raise never produces;
• only the divergence is shared, and that is exactly what SRaise keeps.

#The result: strictly fewer, never more

#Measuring the noise first

fn f(g : Int?) -> Int {
  guard g is Some(v) else { return 0 }
  return v            // reported unreachable — a false positive
}

#Mutation gate: 7 mutations, 4 killed / 3 survived on the first version, 7 / 0 at the end

• M2: first tried separating them by the behaviour lens not evaluating the payload; that failed too, because an orphaned payload follows a terminating SRaise(None), so the behaviour lens does not execute it either — it gets reported as unreachable instead. What finally separated them was the anchor line: with the payload attached the dead statement is return 1 on line 6; orphaned, the dead statement is the payload itself, still on line 5. Same count, same family, same lens — a different line, and the line is the claim.
• M4: a second reason. Every payload before that was a call to an unknown name (E), and a call to an unknown function has no signature to check its arguments against, so ty_of returns early and the payload was never really looked at. Replaced with an expression the type lens checks on its own: raise 1 + "a" (settled valid; int + str is an OperatorMismatch) — a binary operator cannot be skipped for want of a signature.
• M7: the file had no bare raise fixture at all. The function named bare writes raise E, which has a payload. Adding the genuinely payload-less form turned it red.

#0.4.23 — the raise effect annotation, and a false positive it uncovered

#One clause, two positions

#A false positive the fix uncovered: guard!

// moonbitlang/async 0.22.4 src/internal/fd_util/pipe.mbt:31
guard! fds is [r, w]
// reported: operand of '!' must be bool, got '[int]'

#The cost: actionable rose, and every new one is UndefinedName

// proton facade_error.mbt:6
OperationFailed(action~, status=..., detail=...)
// reported: no visible binding for 'OperationFailed'

#Mutation gate: 9 mutations, 9 killed, 0 survived (_verify/mutate_0423.ps1)

• M7 / M8 are the same guard in opposite directions. Admit everything and a bare raise swallows the body's { or the closing ) — a silent misparse — turning 4 tests red. Admit nothing and every named effect stops being consumed, turning 6 red. Testing one direction alone lets "too strict" pass for "correct".
• What M5 killed was not skip_indexed(), it was the raise keyword itself. The first version of M5 removed skip_indexed() and came back 371/371 green — an equivalent mutation: type_annotation already calls indexed_suffix() on the name it reads, so raise E[Int] is consumed whole without that line. The dead call was deleted, with the reason recorded at the call site: keeping it would make the reader look responsible for a case it is not, and the next person to delete it would have no evidence anything checked it.
• M2's first result was COMPILE-ERR, which was a bug in the gate rather than a result. My Find string began with a newline, so after the replacement the code merged into the preceding comment line and the mutation never ran. There is one reliable criterion: a compile error is the absence of a Total tests: line, never a grep.

#Two gaps measured but not fixed here

• The return type renders as None when the body ends in a tail expression. fn f() -> Int { 1 } gives f() -> None, while fn f() -> Int { return 1 } gives f() -> int. This has nothing to do with raise: all four raise forms behave identically with and without an explicit return. Real MoonBit leans on tail expressions heavily, so its corpus impact is probably larger than raise's. The 0.4.23 tests therefore deliberately use an explicit return — otherwise the assertion would go red for a reason that has nothing to do with the effect annotation.
• A parenthesised function type in return position is read as a tuple. fn f() -> (() -> Int) { reports expected '{', with no raise involved (return_annotation's tuple branch stops at the first ) rather than the matching one). A real -> (Int, String) is fine. Corpus cost is small: 6 files in moui, 0 elsewhere. Next release.

#0.4.22 — named arguments matched by name, and Int32 read as Int

// declared order, core/pkg.generated.mbt:92
ActionCommand::new(intent~, label?, shortcut?, enabled?, group?, description?)
// call order, core/gesture.mbt:754
ActionCommand::new(intent=..., label=..., group=..., description=..., shortcut=...)

• One extra let r = build() line in the fixture makes three mutations survive. When an argument's type is wrong the behaviour lens reports the same call as MethodError, which merges with the type lens's ArgTypeMismatch (merge_findings groups by (merge family, line)), so count_family("ArgTypeMismatch") is permanently 0. Changing param_index to never match left all 432 tests green. A zero-count assertion can only fail if the finding it counts actually arrives under that family.
• Two on one line collapse into one. Same reason: merge_key is (merge_group, line), so two wrong arguments written on one line come back as one, and a case expecting 2 must be split across lines.
• parse_call_args has four push points. The one for "an argument that does not start with a name" is not the one for "starts with a name"; missing a single push does not error, it leaves labels shorter than args, and every argument after the gap reads some later argument's label. The fixture added for this is g(1, b=true) — which also settles a semantic: a ? optional parameter cannot be passed positionally at all (moon check reports "requires 0 positional arguments"), nor can a required ~ label; only a bare a : Int can. Which is exactly why named arguments are everywhere in real MoonBit and why positional matching produced so many false positives.

• M7, the all_positional gate (no arity check on labelled calls). No test can see it, because no valid MoonBit program passes more named arguments than the function declares — settled: a duplicate label is 4084 and a label naming no parameter is 4085, both compile errors moon check already reports. Its cost was measured rather than assumed: across 12,428 files in the six corpora it changes exactly one finding, an arity report in mouibackend/web/web_host.mbt past that file's reliable-region boundary, so it lands in the unreliable bucket and is never shown as a result. That one could not be confirmed as a true positive, and an argument-COUNT check is exactly where a misread cross-file signature manufactures a false positive. Writing a test that pins a behaviour no valid program exhibits would make the gate green and the suite weaker.
• M8, method-call labels. EMethodCall carries labels now, but infer discards them (EMethodCall(base, _, args, _)), because method arguments are not type-checked at all in this model — there is no receiver signature to check them against. That is a real gap, not a designed leniency: killing it needs a method-receiver signature, which is a larger change than this release.

#0.4.21 — 436 → 481: guard, lambdas as named-argument values, is across a newline, and an is that bound only its first name

#C is the hardest kind of bad here: it parses, and the tree is wrong

guard (self.frame, self.image, self.host_bridge)
  is (Some(frame_state), Some(image_state), Some(host_bridge)) &&
  !self.disposed else {

#D: settle first, and the answer was not the obvious one

fn f(x : Int) -> Int {
  guard try_os(x) is Some(Os(error)) else { return 0 }
  error + 1
}

• not _, not a keyword
• the next token is not ( — that is a nested CONSTRUCTOR, not a binding
• neither neighbour is . — @core.Role::Checkbox is a qualified path, 18 in corpus
• the first : ends it — the rest is a type annotation and Int is not a binding; a qualified path's :: lands on the same rule

#The differential caught a regression I had INTRODUCED