JosephFerano/flan
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Two dyn rows had been asserting the stub's output, not the runtime's

Browse Source 
Found by adding the --x86 rows beside them: the new rows failed, and so did
the LLVM rows they were copied from, identically and on the tip. That is the
tell -- a backend cannot change what a runtime prints, so the expectation
was what had gone stale. Both were written while flan_dyn.c was the stub
that mallocs and never frees, and the real renderer landed with different
answers to two questions the stub never had to answer.

The container line has a space after the open bracket because the space is
a prefix per element rather than a separator between them, and a text nested
in a container is escaped and quoted while the same text printed alone is
not -- three bare on its own line, "three" inside the vector. Both are
deliberate and both are pinned by the runtime's own C test, which asserts
"[ 1 2 3]" and "[ \"x\" \"a b\" ...]"; this file is the side that had not
caught up, so this file moves.

The trap sentence is the same story: it names the tag it found and the tag
it wanted, and the row now matches on that half rather than on the wording
the stub used.

dune test --force: 6 failures to 0.
This commit is contained in:
Joseph Ferano 2026-09-19 15:06:50 +07:00
parent c2d378957e
commit d722b267e6
1 changed files with 17 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
test/test_acceptance.ml
View File

@ -3008,7 +3008,17 @@ level "1"
"programs/dyn-basic.flan" dyn_basic_out;
outputs ~x86:true "dyn: an unannotated defn at two types, --x86"
"programs/dyn-basic.flan" dyn_basic_out;
let dyn_vec_out = "4\n[1 2.5 three true]\n1 2.5 three true \n" in
(* Two things in the container line that the stub this row was first
written against did not do, and the real renderer does on purpose. The
space is a prefix per element rather than a separator between them, so
the open bracket is followed by one — runtime/flan_dyn.c's [render],
pinned by test/dyn_ops.c's own "[ 1 2 3]". And a text *nested* in a
container is escaped and quoted while the same text printed on its own
is not, which is the third line here: [three] bare, ["three"] inside
the vector. Both were red against the expectation below until this was
corrected — on LLVM as much as on x86, because neither is a backend's
business. *)
let dyn_vec_out = "4\n[ 1 2.5 \"three\" true]\n1 2.5 three true \n" in
outputs "dyn: a heterogeneous vector"
"programs/dyn-vec.flan" dyn_vec_out;
outputs ~opt:"-O0" "dyn: a heterogeneous vector, -O0"
@ -3040,7 +3050,12 @@ level "1"
in
if code <> 134
|| not (contains text want)
|| not (contains text "required to be an i64")
(* The runtime's wording, and the stub's was different: what it says
now is which tag it found and which was wanted, then the value.
Matched on the half that carries the meaning rather than on the
whole sentence, so the row is about the trap being reached with
the right two things in hand and not about punctuation. *)
|| not (contains text "float, and an int was wanted")
then begin
incr failures;
Printf.printf