gen-rust emits the math builtins as bare free functions, which Rust does not have

[gHashTag]

The Rust backend already knows how to translate every math builtin, and never gets the chance to.

The defect

zig_builtin_to_rust maps the whole family correctly — "@min" if two => format!("({}).min({})", ...), "@sqrt" | "@abs" | "@round" | ... => format!("({}).{}()", ...). Its first line is:

fn zig_builtin_to_rust(name: &str, args: &[String]) -> Option<String> {
    if !name.starts_with(char::from(64u8)) {   // no `@` sigil
        return None;
    }

Specs write the builtins bare — abs(x), min(a, b) — so the table never answers, and the bare name is emitted verbatim. Rust has none of these as free functions, and rustc replies:

error[E0425]: cannot find function `abs` in this scope

The Zig backend closed this identical class at gen_expr, with a comment naming the same symptom ("use of undeclared identifier abs") and a declared_fns guard. The Rust backend has neither.

Measured

• 118 of 650 specs contain a call-shaped occurrence of one of the seven; 99 of those parse.
• Corpus-wide rustc acceptance of the emitted Rust is 429 of 650 (instrument: rustc --edition 2021 --crate-type lib --crate-name g --emit=metadata, with a control that compiles a valid file and rejects an invalid one — an earlier run of this measurement read 0 of 650 because the filenames carried .t27 and rustc derives the crate name from the filename, so nothing was ever compiled).

Three traps in the obvious repair

Each was measured, not anticipated:

1. A spec may own the name. 30 declarations across the corpus give one of these names to a spec function — fn floor in 10 specs, fn abs in 9, fn cos in 3. Redirecting those to a Rust method is a wrong translation that compiles, which is strictly worse than a bare name that does not. 3 of the 30 declare their return type Zig-style without ->, so a guard built on collect_fn_ret_types (which skips an empty extra_return_type) would be narrower than its subject exactly where it matters.

2. A literal receiver has no type. (5.0).sqrt() is error[E0689]: can not call method sqrt on ambiguous numeric type {float}, and so is ((2.0 / 3.141592653589793)).sqrt() — the first version of the guard tested for a single literal token and still admitted the compound form.

3. A const initialiser can never work. sqrt is not a const fn; inside pub const K: f64 = ... every spelling fails. Trading E0425 for E0015 there is a new failure, not a repair.

Separately: @log is mapped wrongly

The existing table has "@log" ... => format!("({}).{}()", ...), emitting (x).log(). Rust’s f64::log takes a base argument, so that is error[E0061]: this method takes 1 argument but 0 arguments were supplied. The natural log is ln. Filed here rather than changed under an unrelated title.

What the repair is worth

Honestly: corpus-wide rustc acceptance moves 429 → 429, a delta of zero. The emitted Rust of 9 files changes and none crosses from fail to pass — each carries other blockers, matching the repository’s established shape that a rejected file has four or five error families, not one.

The value is not the corpus number. It is that a clean spec can now produce Rust that compiles at all, which is the precondition for expressing hand-written code as specs. A worked example is in the PR: a spec port of rings/ring-103-rust/src/lib.rs whose generated Rust agrees with the hand-written original bit-exactly on 20,736 inputs, including NaN, both infinities, both zeros and subnormals.

[gHashTag]

Correction to my own figure in #3401, and a second reader that agrees.

The number I published was inflated

#3401 states corpus-wide rustc acceptance of the emitted Rust as 429 of 650, before and after. The delta of zero is unaffected and stands. The level is wrong.

Of those 429, 99 are vacuous: the file emitted no code at all — comment-only or empty — and rustc accepts an empty crate. My instrument counted "rustc exits 0" and an empty file exits 0 for the same reason a correct one does.

files with NO code (comment-only/empty) : 99   of which rustc-accepts: 99
files that compile AND contain a pub fn : 311
429 = 99 vacuous + 330 substantive

A second reader, working independently from the specs/ tree rather than from my generated directory, reports 311 of 650 (47.8%) for "compiles and contains at least one function". The two agree exactly on 311, which is the figure worth quoting.

That reader also puts it as 360 of 581 for plain rustc-acceptance among specs that generate at all — a different denominator from mine (it excludes the 69 that never generate) and not to be mixed with the 429.

Three further facts from the same measurement, which matter more than the number

1. gen-rust exiting 0 carries no information. It succeeds on exactly the 581 specs that parse succeeds on — the same set, never one more, never one fewer. "Generates" and "parses" are the same event, so a report of generation success says nothing about the artefact.

2. 536 of the 581 generating specs carry the NOT LOWERED BY THIS BACKEND banner. Of the 45 that do not, 42 have zero functions and 24 emit a 66-byte file holding only the two-line header. Three fully-lowered outputs contain any function at all.

3. Only two of the four backends admit what they drop. gen-rust emits its banner on 536 of 581 (compiler.rs:23874-23883) and gen-verilog an equivalent named block on 535 (compiler.rs:13605-13636). gen-c and the Zig backend emit no file-level header on any of the 650; 340 of 581 C outputs and 278 of 581 Zig outputs carry no honesty marker of any kind. Function bodies are dropped at the same rate in all four — 818 of 4851 emitted functions are unimplemented!() / /* TODO: implement */ / @compileError("not yet implemented") — so the difference is disclosure, not behaviour. The Verilog figure 4579 declared / 817 without a body matches the compiler own AST oracle t27c impl-status exactly, which anchors the table.

And one correction in the other direction

I described the language as lacking recursion when framing this work. That is wrong. t27 has recursion and it runs: a fib plus mutually-recursive is_even/is_odd spec compiles through gen-rust and prints fib(10)=55 even(10)=true, and there are 272 self-recursive functions across 38 of the 581 parsing specs. The constraint is narrower and belongs to one backend: gen-verilog lowers fn to a Verilog function ... endfunction, which cannot recurse, and the compiler already knows it — compiler.rs:9459 notes that disable "corrupts recursive static functions".