From d722b267e6ebcdbc0a917cf2a3e18218bdf63aed Mon Sep 17 00:00:00 2001 From: Joseph Ferano Date: Sat, 19 Sep 2026 15:06:50 +0700 Subject: [PATCH] Two dyn rows had been asserting the stub's output, not the runtime's 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. --- test/test_acceptance.ml | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/test/test_acceptance.ml b/test/test_acceptance.ml index 9199fcc..9b230ef 100644 --- a/test/test_acceptance.ml +++ b/test/test_acceptance.ml @@ -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