803 Commits

Author SHA1 Message Date
534907d204 Merge: the registry answers honestly under churn 2026-09-18 07:50:48 +07:00
739b871ff1 The eight attempts at reading the table now wait between themselves
Retrying immediately looked like eight chances and was one: a walk that bails
at the epoch check costs almost nothing, so all eight fit inside the single
compaction they were all losing to, and the listing refused having waited for
nothing. A quarter of a millisecond between attempts -- the agent's break-loop
idiom, legal here because the waiter is the listener thread and never the game
loop -- bounds the whole refusal at two milliseconds. Measured with a writer
noting and freeing on top of three thousand live blocks: 8 right answers in 200
without the pause, 200 in 200 with it. It is not magic, and the comment says
so: a writer that spends most of its time rearranging the table still gets
refused, which is the honest answer and used to be a zero-row lie.

The two cases the last commit left unwired are wired now, and a third joins
them: a listing taken while the table really is being compacted, which nothing
covered -- the full-of-live case never compacts and the churn case is
single-threaded, so the retry itself was exercised by nothing. It asserts only
what a slower machine cannot change: never zero rows, never a count that is
neither right nor a refusal. How the rest divides is printed, not pinned.
2026-09-18 07:47:57 +07:00
d8fc41a142 Merge: a failed module leaves the session as it found it 2026-09-18 07:45:02 +07:00
1d788dfda4 The queue-full refusal stops contradicting the note two arms above it
It ended "send it again once the program is running", which reads as a
withdrawal of what eval promises a parked program on every other evaluation:
that a body redefined while parked installs when the program is run again.
What is true is narrower — this module was not taken, and the run that drains
the sixty-four already queued is what makes room for it.
2026-09-18 07:43:38 +07:00
b23dcf73f3 The session is put back however the module failed to land
The three named arms are not every way a step after the check can fail.
write_file makes the daemon's copy of the module's text before llc is called at
all, and a Sys_error from it went out through serve's guard with the session
already holding the declaration — the same stranded declaration under a
different exception. Dev.eval now restores on the way past anything that
escapes, and carries an accepted flag so that a module the agent has already
taken is never rolled back out from under the process.

That is also the seam the crash can be reproduced through. test_dev takes the
daemon's working directory away from it — its own, not the macro cache the two
failures above use, which cannot fail a build with no macro in it — evaluates a
defn, and then calls it. Without the restore the daemon lists probe-two in
describe and the call closes the socket: the null cell, the game thread, and
address 0.
2026-09-18 07:42:41 +07:00
1eea388a47 Merge: the Emacs client stops eating frames, replies, and second sessions 2026-09-18 07:40:37 +07:00
866c0792e0 Two checks that would have been read wrong, and one that could have flaked
The unreadable-frame case wrote both frames as one string, where `(:a14' reads
as a typo rather than as the end of one frame and the start of the next; they
are two inserts now, with a line saying which is which. And the check that a
request after a daemon restart does not wait out a reply the old connection
owed was asserting against the same number it had bound the timeout to -- the
one arrangement that cannot tell "fast" from "timed out a moment ago". The
timeout is ten seconds and the assertion is three, which is the gap the claim
is actually about.
2026-09-18 07:40:10 +07:00
5caf455e66 A compaction that can reclaim nothing does not run, and a listing nobody could read says so
The registry compacted whenever the table was three quarters full, and a
compaction reclaims dead entries and nothing else. A program holding more than
three quarters of the table in live blocks therefore compacted on every
allocation for the rest of its life, reclaiming nothing each time and holding
the table-wide epoch odd while it did. A listing racing that loop lost all
eight of its attempts and answered with zero rows -- "nothing is held", about a
program holding three thousand blocks, from the verb that exists to find a
leak. Measured at 199 wrong answers in 200.

The trigger now also asks whether there is an eighth of a table's worth of dead
to reclaim, which is a count four places maintain: a death, an arena's
free-all, a note written over a dead slot, and the sweep itself. That bounds
the cost from the other side too, since a sweep that runs reclaims at least 512
slots and so cannot run twice in 512 allocations.

Separately, flan_dev_reg_by_type answered a walk it could not take with zero
rows, which is the same number a program that had freed everything gets, and
stepped past slots flan_reg_snap could not copy while still calling the walk
whole. It now counts those slots and returns -1 with the count, the agent
refuses in a sentence the daemon already renders, and the snap contract says
which caller keeps it and why reg_at is allowed not to.

A note that finds no slot is still dropped -- dying because a diagnostic ran out
of room would be the diagnostic shooting the patient -- and now says so on
stderr once, quoting how many entries were dead rather than claiming the table
is all live.

test/dev_limits.c gains three modes, driven from test_reload: 3100 live blocks
read under a writer thread (1 right in 200 before, 200 after), 3000 live with
600 churned on top of them to prove the sweep still runs, and a genuinely full
table that must say so exactly once.
2026-09-18 07:36:45 +07:00
f186284a4d Quitting ends one session, and connecting elsewhere says what it is leaving
`flan-dev-quit' promises to stop the daemon this Emacs started. It sent `close'
down the current connection as well, on the assumption that the two are the
same program -- and `flan-connect' is the command for attaching to one that is
not, so the assumption was one keystroke from being false. Connect to a daemon
running in a terminal, quit, and two programs ended: the one Emacs owned, and
somebody else's.

The daemon's socket is now kept apart from the connection's, which is what lets
one be told from the other. `flan-connect' names both programs before it
abandons a connection belonging to a daemon this Emacs started, and refuses
outright for a Lisp caller, as `flan-dev' already did for a running program.
`flan-dev-quit' on a connection that is not the daemon's closes that connection
and says what it left running. `flan-dev-restart-program' restarts on the
daemon's own socket, and refuses while the connection is elsewhere: there is no
reading of "build it again" that leaves one session where there was one.
2026-09-18 07:35:55 +07:00
eed0cfa950 C-x C-e at the top of a file has nothing behind it, and says so
`backward-sexp' does not signal when there is no form before point; it goes to
the beginning of the buffer and stays there. At point-min that is no movement,
so the form the dispatch then looked at was the one *after* point -- whose head
is very often a declaration -- and the region between start and end was empty.
The key installed the file's first declaration by name with no body, which the
daemon accepts, and the echo area reported it as a change. Both paths check for
movement now: the predicate refuses, and the expression arm refuses in words
rather than asking the daemon to evaluate the empty string.

The same predicate asked only for the depth at the open delimiter, and a form
written at column 1 inside a comment or a string is at depth 0 like any other.
A `defvar' in a comment is prose; it is not offered as a declaration any more.
Depth in a narrowed buffer still means depth within the narrowing, which is
noted where it is read rather than changed.
2026-09-18 07:32:34 +07:00
a2449ed7c1 Merge: an enum member is checked against the i32 it will be 2026-09-18 07:32:28 +07:00
9585d8c2fe An enum member is checked against the i32 it will be, before anything reasons about it
The members of a defenum are i32 at run time, but the reader hands the parser
an int64, so a value too large for the type arrived looking ordinary: truncated
by the x86 backend, malformed in the LLVM IR, and -- the reason this is a
correctness hole and not a nicety -- invisible to the duplicate-value rule
sitting right below it. That rule compares int64s, so (defenum E [A 0
B 4294967296]) passed it: the two differ as int64 and are both 0 as i32, and
the one check written to catch two names for one number waved through exactly
the case it exists for.

Each value is now checked where it is resolved, which is before the collision
scan runs, so the scan compares the numbers the program will actually have. A
value that does not fit is refused rather than quietly made to fit, naming the
member, its enum, and the value, with a different sentence for a value that was
written and one autoincrement walked into -- nothing in the source wrote
2147483648, so the refusal has to say where it came from before it can say it
is wrong.

The check is bound with a let rather than inlined into the cons, and that is
load-bearing: OCaml leaves :: operand order unspecified and takes the tail
first, so an inlined check would run after the recursive Int64.add and let
(defenum E [A 9223372036854775807 B]) wrap to min_int and refuse B for a number
in no one's source. Bound first, A is refused and the wrap is unreachable.

The parser is the only place this needs to happen: Parse.decl is the sole
constructor of Ast.Defenum's member values, and Load only re-qualifies the
enum's name.

Explicit-duplicate aliasing is untouched; that rule is deliberate.
2026-09-18 07:31:00 +07:00
acf38ac064 The poll settles like every other sender, and the settle runs before the reconnect
`flan-dev--poll' guarded on `flan-dev--busy' and nothing else, and the watch
timer is precisely the sender that does not bind it: it sends without waiting,
so it has nothing to hold. A poll landing in that gap sent `describe' down a
connection that already owed a reply, read the watch's answer as its own, and
left its own for the watch to read a tick later -- after which the two
consumers stayed swapped for the session, each of them answering the other's
question. It runs `flan-dev-settle-hook' now, which is the invariant the hook's
docstring already claimed.

And the hook runs before `flan-dev--live-connection' rather than after. An
outstanding reply belongs to the connection it was asked on; when a daemon has
been restarted the old connection is gone and no reply is coming on the new
one, but the hook was being asked about the new one and blocked a full
`flan-dev-reply-timeout' -- a frozen Emacs on the first key pressed after a
restart, with the watch armed. `flan-dev--busy' now covers the reconnect too,
which asks the new daemon what it defines and so must not be interrupted by a
poll either.
2026-09-18 07:30:43 +07:00
a70cfadd94 A bad frame costs one request, not the connection
Two orderings in the reply reader, and both of them were permanent. A frame
whose header arrived and whose body did not fell through the wait loop into
`flan-dev--extract-reply', where `byte-to-position' signalled a wrong-type
error on a position past the end of the buffer -- so the timeout message the
function goes to some trouble to word was never the one anybody read, and the
header stayed at the front of the buffer, where the next request took it as
its own and every request after that was answered by the one before it. The
body deadline is tested again now rather than trusted, and the dead frame is
erased: the timeout is said in the words meant for it, and the connection is
back in step. The header deadline still erases nothing, because a partial
header is a valid prefix of a reply that is merely slow.

The other is `flan-dev--extract-reply' reading the payload before deleting it,
so a payload that would not read was never consumed and the same bytes
signalled again on every later request. It is deleted first now. That makes
the frame gone whether or not the read succeeded, which `flan-watch--tick' has
to know: it cleared its pending flag only on a reply it got back, and would
otherwise wait for ever for one no longer in the buffer.
2026-09-18 07:29:34 +07:00
47cb46aa00 Merge: a while condition joins the loop's move regime 2026-09-18 07:28:16 +07:00
c31feb85eb A while condition runs every trip, so it may not move what it stands on
The condition was checked before in_loop, outside the diff that catches a
loop giving away what the next iteration needs. Emit puts the condition in
the loop header, so it runs again every trip: a condition that frees a
local freed it once per trip. It is now diffed against the same dead set,
with its own reason. A dotimes count and a loop's initial values stay
outside: those are evaluated exactly once.
2026-09-18 07:26:28 +07:00
d36c77ba6b A parked program's full reload ring says why it is full
The agent refuses a module it has no room to queue with "the program is not
calling agent/poll". For a running program that is the cause. For a parked one
it is confidently wrong: there is no game thread left to poll with, nothing
drains the ring until somebody runs the program again, and the ring is full
precisely because Dev.eval accepts evaluations while parked and promises they
install at the next run. At install sixty-five that promise breaks, and the
reply sent the reader to inspect a loop that is not running.

The agent cannot know this — parking is the merged shim's state — so the
daemon, which has just asked liveness, rewrites that one reply the way
abi_mismatch rewrites dlerror's. Every other refusal is still quoted in the
agent's own words, and a running program's is unchanged.

Pinned on Dev.refusal rather than end to end: filling the ring is sixty-four
real clang runs, and what the daemon does with the agent's words is the whole
of the change.
2026-09-18 07:26:07 +07:00
cf410c5da3 A declaration that fails to build or deliver leaves the session as it found it
Session.eval committed the checked program the moment a form checked, and the
two steps that can still refuse it — the build, and the agent taking the
module — come after that, in the daemon. Either one left the editor holding an
error and the session holding a declaration the process has no body for. The
next module built for that session lists the name in its install prologue,
which interns a cell for it and never stores anything into it, and a dev
build's call through a cell has no null test in front of it: the game thread
jumps to address 0 at the next C-x C-e, locals render or globals refresh.

Session.held takes the four fields eval commits as one unit and Session.restore
puts them back. Dev.eval and Dev.eval_expr take one before checking and restore
it on every arm where nothing was accepted — a failed build, a refused
delivery, an unreachable agent. eval_expr needed it for the generic instances
it keeps, whose own comment already claimed the invariant: "the session must
not come to believe it holds a body that no module was ever written for."

A delivered module that then times out is not a refusal and does not roll back:
the agent has it and will install it at a frame boundary.
2026-09-18 07:24:45 +07:00
ce3e879e83 The hunt's ledger: five dispatched, the rest recorded 2026-09-18 07:08:49 +07:00
1f75744b06 Four lanes in, and what is left is the author's 2026-09-17 23:25:10 +07:00
c0ccbe2df2 The runtime stops trusting multiplication, sharing one buffer, and keeping an unread word ambiguous 2026-09-17 23:14:28 +07:00
c59cc95679 The removal joins the deferred map operations in the test and in the note
The arm was written with the others and through the same deferral, and neither
the generics row in test_flan.ml nor the paragraph in BUILT.md that enumerates
what defers had it. Its placeholder is get's, for get's reason: it answers an
(Option V), so the match around it still has to check while the key is a
variable.
2026-09-17 23:13:30 +07:00
9f85139f1f An Option has no fields to take the address of, and two rows now say so
FIX.org carried Addr(Pfield ...) on an Option as a hole in both backends. It is
not reachable from the language: a field access goes through struct_target,
which admits a struct or a pointer to one and refuses everything else by name
with a location, so (addr (.x o)) is refused at the field and never reaches a
place. The node that failed was one the compiler built for itself.

The refusal is pinned on the bare field and on the address of one, and FIX.org
now records the finding, including the asymmetry that stays: the x86 backend
lays out an Option's tag and value as fields and the LLVM backend does not.
Neither path is reachable, so matching them would be untestable code written to
balance a road nobody drives on.
2026-09-17 22:59:03 +07:00
81b807f544 A rendered number goes in the caller's frame, not in one buffer for the process
Every number-to-text conversion wrote into one file-static in the runtime and
answered a slice over it, and nothing copied. Two of them in one expression
printed the second number twice — no crash, no diagnostic, and nothing a
sanitizer could find, because every byte read was inside an object that was
alive. The wrong object.

The buffer is now the caller's, one frame slot per call site. The slot is
allocated in the checker rather than in either backend: a slot is a
function-lifetime location in both of them, where an x86 backend temporary is
bump-allocated and reclaimed at the end of the expression that made it — which
is the one lifetime a returned slice must outlive. Each backend gains one
pointer argument and no reasoning of its own, which is what keeps them
symmetric.

The static is gone rather than left unused, since a buffer with nothing but a
comment beside it is a loaded gun. What remains is the ordinary lifetime a
pointer into a frame has: storing one of these slices in a container that
outlives the frame, or returning it, is still a copy the caller has to make.
NEXT.md's sharp edge now says that instead of what it used to say.
2026-09-17 22:55:30 +07:00
9d10e7edb0 The allocation registry stops being read out from under its writer
The writer is the game thread, in every allocation and every free; the reader
is the agent's listener, on a program that is running. Nothing stood between
them. The consequence is not a slightly wrong count: a row's type pointer and
its length mean nothing apart, and a reader that takes the new pointer with the
old length reads off the end of a string literal.

Each entry now carries the watch table's seqlock, odd while it is written, and
a reader copies the entry and re-reads the counter before believing it. The
compaction bumps a table-wide counter around itself, because it moves entries
between slots and no per-slot counter can describe that; a scan that sees that
counter move walks again. It clears the table slot by slot rather than with one
memset, since the memset would zero the counters a reader was holding.

The breakdown and the leak report stay answerable while the program runs, which
is the moment they are for. reg at does not: whether one address is still live
is exactly what a running program is changing, so it is refused the way every
break verb is refused, which is what the daemon already did on its own side.
2026-09-17 22:37:19 +07:00
594a42b54e A map you can take a key out of, and the run closes behind it
(map-remove! m k) answers the value that was there, or None, which is the
answer get already gives and for the same reason: a key that is not in the map
is an answer, not a failure. Handing the value back rather than dropping it
makes "take this out and use it" one call instead of two that hash the key
twice.

The removal shifts the probe run back over the hole. A Robin Hood lookup stops
at the first empty slot, so a hole left in the middle of a run hides every
entry after it — and the hidden ones are precisely what a test that only asks
after what it removed never looks at, which is why the program removes a
thousand of two thousand keys and then asks for the other thousand.

Odin was read rather than recalled here, and it does the opposite: its erase
marks a tombstone and its insert carries the repair loop. Staying tombstone-
free keeps the shape the rest of the file already assumed, and the lookups —
which outnumber the removals — pay nothing for it. The note in the runtime and
the two in BUILT.md that said Odin deletes by backward shift were describing
Odin's insert, and now say which is which.

It allocates nothing and releases nothing, so there is no guard around it and
it means the same thing on a map in an arena as on one in the heap: a key and a
value live inside the one block the map allocated, and there was never anything
per entry to hand back.
2026-09-17 22:31:58 +07:00
0fd83dc95e The driver refuses in sentences, and CI exists 2026-09-17 22:23:19 +07:00
aaca776afd A clock, the rest of libm, getenv, and the small file verbs 2026-09-17 22:21:24 +07:00
9a32910882 The header says where this stops and what picks it up next 2026-09-17 22:19:16 +07:00
263b9bb627 Four places the runtime answered with something other than the truth
The argument vector's malloc was unchecked, and a failure there would have
published a null pointer with a length beside it. It now dies naming what it
was building, because argv has no allocation site for a condition to hang on.

flan_slurp_into read a capacity of elements as a capacity of bytes and skipped
the epoch check every other container operation runs. The element size is now
a parameter and the length it publishes counts whole elements, so the day slurp
answers something other than (Vec u8) it does not answer with bytes nobody
wrote.

A string with a NUL in it is refused at the C boundary, which is the policy
flan_path_cstr has always had for a path: C reads to the first NUL, so what
crosses is a prefix of what was passed, and a window title is no different from
a filename in that respect. The refusal names the declare-c, which is the name
the program's author wrote.

The runtime's two translation units are compiled with -Wall -Wextra. They were
already clean under both; the flag is there so the next one is caught rather
than read.

The generation word keeps its place and loses its "yet": a reader for it is a
third word on every slice in the language, which is a spec amendment rather
than a runtime patch, and the comment now says so where someone deciding to
trust the word would read it.
2026-09-17 22:17:19 +07:00
96e5fab77f flan run does not offer --dev, and says so rather than building one
--dev builds a program whose call sites go through indirection cells so
something can attach and redefine through them. Nothing can attach to a
process this command builds, execs, waits for and deletes, so the flag had no
meaning here -- and an --x86 --dev route through run would have falsified
Build's own statement that flan dev never reaches that fork because --x86 is
read only by flan build. It falls into the refusal arm with a sentence
instead.
2026-09-17 22:12:54 +07:00
16498a4e60 The alias that nobody ran now has something that runs it
A GitHub Actions workflow on push: dune build, dune test --force, dune build
@checks. @x86 parity is not under dune test, so the routine suite never
protected it; both of this repository's silent failures would have been caught
by one person typing one command, and the problem was never the command.

The suite step keeps its log and greps it for Fatal error, because a suite
that passes while leaving an unhandled exception on stderr is one that is
telling you something and being ignored.

FLAN_LLC is pinned to the llc matching clang's version rather than left to
PATH order: the live loop goes llc + ld -shared + dlopen and never calls the
clang driver, so a mismatch breaks every reload test while flan build keeps
working, which is a bad failure to debug from a log.

What an Ubuntu runner cannot cover -- raylib by exact Fedora soname,
emscripten, a wasi sysroot, lldb -- is written in the workflow with the skip
path each one already takes, so the tick does not read as more than it is.
README.md and test/dune both said there was no CI; both now say what there is
and what it misses.
2026-09-17 22:11:25 +07:00
4d1af07cd0 Rebased onto defdata, and the untagged union is refused by name
The tagged sum is Tast.data now and Tast.unions is C's untagged union, which
arrives as a structure whose every field sits at offset zero. That is a
layout, and a layout is the one thing an object has none of here -- two
properties cannot share a run of bytes -- so it is refused with the type's own
name rather than met as "not a struct".

Two hardenings the sweep could not have found. $str built a view onto node's
Buffer pool, where small Buffers share one ArrayBuffer, so a write through one
string literal's slice could have reached another's bytes; native puts a
literal in .rodata where that write is a fault. And copy_of's Option arm named
its argument three times, which evaluates it three times.

SURVEY_FLAGS reaches both sides now, as it does in the x86 sweep, so the
unchecked indexing path -- a bare a[i] with no $at around it, which nothing
had ever run -- is swept too: 23 match, 0 differ.
2026-09-17 22:08:42 +07:00
98dce374d1 The FFI example declared a name the prelude now has
web/examples/ffi.flan opened with (declare cos-f64 [x f64] f64 "cos"), which
was a fine one-liner until the prelude grew cos-f64 an hour ago. @page caught
it: "cos-f64 is defined twice", with the prelude line named as the other site.

It is cosh now. Same shape, same answer, and the collision is worth keeping in
the page rather than editing around silently -- a reader reaching for a libm
function needs to know the common ones are already there and that a second
declaration of a name is refused, not shadowed. The example says so in one
sentence.

This is the cost of filling out the prelude, and it is the whole of it: a
program that declared one of the new names for itself stops compiling, with
both sites named. Nothing in the corpus or in examples/ hit it; this page did.
2026-09-17 22:06:59 +07:00
f0fd54f0f0 The sweep is behind @js, because dune test stays fast
The alias is @x86's shape and deps: one rule over spike/js/survey.sh, FLAN
passed so the script does not start a dune inside dune's own lock. It is not
in the default run and node is probed rather than assumed.
2026-09-17 22:05:48 +07:00
dfe0296479 The sweep is the evidence: 24 match, 0 differ, 71 refused by name
spike/js/survey.sh is the x86 sweep's shape with one deliberate difference in
what it counts. That backend is behind, so a refusal there is a regression and
its strict mode fails on one. This is a dialect, so a refusal is the design
working -- a pointer, an allocator, a Map, the FFI and conditions are refused
permanently and correctly. What fails the @js alias is a DIFFER, which is a
wrong answer, and a CRASH, which is JS this backend emitted and node would not
run.

Two probes carry the decisions the corpus does not reach. p1-int-semantics
prints wrapping at all eight widths, a multiply past 2^53, truncating division
with a negative operand, shifts whose count is out of range, bitwise over a
u32, f32 that is not a double, and the conversions both ways -- 35 lines, all
identical to the LLVM build. It found two real bugs: >>> binds tighter than &
in JavaScript, so a bit-and on a u32 answered -1; and a 64-bit value through
Number() rounds to 53 bits before it can be truncated, so (i32 i64hi) answered
0 where it must answer -1.

p2-value-copies goes past values.flan to the cases a shallow copy would pass:
a struct inside a struct, a struct returned out of a function, an element read
out of an array of structs, and a global.

Also fixed, and all three were found by the sweep rather than by reading: a
unit-typed call in statement position was compiled to an expression nobody
emitted, so (load-xs) silently did not happen; an arrow body that starts with
a brace is a block, so a zeroed array of structs was a syntax error; and a
bounds message must carry the index expression's location, not the form's,
because that is the one emit.ml passes to check_at.

Render reads an Option's tag as field 0 and a union's as field 0, which is the
LLVM layout and not this one, so both are answered here rather than refused.
fdefers is dropped rather than refused: nothing in the dialect can start a
transfer, so the transfer exit path is unreachable, and refusing it would have
refused every program that writes a plain defer.
2026-09-17 22:05:25 +07:00
dfb02ee26a A Flan struct is a JS object, and the memory model does not come along
lib/js.ml lowers the same checked Tast the other two backends take to one
CommonJS file, by object mapping rather than linear memory: docs/DISCUSS.md
item 5 settled that fork before this was written, and item 5's consequence is
the whole shape of the file. Object mapping means the host's collector owns
every value, so there is no (Ptr T), no free, no arena and no allocator, and a
program that uses one is refused by name with a location rather than compiled
badly.

flan build --target=js leaves Build.executable through its own two lines,
before anything that assumes a clang: there is no object to compile and no
linker to run. --dev, --debug, --sanitize and --x86 are refused there rather
than swallowed. Js.Unsupported exits 3 beside X86.Unsupported, so a sweep can
count refused-by-name apart from did-not-compile.

What runs end to end: integer and float arithmetic with the normalisation each
width needs, let, if, while with break and continue, calls, function values,
structs, fixed arrays, slices, unions, options, match, and println through the
same structural printer the other backends walk.

Value semantics is the trap the object mapping sets and the reason the header
carries a section on it. A Flan struct and a fixed array copy on assignment and
a JS object does not, so every site emit.ml memcpys emits a generated
Point$copy here. Fable's JS backend faces the same question for F# structs and
answers it the other way -- it inserts no clone, and its Rust backend does --
so the divergence is deliberate and the survey pins it.
2026-09-17 22:05:25 +07:00
901376ba49 The three new programs join the two memory sweeps
Both corpora are explicit lists and not globs, so a program added to
test/programs is covered by dune test and by @x86 and by nothing else until
somebody types its name here. files.flan, math3.flan and time.flan are typed.

time.flan is the one with something to say. getenv hands back a slice viewing
the process environment and never a copy, which is the exact shape a
use-after-free or an off-by-one length would be, and neither ASan nor memcheck
had ever seen it. files.flan brings three more path buffers through
flan_path_cstr. math3.flan is the cheap one and is here for completeness.

files.flan makes and removes its own tree, so the sweeps' two runs of it see
the same directory both times.

@sanitize is clean with all three in. @valgrind is not run here -- it is tens
of minutes and opt-in -- so those three entries are checked by the next person
who runs the alias.
2026-09-17 22:05:07 +07:00
c5b8af23a1 Files beyond slurp and barf, split by whether a handler could act
Five more: file-exists?, file-size, delete-file, rename-file and
make-directory. The interesting thing is not the list, it is the line drawn
through it.

file-exists? and file-size answer a value -- a bool and an (Option i64) -- and
are prelude functions over one declare that the compiler knows nothing about.
Absence is the reply to those two questions and not a fault, so a condition
would make the ordinary case pay for a handler search, and there is no restart
a handler could take that would turn "it is not there" into a different
answer.

delete-file, rename-file and make-directory answer () and signal FileError,
and they are check.ml builtins for the one thing a declare cannot do: they go
through file_guard, so each failure arrives under retry and use-value. Those
are restarts a handler really can take -- make the parent directory and retry,
or supply another path -- which is exactly the case a bool return throws away.
op continues the prelude's numbering as 2, 3 and 4.

One C function behind the two questions rather than two, because they are one
question: stat answers whether the path resolves and how big it is in the same
breath. It is stat and not flan_file_size's fopen-plus-ftell, which is shaped
by slurp being about to read the file and is wrong as a general size -- fopen
on a directory succeeds on Linux and ftell then answers a number that is not a
file size. The two coexist and answer different questions.

rename holds the source in the guard's path slot, so a use-value renames a
different file to the same destination. Both readings are plausible until
somebody says which, so check.ml says which.

The errno mapping is not extended. Its three buckets are what a handler can
act on; EEXIST and ENOTEMPTY land in io with everything else, and that is
honest until conditions have a hierarchy to hang a fourth reason off.

All three carry barf's decision 2 unchanged: they change the filesystem, so on
the web they signal rather than succeeding quietly into a filesystem the page
throws away.

Not here, and not half-parsed either: a directory listing, which needs an
allocating builtin and a Vec of owned strings, and streaming IO. Neither has
a name to trip over.

programs/files.flan makes and removes its own tree and takes both restarts on
operations that write. The runtime additions continue the block at the end of
flan_rt.c.
2026-09-17 22:04:48 +07:00
2dd13b5ae0 The language can tell the time, and read its environment
Nothing in it could. A game got a clock from raylib and a program without a
window had none at all, so "how long did that take" was unanswerable in the
half of daily use that is a tool rather than a game.

Two clocks, because the mistake a single one invites is using it for the other
job. monotonic-ns measures: it never goes backwards, nothing adjusts it, and
its zero is arbitrary, so it is meaningless alone and correct as a difference.
unix-ns dates: nanoseconds since 1970, which is what goes in a save file, and
which jumps in either direction when somebody sets the system clock. The names
are picked so that reaching for the wrong one reads wrong.

This is Odin's shape, from core/time/time.odin and core/time/time_linux.odin:
Tick against Time, both an i64 of nanoseconds, over MONOTONIC and REALTIME,
with the seconds-valued face derived rather than a second syscall. Three C
functions here and six Flan names over them, which is the rule flan_rt.c's own
header states -- a primitive is the only thing implemented twice.

The monotonic origin is the first read of the clock in the process, not boot,
and that is the one decision worth arguing. CLOCK_MONOTONIC counts from boot,
so on a machine up a hundred days the raw value is past 2^53 nanoseconds and
monotonic-seconds would lose sub-microsecond resolution depending on the
machine's uptime rather than on anything the program did. Latched to first
read it stays integer-exact for a hundred days of process life, and it also
matches what a game already has: raylib's GetTime is seconds since
InitWindow, so the two numbers now mix without a conversion at every site.

sleep-ns loops on EINTR, because otherwise a signal cuts the wait short and a
frame loop wobbles for reasons nothing in the program explains. It is
documented as at-least and not as a frame limiter; the shape that actually
paces a loop is a deadline recomputed from monotonic-ns each turn, and the
comment says so where somebody will read it.

getenv answers an (Option [u8]) viewing the process environment, which needs
no allocator and no free and is safe precisely because nothing in this
language can call setenv or spawn a process. The absent case rides in the
length rather than in the pointer: there is no null test to write, since a
(Ptr T) here always addresses something, so flan_getenv answers -1 and a
pointer at a valid empty string and the Flan side tests arithmetic.

The runtime additions are a single block at the end of flan_rt.c, with
<time.h> inside it for the reason <errno.h> sits beside the file section.

programs/time.flan asserts invariants and never a reading -- t2 >= t1, a sleep
that did not return early, a date after 2020 and before 2100 -- because the
same file is in the corpus @x86 builds twice and diffs, so a timestamp would
fail a correct compiler on its second run.
2026-09-17 22:04:48 +07:00
aeeb6de59d The maths is the whole family now, at both widths
The prelude's declare surface was five f32 functions, and the five were there
because somebody needed each one. Everything else a caller wanted was written
as a declare at the top of their own file -- the identical libm call with none
of the caveats written down.

So the rest of libm is here: tan, the three inverses, the three logarithms,
exp, fmod, hypot, cbrt, fabs, and an f64 face for every one of them including
the five that already existed. A declare is a line, a symbol already on the
link, and nothing in either backend, which is why this was cheap enough to do
completely rather than one function at a time.

The f64 half is not decoration. f32 is what a position is; f64 is what a
measurement is -- the clock, parse-f64, format-f64, any sum over more than a
few thousand terms -- and having only the f32 face forced a cast down and back
at each of those boundaries, which is where the precision went.

The paragraph the sqrt note draws for itself is now drawn once for the family:
IEEE-754 specifies sqrt, fabs, floor, ceil, round and fmod as exact or
correctly rounded, so those agree bit for bit across glibc, musl and
wasi-libc; it requires nothing of the rest, so the sand-grid rule covers all
of them unchanged. floor, ceil and round are Flan at f32 and libm at f64, and
that is not an inconsistency: the f32 bodies work because every f32 with a
fraction fits in an i32, and at f64 that trick is gone.

abs-i32 and abs-i64 are Flan, one per width because min and max are builtins
and no generic covers the numeric types. pi and tau at both widths, written
out rather than derived so the compiler rounds each literal once.

programs/math3.flan covers it at values that are exact in binary, so nothing
pins one libm's last bit. The -O0 case is the one that matters: at -O2 LLVM
folds a call over two literals and leaves no symbol to resolve, which is how a
missing -lm hid the first time.
2026-09-17 22:04:48 +07:00
ccb100d74c The command list is all eleven, the environment is written down, and one promise is withdrawn
README documented four subcommands of eleven. The seven missing ones are
there now, with import-c and generate-c given a worked example each -- they
are the most valuable thing here that nothing documented at all.

An environment table, checked against the getenv sites rather than against a
list: thirteen variables, each with where it is read, plus the llc/clang
version coupling that breaks C-c C-c while flan build keeps working. The
FLAN_DEV_* set that flan dev hands itself across its own exec is named as
internal rather than left looking settable.

DISCUSS.md's survey of what the x86 backend had no plan for still listed the
whole condition family. x86.ml:1587-1615 lowers all of it and the survey is
104/104; the row is struck through and corrected in place, because other
files cite that table by position.

prelude.ml promised a core: package at milestone 3. Milestone 3 came and went
and the package did not, so the docstring states the limit instead of
promising a way out of it. The loader could carry one -- what is missing is
the decision about what core: means for a program that imports nothing.
2026-09-17 21:50:33 +07:00
366a8724ba A byte count that cannot be represented is StorageExhausted, not a smaller block
Every size the containers compute is a product of a capacity the program chose
and an element size the checker did, and a product that wraps leaves a block
that fits beside a capacity that does not. The next write goes past the end of
an allocation a sanitizer was told to expect, which is the one corruption
nothing in the suite could have found.

The Vec's growth, the Pool's two blocks and their sum, the map's five runs and
the budget check now go through checked arithmetic. A size with no
representation reports along the path an out-of-memory already takes, with the
largest number the condition's field can hold, since the true one has none.

The test pins the case the guard exists for: an element of 2^33 + 1 bytes at a
capacity of 2^31 wraps to 2 GiB, which a heap allocator answers.
2026-09-17 21:49:40 +07:00
668268b6cc The wait for a reply is a setting, and the directory installs
The 30s deadline in the reply reader was a literal and its message said only
that nothing had arrived. It is flan-dev-reply-timeout now, and the message
names the daemon buffer to look in -- a first compile on a cold cache is the
case that legitimately runs long, and the build log is what says so -- and the
setting to raise. Still never resent: a request the daemon took and died on
may already have run.

Package headers on all eight client files, so package-install-file on the
directory works and the client is not reachable only by load-path. The
daemon-buffer defcustom moves up beside the other buffer names, because the
reply reader now names it and the byte-compiler reads a file in order.
2026-09-17 21:48:03 +07:00
652361e169 A missing file is a sentence, and flan run's two argument lists are told apart
with_errors had no Sys_error arm, so flan check nosuch.flan ended in OCaml's
default handler; the daemon has had that arm since before the CLI did. A
Not_found backstop joins it — nothing reaches it today, and the day something
does the failure should name the file rather than say nothing at all.

flan run handed every flag it did not understand to the compiled program:
flan run game.flan --debug built at -O2 and gave the game a --debug. Build
flags are now the build's, -- ends them, and an unknown dash argument before
-- is refused by name with -- named as the way to mean it for the program.

-O0 through -O3 get a spelling on build and run, which they did not have at
all: Build.default pinned -O2 and --debug was the only route to anything
else. Four levels and not five, because -Os is clang's and llc rejects it,
and the same string reaches both. --debug with a higher level is refused
rather than quietly overruled by Build's own -O0.
2026-09-17 21:44:55 +07:00
223e282e44 An escaped diagnostic says which file and which line, not (_)
Three suite runs left "Fatal error: exception Flan.Loc.Error(_)" on stderr:
OCaml's default handler knows nothing about the diag record, so a process
that does not catch prints a constructor name and none of the message. The
trigger was a corpus file the test binaries check directly and nothing there
wraps. Registering a Printexc printer changes no control flow and costs the
drivers that do catch nothing; it only makes the corpse legible.
2026-09-17 21:44:46 +07:00
ac7ee912e7 A wrong main signature points at the main that is wrong
check_main raised against Loc.unknown, so both of its refusals opened with
<unknown>:0:0. env.locs is the table of where each type was declared and a
function is not in it, so the location comes from the declaration list the
caller already holds. A main that arrived without a defn keeps the unknown
span rather than being given an invented one.
2026-09-17 21:44:40 +07:00
8a430bb50c The review has four lanes, and the JS backend has its references 2026-09-17 21:43:58 +07:00
fbbd6c4984 What stands between this and daily use, ranked to be implemented from 2026-09-17 21:23:53 +07:00
e9d0b99096 The refusal was about teardown, and a region has none 2026-09-17 20:46:44 +07:00