Cx Dev Log — 2026-05-24

#cx #programming

Composite literal type-checking just closed the final soundness gap in the Cx language interpreter. Our four-pillar audit? It laid the groundwork for what's next in version 0.2. Two development themes took center stage: tackling a targeted fix and diving deep into a broadened codebase audit. While initially distinct, these efforts uncovered shared threads.

Composite Literal Type-Checking

We discovered a crucial loophole in our semantic analyzer—it checked for struct names and array lengths without verifying the contents. Structs with incorrect field types, missing fields, or extras? They compiled, only to produce incorrect output. Similarly, array literals managed to slip through with mixed element types. This was flagged as our highest-priority finding during the Pillar 2 correctness audit, and we resolved it the same day.

The fix was precise: about 54 lines added to src/frontend/semantic.rs under commit 8169d33 on submain. Struct literals now ensure all fields are declared, reject unknown fields, and type-check each one. The generics are resolved during this process. Array literals go through their own rigorous check to confirm element type consistency.

To cement these changes, four verification matrix fixtures tested the updated behavior: t_composite_array_element_type.cx, t_composite_struct_missing_field.cx, t_composite_struct_unknown_field.cx, and t_composite_struct_wrong_type.cx. With these in place, the soundness gap is officially closed. The matrix remains unbroken at 182/0 on main.

The Four-Pillar Deep-Dive

Our day extended into a methodical four-pillar audit of the 0.1 codebase, unfolding across dedicated branches to explore various facets and inform the 0.2 roadmap.

Pillar 1: Performance Analysis

We uncovered two performance bottlenecks: a heavy reliance on memset from per-call 64KB arena zeroing dominated call-heavy programs, and SipHash string hashing burdened loop-heavy ones. Arena zeroing can shift to lazy initialization to mitigate the memset impact. For SipHash, the solution lies in leveraging the already computed BindingId, eliminating runtime re-hashing.

Pillar 2: Correctness Differential Audit

A thorough interpreter-vs-JIT analysis exposed 14 key issues, 13 of which were JIT-only slips like out-of-bounds access and division by zero. Not distinct bugs, but symptoms pointing to a larger issue—a missing abstraction.

Pillar 3: Architectural Risks

A layered review highlighted five risks by delay cost. The absence of a shared semantic core between interpreter and JIT was the major revelation, leaving both engines executing validation and error handling separately. Issues like builtin duplication and extended runtime.rs files confirmed these architectural gaps.

Pillar 4: Developer Experience Hurdles

We identified friction points through test programs. Parse errors, limited enum support, lack of string manipulation tools, and raw token names in errors topped the list. Quick improvements are clear pathways to a significantly smoother developer experience.

The Structural Culprit

The synthesis document brought everything together. Pillar 1’s SipHash problem, the 13 interpreter/JIT disagreements from Pillar 2, Pillar 3’s concerns about builtins, and arena zeroing all traced back to shared structural roots. Correcting these inefficiencies promises to dissolve many surface-level issues.

What the Audit Doesn’t Decide

Our audit defers the hefty question of committing to a unified semantic core for interpreter and JIT. Except for essential tasks like lazy arena allocation and parse error improvements tagged for immediate action, everything awaits the team's verdict following the synthesis review.

What’s the Next Step?

The composite literal fix is primed for a main branch PR, with four new fixtures in tow. The pending merge of the exit() builtin also awaits. Focus should now shift to implementing low-effort, high-impact improvements like let x = expr. But crafting the roadmap for version 0.2 lies in the team's hands. Will we prioritize structural betterment or proceed incrementally with new features? This is the decision on the horizon.

Follow the Cx language project: