Joseph Ferano 3df49184a7 The combination nothing built is built now, eight cases of it
--dev --sanitize had been unbuildable for as long as a dev build has
armed the registry from a constructor, and nobody knew because no alias
built it: test_sanitize built the corpus twice and neither time --dev,
test_dev builds --dev and never with a sanitizer. A configuration
nothing builds can be broken for a month, and that one was. af71459
fixed it; this is what keeps it fixed.

dev_sweep, in the alias that already exists rather than a new one --
five names to remember was already four too many, and this is the same
question @sanitize is for. Seven programs built --dev twice, plain and
sanitized, run standalone with no daemon: a sanitizer report fails, and
so does any divergence from the unsanitized dev run.

Standalone is what makes it nearly free, and it works because a dev
build is not a dev session. The cells, the marker and the constructor
are in the executable either way, and a program that never calls
agent/start runs to its own end. That is why the list is mostly
ordinary programs built the other way: dev-noagent is the only one of
sixteen dev-*.flan that does not import the agent, and the rest stop in
the break loop waiting for an editor, which is test_dev.ml's business
against a real daemon.

The three dyn programs are not interchangeable and the difference is
the collector. dyn-vec allocates and never collects -- flan_dyn.c has a
one-megabyte floor and dyn-vec does not reach it -- so what it says is
that the registry and the allocator agree. dyn-map and p13-dyn-collect
are the only two programs anywhere past that floor, so they are the
only two under which a mark and a sweep run; without them a collection
had still never happened in a dev build under ASan.

dev_segv is beside the sweep rather than in it, because the program
that faults cannot be compared against an unsanitized run: that build's
handler prints its line and parks in the break loop, so the plain half
would hang, and the two are supposed to differ. ASan is meant to own
the fault -- flan_dev_crash_enable checks a weak __asan_init and stands
down -- so the case asserts ASan's report and the absence of the
handler's line. At -O0, because at -O2 the write through a bytes-view
of a literal does not fault at all and both builds print the string
unchanged. That yield had never run in any build anywhere; it was
behind a link that did not happen.

Checked both ways rather than asserted: eight failures with the
constructor naming declarations again, clean with it fixed.
Twenty-six seconds of the alias's 2m30 warm, and nothing added to dune
test.

Two aliases were also green only because dune test runs first.
@sanitize never listed the package directories pkg-diamond.flan
imports, and @page never listed sand.flan, which quotes.sh reaches
through sand-headless.flan; from a cold tree the first died before its
first sanitized build, and @page sits inside @checks where CI hides the
same thing. Both listed now. @valgrind, @x86, @js and @cells were
checked and are complete.

What it still does not reach is in FIX.org: a program driven by a real
flan dev daemon under ASan, which wants a --sanitize the CLI does not
have and a way through Dev.serve. --x86 --sanitize is refused by Build
by name, so there is no second backend to track here.
2026-09-21 12:08:36 +07:00
..