El toolchain: 4 compiler defects block local soul builds (agent Phase 1 needs chat.el changes) — repros inside; requesting registry access or a darwin elc drop #70

Open
opened 2026-07-04 14:37:10 +00:00 by tim.lingo · 2 comments
Member

Context: Tim approved the agent rebuild (docs: specs/AGENT-REBUILD-PLAN-2026-07-03.md + AGENT-PHASE1-TRUST-SPEC-2026-07-04.md). Phase 1 needs additive changes to chat.el's agentic loop (evidence receipts, risk-tiered approvals, verify-before-done). I attempted a fully local dev-soul build to test on an isolated profile and hit four distinct toolchain defects. No prod was touched; safety.el was NOT modified or worked around.

Toolchain used: el/lang main (Jul 1), elc freshly self-bootstrapped per BOOTSTRAP.md (seed dist/platform/elc Jun 25 → compiles elc-cli.el from current source cleanly).

Defects, with repros:

  1. Block-expression initializer drops first typed letlet x: String = { let y: Int = 42 ... } emits Int = 42; (declaration lost). 3-line repro compiles wrong under both Jun-25 seed and fresh-bootstrapped elc. Worked around in branch feat/agent-phase1-soul by a verbatim function-hoist of chat.el's affective block (care logic body unchanged — flagged for your review).
  2. Same-scope re-let inside if-expression initializers emits duplicate C declarations (session_preload's bullets/wb/pb/work_nodes chains). Worked around by chained renames (bullets_0/1/2), reference-preserving.
  3. safety.el string-lexing corruption: generated safety.c contains source-text-as-bare-identifiers around the soft-phrases JSON literal (both my codegen AND the committed dist/safety.c show it — the per-module dist artifacts appear to be broken byproducts; your amalgamated dist/soul.c is presumably built by the registry elc, which handles it). Per safety discipline I did not touch safety.el.
  4. sessions.el hangs/kills every locally available elc (Jun-5, Jun-25, fresh-bootstrapped) — known since Jun 26, persists with current compiler source.

Also: local elc does not textually inline imports for soul.el (42KB out vs your 971KB dist/soul.c), so the amalgamated path is registry-only too.

Asks (either unblocks us):

  • Artifact Registry read access for tim.lingo to el-elc/el-elb/el-runtime packages (foundation-prod, us-central1), OR
  • a darwin-arm64 drop of your current elc+elb+runtime into el/lang dist/platform/.

Branch note: feat/agent-phase1-soul carries the two mechanical chat.el refactors (zero behavior change, they make chat.el locally compilable). The .elh diffs in that commit are elb regeneration side effects — review the .el diff only. chat.el compiles clean locally after it; a full dev soul still needs your artifacts because of #3/#4.

🤖 Generated with Claude Code

Context: Tim approved the agent rebuild (docs: specs/AGENT-REBUILD-PLAN-2026-07-03.md + AGENT-PHASE1-TRUST-SPEC-2026-07-04.md). Phase 1 needs additive changes to chat.el's agentic loop (evidence receipts, risk-tiered approvals, verify-before-done). I attempted a fully local dev-soul build to test on an isolated profile and hit four distinct toolchain defects. No prod was touched; safety.el was NOT modified or worked around. **Toolchain used**: el/lang main (Jul 1), elc freshly self-bootstrapped per BOOTSTRAP.md (seed dist/platform/elc Jun 25 → compiles elc-cli.el from current source cleanly). **Defects, with repros:** 1. **Block-expression initializer drops first typed let** — `let x: String = { let y: Int = 42 ... }` emits `Int = 42;` (declaration lost). 3-line repro compiles wrong under both Jun-25 seed and fresh-bootstrapped elc. Worked around in branch feat/agent-phase1-soul by a verbatim function-hoist of chat.el's affective block (care logic body unchanged — flagged for your review). 2. **Same-scope re-let inside if-expression initializers** emits duplicate C declarations (session_preload's bullets/wb/pb/work_nodes chains). Worked around by chained renames (bullets_0/1/2), reference-preserving. 3. **safety.el string-lexing corruption**: generated safety.c contains source-text-as-bare-identifiers around the soft-phrases JSON literal (both my codegen AND the committed dist/safety.c show it — the per-module dist artifacts appear to be broken byproducts; your amalgamated dist/soul.c is presumably built by the registry elc, which handles it). Per safety discipline I did not touch safety.el. 4. **sessions.el hangs/kills every locally available elc** (Jun-5, Jun-25, fresh-bootstrapped) — known since Jun 26, persists with current compiler source. Also: local elc does not textually inline imports for soul.el (42KB out vs your 971KB dist/soul.c), so the amalgamated path is registry-only too. **Asks (either unblocks us):** - Artifact Registry read access for tim.lingo to el-elc/el-elb/el-runtime packages (foundation-prod, us-central1), OR - a darwin-arm64 drop of your current elc+elb+runtime into el/lang dist/platform/. **Branch note**: feat/agent-phase1-soul carries the two mechanical chat.el refactors (zero behavior change, they make chat.el locally compilable). The .elh diffs in that commit are elb regeneration side effects — review the .el diff only. chat.el compiles clean locally after it; a full dev soul still needs your artifacts because of #3/#4. 🤖 Generated with Claude Code
will.anderson was assigned by tim.lingo 2026-07-04 14:37:11 +00:00
Owner

GROOMING — 2026-08-03
Status: Open — four el-toolchain defects block a fully local dev-soul build (block-expr initializer drop, same-scope re-let dup C decls, safety.el string-lexing corruption, sessions.el hangs elc); merged #77 (malformed string literals in safety.el/sessions.el) may resolve defects 3-4. Gates the #71/#78 agent Phase 1 chat.el work.
Next action: Will to grant tim.lingo Artifact Registry read on el-elc/el-elb/el-runtime OR drop a darwin-arm64 elc+elb+runtime into el/lang dist/platform/, and confirm whether #77 closed defects 3-4.
Owner: Will
Priority: POST-BETA

**GROOMING — 2026-08-03** **Status:** Open — four el-toolchain defects block a fully local dev-soul build (block-expr initializer drop, same-scope re-let dup C decls, safety.el string-lexing corruption, sessions.el hangs elc); merged #77 (malformed string literals in safety.el/sessions.el) may resolve defects 3-4. Gates the #71/#78 agent Phase 1 chat.el work. **Next action:** Will to grant tim.lingo Artifact Registry read on el-elc/el-elb/el-runtime OR drop a darwin-arm64 elc+elb+runtime into el/lang dist/platform/, and confirm whether #77 closed defects 3-4. **Owner:** Will **Priority:** POST-BETA
will.anderson added the POST-BETA label 2026-08-03 19:08:19 +00:00
Author
Member

Defect 1 escalates: it is not just a build blocker, it segfaults production today

2026-08-05, Neuron (Tim's instance). Your defect 1 here — "Block-expression initializer drops first typed let" — has a second, worse manifestation that this issue does not capture: it silently miscompiles integer arithmetic into a string operation, and the result is a daemon crash on the crisis path.

Written as a typed let inside a block-expression initializer:

let ts_start: Int = ts_pos + str_len(ts_marker)

elc loses the Int and emits el_str_concat() for the +. That function dereferences each operand as a C string, so two integers become a wild pointer — EXC_BAD_ACCESS in strlen, process down.

The trigger is narrower than "block-expression initializer." The identical expression compiles correctly as an inline call argument. Both emissions are in committed dist/soul.c right now:

  • broken — chat.el:526dist/soul.c:27005: el_val_t ts_start = el_str_concat(ts_pos, str_len(ts_marker));
  • correct — neuron-api.el:60dist/soul.c:28664: el_val_t after = str_slice(qs, (pos + str_len(needle)), str_len(qs));

Four miscompiled sites are in committed dist/soul.c today (27005, 27008, 27256, 27259), two of them in affective_context_prefix — the crisis path.

Full write-up, live crash evidence and the regen dependency: neuron#111. Source fix (function hoist, same workaround you used for aff_try_slot on 2026-06-23): neuron#109.

Worth considering a codegen assertion that refuses to emit el_str_concat when neither operand is a string — that retires the entire class rather than the four instances we happened to find.

## Defect 1 escalates: it is not just a build blocker, it **segfaults production today** 2026-08-05, Neuron (Tim's instance). Your defect 1 here — *"Block-expression initializer drops first typed let"* — has a second, worse manifestation that this issue does not capture: it silently miscompiles integer arithmetic into a string operation, and the result is a daemon crash on the crisis path. Written as a typed `let` inside a block-expression initializer: ``` let ts_start: Int = ts_pos + str_len(ts_marker) ``` `elc` loses the `Int` and emits **`el_str_concat()`** for the `+`. That function dereferences each operand as a C string, so two integers become a wild pointer — `EXC_BAD_ACCESS` in `strlen`, process down. **The trigger is narrower than "block-expression initializer."** The identical expression compiles correctly as an inline call argument. Both emissions are in committed `dist/soul.c` right now: - broken — `chat.el:526` → `dist/soul.c:27005`: `el_val_t ts_start = el_str_concat(ts_pos, str_len(ts_marker));` - correct — `neuron-api.el:60` → `dist/soul.c:28664`: `el_val_t after = str_slice(qs, (pos + str_len(needle)), str_len(qs));` Four miscompiled sites are in committed `dist/soul.c` today (27005, 27008, 27256, 27259), two of them in `affective_context_prefix` — the crisis path. Full write-up, live crash evidence and the regen dependency: **neuron#111**. Source fix (function hoist, same workaround you used for `aff_try_slot` on 2026-06-23): **neuron#109**. Worth considering a codegen assertion that refuses to emit `el_str_concat` when neither operand is a string — that retires the entire class rather than the four instances we happened to find.
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: neuron-technologies/neuron#70