#251 stage2 runtime stdlib reload silently drops NEW prelude macro names (existing names refresh fine) — breaks the documented probe workflow
open
Opened by atgreen
Symptom: add any new defmacro to src/stdlib.lisp (e.g. (defmacro probe-bq (n) `(quote ,n))) and invoke it on build/funcl-stage2 — "attempt to call an undefined function", i.e. the invocation compiles as an unresolved call. The SAME macro body defined at the stage2 REPL works, and after make build it works on build/funcl (image bake registers it).
EDITING an existing prelude macro (e.g. today's or/#245 and defsetf-era probes on and/when) DOES take effect through the stage2 reload — only NEW names are dropped. Position in the file is irrelevant (probed top, mid, end). No MACROEVAL-PASSTHRU on stderr; gdb shows the call site emitted as a direct call to UNRESOLVED-CALL-TRAP and no UNRESOLVED-CALL crossing is recorded in ag-cold-crossings.
Suspect the materializer Phase 2/4 baked macro index: stage2's in-process stdlib compile updates bodies for names already in the baked index but has no registration path for names absent from it.
Cost: this turned the #246 defsetf implementation into a multi-hour ghost hunt (three "failing" rewrites of a correct body). CLAUDE.md's "probe stdlib work against stage2" guidance is wrong for new macros — needs a caveat until fixed.
STILL TRUE (documented as the cave#251 CAVEAT in CLAUDE.md): stage2's runtime stdlib reload refreshes EXISTING prelude macro names only; a NEW defmacro in stdlib.lisp is silently dropped and its uses compile to undefined-function calls. Probe workflow stands: new prelude MACROS must be probed against build/funcl after make build. Fix shape: the reload path should intern/register macro names absent from the baked table, not just update matched ones.