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.
Joseph Ferano
d722b267e6