DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-05-20

COMMENTERTHE9 — Mon, 15 Jun 2026 00:10:36 +0000

The JIT backend just saw its most significant leap forward with the latest commits hitting submain. We've locked in method-call lowering, tackled print argument widening, and fixed some key differential harness issues. This single day moved parity forward: from 99 PASS and 83 SKIP to 110 PASS with 72 SKIP, all without hitting any PARITY_FAILs across the board of 182 fixtures.

Method-call lowering: synthesis over duplication

We hit a big milestone with method-call lowering — a major code change landed that replaced our previous stub with full end-to-end functionality. The main decision was whether MethodCall should be treated as a standalone process duplicating existing Call logic or if it should leverage existing infrastructure. We opted for delegation: at lower.rs:1791, the MethodCall now converts the operation into a Call, using the receiver as the first argument, diving into existing logic rather than creating new pathways. This keeps method dispatch as a streamlined translation layer rather than a cumbersome parallel process.

With this update, our ingestion process now keeps alias parameters intact, registering methods with modified names ({Struct}${method}) in the signature table. Thanks to this, new test cases (t175/t176/t177) for basic implementation, return paths, and multi-alias methods passed seamlessly.

The same commit tackled literal-width narrowing. It highlighted how Numeric literals matched against typed peers in operations. Instead of a patchwork fix for MethodCall, the solution incorporated a comprehensive surface-level approach: aiding assert_eq peer narrowing, across comparative operators, and MethodCall arguments with the insert_cast_if_needed function. A dedicated fixture (t178) confirms this refinement: ordering comparisons on narrow integers now clear on all fronts. This commit improved parity by +16 PASS.

Print argument widening

One crucial gap was within our cx_printn runtime intrinsic, which was limited to I64. Enter route_print_arg: this new helper extends I8/I16/I32 to I64 through casting and guides Bool/TBool to a dedicated cx_print_bool external. Our approach targets distinct type families rather than one-size-fits-all — integers expand into cx_printn, booleans take their intrinsic path, and F64/I128 await attention post-version 0.1.

We saw immediate resonance in these updates: a +11 PASS jump with no steps back. Fixtures t01 and t115 succeeded at last, and bool outputs aligned with interpreter outcomes. Gaps still exist but aren't our intrinsic's fault — they rest with other structures downstream, like in t41 and t109.

Harness hardening

Our differential testing setup just got sturdier. Two fixes have shored up real vulnerabilities.

The first ripples into our process as it closes hard blocker H1. Previously, a non-JIT binary via standard cargo build would bypass all parity fixtures as SKIPs. Now, assert_jit_capable() assesses the binary at initialization, halting in 30ms if JIT support is absent. This correction erases a swath of misleading CI successes.

The second tackles H5 — a hiccup in metric consistency across four successive commits. Despite reporting 94/88, actual table values were 99/83. The solution? An AUTHORITATIVE TOTALS line using the same accumulators as the detailed table — ensuring cut-and-dry truth, avoiding manual errors.

0.1 readiness audit

Two audit commitments embedded per-item verification directly into the roadmap file using HTML comments. Reviewers can nod along with  or spot  marks as the scorecards apply. Verdict from these audits? We're not ready for 0.1. Despite conquering H1, H2, and H5 today, hurdles like H3 (when-block lowering) and H4 (feature-branch parity items CX-91/CX-94/CX-34) loom.

Interesting discovery: the Cast category's green status in parity reports isn't what it seems. Recent PASSes stem from narrowing touches, not a completed CX-91 Cast JIT implementation.

What's next

Crossing off three blockers — H1, H2, H5 — leaves us grappling with H3 and H4. The CX-233 while-in loop lowering branch is fully fleshed out, tested, yet still waiting in the wings to merge into submain for the third day. When-block lowering (H3) holds back three SKIP cases and is the last blocker squarely in our domain.

Meanwhile, the submain-to-main gap has ballooned to 179 commits, pegged as overdue in daily logs spanning two weeks. The rising cost of integration could soon outweigh remaining feature quests.

Our JIT parity sits at 110/182 (60.4%), but the SKIPs that remain are more from specific construct needs rather than missing fundamental blocks. While 0.1 readiness remains elusive, the path forward is not.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-05-20

Cx Dev Log — 2026-06-13

COMMENTERTHE9 — Sun, 14 Jun 2026 02:42:56 +0000

No commits landed today. No compiler work, no new features, no bug fixes. The only activity in the last 24 hours was automated: a site blog deploy and the June 12 daily log update. Both are housekeeping, not development.

That makes this a good moment to look at the state of the project and what's accumulating.

The submain gap

Submain sits 8 commits ahead of main. Those commits carry the CR#1-4 range-check sweep and the D1.0-D1.1 audit arc work. This gap has been open for at least three days now and continues to grow staler. Merging submain to main remains the single highest-leverage action available, and it keeps not happening.

The test matrix on main was last reported at 230/0. The current checkout (an older branch point on daily-log-2026-05-30) shows 172 PASS / 10 FAIL out of 182, but those 10 failures are CRLF line-ending artifacts where expected and actual output match in content but differ in endings. Not real failures.

Stalled example rewrites

Eight example files have been sitting modified in the working tree since May 23, over three weeks now:

hello.cx, fibonacci.cx, error_handling.cx, structs_and_methods.cx
generics.cx, tbool_uncertainty.cx, arrays_and_loops.cx, fizzbuzz.cx

The changes are substantial (+280 / -78 lines) and represent a pedagogical rewrite: block-comment documentation, renamed variables for clarity, restructured code flow. The fibonacci example swapped from recursive to iterative with a classify helper. The generics example switched from float pairs to string pairs to better show type-parameter flexibility.

This work is either ready to commit or should be dropped. Leaving it uncommitted in the working tree for three weeks means it's accumulating risk of being accidentally lost or becoming stale against other changes.

Growing PR backlog

Daily-log branches for June 5 through June 12 remain unmerged. That's eight branches sitting in the PR queue. None of these are controversial or risky merges. They're just waiting.

What didn't happen

The June 12 log predicted four things for today: merge submain to main, continue the D1 audit arc, merge the daily-log PR backlog, and resume backend expansion. None of those happened, making it two consecutive days of zero-for-four on predictions.

D1.2, which would gate JIT memory-safety, was identified on June 10 but has not started. The project is in a gap between the audit arc that opened on June 10 and whatever comes next.

Looking ahead

The path forward is straightforward even if today was idle. The submain merge is the most obvious step. The example file decision (commit or discard) should follow. The daily-log PR backlog is low-effort to clear. And once those are done, D1.2 or backend Phase 11 are the next real development targets.

Quiet days happen. The risk is when they stack up and the backlog compounds.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-06-13

Cx Dev Log — 2026-05-21

COMMENTERTHE9 — Sun, 14 Jun 2026 00:08:31 +0000

Cx Dev Log — Breaking Through the When-Block Hurdle

The introduction of when block IR lowering has marked a significant checkpoint for Cx, as seen in a 426-line commit to submain. This brings us closer to addressing hard blocker H3, an integral step for the 0.1 release. The JIT parity matrix saw an uplifting shift from 110 to 120 passing fixtures, thanks in part to resolving a compound-assign narrowing issue. Here's how it came together.

How `when` Lowering Works

We've integrated a chained-decision control flow graph (CFG) for when block lowering, aligning it with the strategy used for lower_logical in handling AND/OR short-circuit evaluation. The process for each when arm is as follows:

Patterns such as Literal, Range, and TBool-unknown trigger Compare instructions, followed by a Branch directing to the arm body or the next block.
Catchall arms execute a direct jump to their body.
Statement-style when blocks unify arm bodies using merge_fallthroughs.
Expression-style when blocks employ a typed block parameter for merging.

Why not go for table-dispatch or SSA phi-node based merges? There's a simple reason: these alternatives would necessitate additional IR infrastructure, useful only for the when functionality. By leveraging existing patterns, not only do we simplify, but we also ensure seamless integration with Cranelift's multi-way backend branching. For version 0.1, maximizing efficiency and reuse was the clear path forward.

TBool Unknown Matching

Handling the TBool unknown case required a workaround: comparing the scrutinee against ConstInt(I8, 2), employing Cast(I8 -> scrutinee.ty), then performing a Compare(Eq). This ingenious method skirts the IR validator's constraints without venturing into literal semantics for the TBool, an issue still tabled for future discussion. Presently, focusing on wire value-based pattern matching sets a solid foundation.

Challenges with EnumVariant Arms

EnumVariant arms remain a sticking point—better termed a deliberate limitation at this stage. The lowering process flags these as structured errors detailing the enum and variant. Until we tackle Enum IR lowering, fixtures such as t22, t27, and t28 will remain marked by the SKIP status. It’s a postponed target, slated for post-0.1 attention.

Compound-Assign Narrowing Etched Out

Another noteworthy update comes with commit e4c9202, a fix that rectifies a gap in the +=, *=, etc., compound-assign paths. Previously, these routes missed narrowing numeric literals against target types, causing IR-validator Verifier errors when handling narrow-int fields. By extracting the target type from all SemanticLValue variants and invoking insert_cast_if_needed for numeric interactions, we achieved a corrective balance. This alignment nudged tests like t41_compound_assign_dot and t109_struct_field_overflow from SKIP to PASS.

Hard Blocker Status and What Lies Ahead

We’ve made substantial headway, closing three hard blockers in two days:

H1: closed (May 20)
H2: closed (May 20)
H3: substantially addressed (May 21, Option A scope)
H5: closed (May 20)

H4 is the next frontier, encompassing features such as CX-91, CX-94, and CX-34 that are still pending. As we shift focus to the remaining 62 SKIP fixtures, tackling Enum IR lowering and other unaddressed constructs emerges as a priority. Immediate targets aren't crystal clear—each demands dissecting to diagnose specific barriers.

The task of evolving the submain-to-main merge looms large, as submain extends 181 commits beyond. This anticipated merge has been on the horizon since May 6, yet remains elusive. Today’s updates count as merely additional steps towards this pivotal integration.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-05-21

Cx Dev Log — 2026-05-22

COMMENTERTHE9 — Sat, 13 Jun 2026 00:09:02 +0000

v0.1.0 is tagged. PR #266 merged submain into main, bringing roughly 181 commits and 16,325 insertions across 109 changed files. The test matrix on main jumped from 117 to 182, all passing. The submain gap that had been growing since May 4 is now zero. This is the single largest integration event in the project's history so far.

What the merge brought

The v0.1.0 merge carried the entire backend pipeline onto main: Cranelift JIT, the differential test harness, host boundary, IR lowering through Phase 15. It also brought 65 new verification fixtures (t117 through t178), eight working examples, new backend documentation, CodeRabbit config, and CI expansion. All of this had been accumulating on submain since the last merge on May 4.

Six prep commits preceded the merge to get submain into release shape: semantic hardening, roadmap audits, dead-code cleanup, and doc reconciliation. The final readiness audit (be29a96) declared submain 0.1-READY, confirming all five H-series hard blockers closed. Full suite 411/0/0. JIT parity 120/62/0. The 62 remaining JIT SKIPs all map to acknowledged post-0.1 features (enums, generics, Handle, string interpolation, Result/?, WhileIn, t128/f64 print, full TBool unknown propagation).

Semantic analysis hardening

One of the pre-release prep commits deserves its own section. The method-call analysis path in src/frontend/semantic.rs got a substantial rewrite (075d3dc). Previously, unresolved method receivers would fall through to the IR layer's mangled-callee miss and produce unhelpful UnresolvedSemanticArtifact errors. Now the pipeline catches these earlier:

Receivers not in scope get a clear scope error.
Non-struct receivers are rejected with type information.
Undefined methods produce a method '{struct}.{method}' is not defined diagnostic.
Arity is enforced at analysis time, mirroring the free-function precedent.

The dead classify_type function was also removed. This is the kind of error-quality work that makes sense right before a release cut -- users hitting these paths should get actionable diagnostics, not IR-layer artifacts.

Build hygiene

The polish commit (23971f4) touched 17 files across src/, docs/, and docment/. It added #[allow(dead_code)] annotations on intentionally-retained items in ast.rs, resolver.rs, semantic_types.rs, types.rs, builder.rs, ir/types.rs, validate.rs, and runtime.rs. It fixed the clippy error in ir/printer.rs (the if i > 0 || true pattern) and removed dead re-exports from ir/mod.rs. Build warnings went from 20 to 0. Clippy errors went from 1 to 0.

README rewrite

The README was substantially rewritten from 67 lines of mixed prose and tables to 213 lines of structured documentation. It is now organized around: "Why Cx Exists," "What 0.1.0 Proves," "Current Verification Status," "What Works in 0.1.0," language core and memory model listings, interpreter and JIT sections, deferred post-0.1 items, and cleaner getting-started instructions. This is the project's first public-facing documentation update since reaching v0.1.0, and it signals a shift from build-phase framing to expand-phase framing.

Roadmap updates

Three roadmap commits landed on submain before the merge:

CX-91/94 marked as landed, CX-34 marked as canceled (scope superseded by later items).
A duplicate soft-blocker ID was renamed (S5 to S9).
The "Merged to submain (not yet on main)" section was retitled to "Landed (integrated to main via v0.1.0 merge)."
Frontend section updated: test count from 117/117 to 182/182, status from "release candidate" to "v0.1.0 released."

Phase 11 items "Method call actual lowering" and "when block lowering or structured rejection" are now checked off as delivered on main.

What's next

With v0.1.0 tagged, the immediate priority shifts from "get it out" to "expand coverage." The README frames near-term priorities as: stabilize 0.1.1, improve examples and documentation, expand JIT PASS coverage, and add missing runtime ABI extensions.

Concrete next moves: DotAccess in compound forms is the last unchecked Phase 11 sub-item. Enum IR lowering blocks EnumVariant when-arms and at least five parity fixtures. The 62 JIT SKIPs include fixtures blocked by narrow-int and f64 print formatting, which the README's deferred list explicitly names.

The submain merge that had been predicted on four consecutive daily logs finally happened. Now the real post-release work begins.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-05-22

Cx Dev Log — 2026-06-10

COMMENTERTHE9 — Thu, 11 Jun 2026 01:24:57 +0000

Four type-checking and optimization-focused commits hit Cx's submain, unexpectedly shifting focus towards the D1 audit arc. Instead of prioritizing previous CR range-check fixes or backend development, we took a hard left into soundness and structural improvements. The changes added 11 more matrix fixtures, bumping submain from 261 to 272 without a hitch.

Taming the JIT with Unseen Crash Classes

Kickstarting the D1 audit, five new verification fixtures (D1.0) were added to explore JIT crash behaviors, previously untested in the 261-fixture net. Here's a breakdown:

Division/Modulo by Zero: The usual exit 1 error in the interpreter caused hardware traps like SIGILL on JIT. These traps are locked down with .jit_known_unsound sidecars.
Edge Case in Overflow: t8 -128 / -1 (an interpreter wrap to -128) triggers overflow in JIT. t8 -128 % -1, though, skips the overflow, unexpectedly reaching arithmetic agreement.

Five fixtures later, these cases are now pinned down so any regressions can't sneak past unnoticed. Parity stayed healthy at 165 PASS / 101 SKIP / 0 FAIL, post D1.0.

Nailing a Performance Baseline

Can't improve what you can't measure, right? Before any heady changes, we nailed down a wall-time performance benchmark. Think arithmetic loops, recursive fibonacci, conditionals, and more. Eight programs ran through a PowerShell script doing 1 warmup and 7 real runs, taking medians and spreads.

Key insight: While raw instruction flow suggested even faster speeds, JIT was only 9-13x quicker when counting start-up and compile times, as short runs saw startup costs dominate. A procedural eye-opener arrived too: benchmarks spiked due to thermal throttling; hence, the baseline must now rest on within-session A/B comparisons.

The benchmarking exercise flagged a legitimate fault, directing our efforts to the subsequent commit.

Tweaking Array Index Element Types

The unexpected rises again: array indexing stumbled during benchmarking when acc + a:[k] on t8 arrays output incorrect values. Here’s the screw-up:

Expr::Index defaulted to SemanticType::Unknown regardless of actual array base types, tossing proper wrapping on integer arithmetic at sub-64-bit sizes.

The fix unfolded in semantic.rs, rewriting five lines to discern element type from Array(_, elem). Six new tests now define t8/t16 wrapping, typed binding narrowing, and return-value wrapping. This tweak let bench_array_loop drop previously necessary workarounds, aligning with expected natural form execution.

Final matrix post-fix: 272 fixtures, all stable across both backends.

Integrating Integer-Width Facts

The penultimate effort was extracting integer-width consistency from three hard-to-sync places: semantic.rs, runtime.rs, and lower.rs. Each worked off its own inline constants to determine value bounds, which was less than ideal.

Enter frontend/int_facts.rs, our new comprehensive data store. It introduces IntWidth (W8 through W128), IntFacts (inclusive of truncation mechanics), and a truncate(i128) method, ensuring a singular, central source that all modules are now tapping.

Design boons?

It stands alone — a data-only module untouched by other dependencies.
No unnecessary clutter, such as Bool inclusion, keeping it purely numeric.
Streamlined by skipped over a bits field given its lack of current utility.

Measured efficiency: 129 insertions and 26 deletions across seven files, no change in operational behavior, proving the integration seamlessly.

What's Next

The D1 arc’s evolution will naturally target memory safety for JIT, following today’s .jit_known_unsound reveals. Further unifying measures, akin to int_facts, likely loom ahead.

Currently, submain strides eight commits ahead of main, tracing the path for a coherent merge that boosts matrix integrity from 230 to 272. Yet, the daily-log PR backlog and backend development have seen deferral — though inevitable, they remain on the horizon as the D1 audit arc continues to unfold.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-06-10

Cx Dev Log — 2026-05-24

COMMENTERTHE9 — Wed, 10 Jun 2026 00:08:59 +0000

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:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-05-24

Cx Dev Log — 2026-05-25

COMMENTERTHE9 — Tue, 09 Jun 2026 00:09:39 +0000

The interpreter's variable lookup is now blazing through arithmetic loops at a 57% faster pace. But this isn't just about raw speed — four tracker items were checked off the list, culminating in a more robust system. All rolled out on submain, a direct result of a thorough four-pillar audit.

BindingId replaces string hashing at runtime

The heavyweight change came from tracker #009. Previously, our interpreter was busy hashing variable names every time they were accessed. That was a repeat offender in wasted cycles. Now, by using a pre-assigned numeric BindingId, we seize efficiency. The semantic phase was already handing out these IDs, but the runtime kept adding the overhead back. It doesn’t anymore.

ScopeFrame.vars has transitioned to a HashMap equipped with a zero-cost identity hasher keyed by u32 binding IDs. Name-based lookups are still around but tucked away for less frequent operations like string interpolation.

Fixes were necessary upstream: ConstDecl and semantic_impls now hold onto their BindingId, making sure our semantic phase pipelines gracefully into the interpreter's primary key system — narrowing the gap with JIT's variable handling.

Here's how the numbers shine on a Windows release build:

arith_loop (5M iterations): from 5744ms down to 2481ms (56.8% boost)
nested_loops (4M iterations): from 2675ms down to 1796ms (32.8% boost)
fib_recursive: from 6835ms down to 6488ms (merely 5.1% faster due to call-frame constraints)

Our findings align with expectations: recursive functions aren't bogged down by variable lookups as much as by setting up call frames.

Array bounds errors stop lying

Misleading diagnostic labels are on their way out, thanks to tracker #002 and #032. Attempts to access out-of-bounds array indices once triggered an error as unhelpful as variable 'index 5' has not been declared. Not anymore.

Changes came in two waves. First, we introduced a new error variant: RuntimeError::IndexOutOfBounds { pos, index, length }. Then, three runtime.rs cases were refactored to employ this newfound precision. Now, programs react with clarity, showing array index N out of bounds for array of length M.

New fixtures have been added to validate this behavior and to handle discrepancies with the JIT through a .jit_known_unsound sidecar. This move optimally separates interpreter improvements from JIT limitations, acknowledging that our current JIT doesn’t yet include bounds checks (tracker #003).

Builtin registry

Though tracker #008 tackled a narrower terrain, its ripples will be felt across the project. By consolidating all of the site-dependent lists for Cx builtins in src/frontend/builtins.rs, we ended the structural divergence that was starting to creep in. Future integrations are now a single-source update, negating the chance for list drift.

This tidy up is directly tackling findings from the audit's Pillar 2 concerns. Where once four lists zigged separately, now they zag together.

Deliberate sequencing

Our line of commits didn't happen by chance. Tracker #012 initiated the new error variant, leading to #002/#032 fixing use-sites, and deploying a JIT exclusion practice. Tracker #008 cleared the path by resolving the builtin conundrum, before tracker #009 flexed the freshly implemented BindingId advantages.

Each stage acted on precise dependencies with grounded purpose and references back to their origins in the audit pillars.

What is next

We’re setting our sights on the lazy arena (tracker #010) identified in #009’s commit log. The 64KB memset seen in function calls sticks out like a sore thumb in call-heavy operations, hogging 90% of runtime. The solution is clear-cut and well within scope.

After a successful deployment of these fixes, merging submain to main comes naturally. With submain miles ahead by seven commits and improvements across performance and correctness, attention can shift to JIT’s array bounds safeguard (tracker #003), leveraging the existing jit_known_unsound mechanism to master this transition.

Main remains unchanged with a clean slate of 182/0, while today’s improvements have all bolstered the growth of submain.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-05-25

Cx Dev Log — 2026-05-26

COMMENTERTHE9 — Mon, 08 Jun 2026 00:08:51 +0000

Stuck without a single developer-authored commit landing today, while submain sits 7 commits ahead of main, full of crucial work waiting to merge. The backlog's growing increasingly hard to ignore.

Submain is sitting on real work

Submain's ahead, and it's not just sitting there with trivial updates. We've got 7 commits affecting 47 files: a whopping +1061/-331 lines. Inside? Real changes like:

Tracker #001: Tackling composite literal type-checking.
Tracker #002 / #012 / #032: Nailing down IndexOutOfBounds diagnostics.
Tracker #008: The Builtin registry.
Tracker #009: A killer 57% speedup on arithmetic loops using BindingId-indexed variables.
Implementation of the exit() builtin.

Yet, none of this has hit main. No merge conflicts are lurking ― submain was last synced with main on May 24 through PR #282. Each daily log promises a merge from submain to main since May 6, and every promise has fizzled out.

The daily-log branch backlog

The issue is bigger than just submain. The daily-log branches are stacking up too. The last time main saw a daily-log merge was back on 2026-05-09. Branches from 05-24 and 05-25 are just gathering dust. They’ve got crucial roadmap updates and project history waiting in the wings.

Right now, main’s roadmap still reads "0.1 release candidate" with a 117/117 matrix. Reality check: we're at v0.1.0 with 182 tests passing. Daily-log branches know this, but without merging, it's nowhere on the main branch.

Nothing in progress

Main’s working tree is clean. No files in limbo or half-baked changes. It’s not that the work’s just somewhere else. It’s a genuine pause.

What is likely next

The crystal ball looks a lot like yesterday's prediction: submain needs to merge into main. That’s the most impactful move we've got. Following that, merging daily-log branches would pull the documentation up to date. Work branching off from the May 24-25 tracker sprint is all about either optimizing lazy arenas (tracker #010, targeting that annoying 64KB memset bottleneck) or tightening JIT array bounds (tracker #003, nailing the jit_known_unsound issues).

Whether any of this unfolds tomorrow remains to be seen. But the work's definitely there, waiting for the green light.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-05-26

Cx Dev Log — 2026-06-06

COMMENTERTHE9 — Sun, 07 Jun 2026 00:10:43 +0000

The v0.2.0 merge landed. PR #295 brought 35 commits from submain into main, touching 145 files (+4130/-2052) and jumping the verification matrix from 182 to 230 fixtures. Within hours, three targeted range-check fixes found during review pushed submain to 252. No regressions, no reverts.

What shipped in v0.2.0

This release closes a month of divergence between main and submain. The highlights:

String concatenation and the len builtin
if as an expression (not just a statement)
Enum signatures in function declarations
TBool safety and unknown-as-value rejection
exit() builtin
Composite literal type-checking
The differential harness for interpreter/JIT parity testing
Runtime refactoring: the monolithic 1725-line runtime.rs was split into six modules (exec, eval, call, ops, scope, print)

The runtime split is a pure structural refactor with no behavior change, but it sets up the module boundaries for future work on the runtime.

48 new verification matrix fixtures came along with all of this. Main went from 182 to 230 passing tests, zero failures.

Three range-check fixes in one afternoon

The original out-of-range literal rejection rule (#028/#037) was established early: if you write x: t8 = 300, the compiler should reject it at semantic analysis time, not silently truncate. That rule worked for standalone declarations, but CodeRabbit caught three surfaces where it didn't apply.

CR#1: Generic struct fields. Writing Pair<t8> { b: 300 } silently accepted 300. The problem: explicit generic type arguments were being discarded. The _type_args in the StructInstance arm of semantic.rs were unused, so field literals validated against raw TypeParam("T"), making the range check a no-op. The fix builds a positional param-to-arg substitution map and applies it to each field's declared type before range-checking. Six new fixtures. Matrix: 236/0.

CR#2: Array elements in struct fields and call arguments. items: [3: t8] initialized with [1, 2, 300] inside a struct silently accepted the out-of-range element, even though standalone x: [3: t8] = [1, 2, 300] correctly rejected it. The element-type hint was never propagated at those sites. A new analyze_expr_with_elem_hint helper in semantic.rs delivers the hint at struct-field and call-argument sites, consolidating the typed-declaration path. This composes with CR#1, so Box<t8> { items: [3: T] } now resolves to [3: t8] and range-checks every element. Eight new fixtures. Matrix: 244/0.

This fix also surfaced a pre-existing Cranelift codegen bug: storing a negative value in a struct's fixed-size array field corrupts adjacent stack memory on teardown. Positive arrays work fine. The interpreter handles it correctly. Marked .jit_known_unsound for now.

CR#3: Return values. fnc: t8 f() { 300 } silently returned 44 (300 mod 256). The trailing-return path went straight to insert_cast_if_needed, which wraps without checking. This is the worst class of bug: silent wrong values. The fix introduces an analyze_returned_expr chokepoint in semantic.rs that runs the same sequence a typed declaration runs (array-element hint, bare-literal width check, type-compatibility gate, then cast) and both return forms (explicit return expr and trailing expression) route through it. Eight new fixtures. Matrix: 252/0.

All three fixes are on submain only, not yet merged to main. Submain is 3 commits and 59 files ahead.

The rule is now closed across five surfaces

After CR#1-3, out-of-range literal rejection applies to: standalone declarations, explicit generic type arguments, array elements in struct fields and call arguments, and both return positions. The only identified remaining gap is literals nested inside if/when branches ({ if c { 300 } else { 0 } }), tracked as CR#4.

One thing deliberately left alone: implicit non-literal narrowing. Writing x: t8 = a where a: t64 still compiles. Cx has no explicit cast syntax yet, so rejecting this would strand legitimate truncation with no escape hatch. The plan is to add cast syntax first, then tighten the rule.

What's next

The immediate priority is merging CR#1-3 from submain to main. It's only 3 commits and should be a clean merge.

After that, CR#4 (range-checking inside if/when branches) is the natural next step to complete the sweep. The Cranelift negative-element segfault that CR#2 exposed is worth investigating but sits in the JIT codegen layer rather than the semantic analysis layer where the current work is happening.

The larger remaining frontier is Phase 8 Round 2 and Phase 15: str/strref layout, Handle, TBool calling convention, and closing the remaining JIT instruction coverage gaps. v0.2.0 cleared the integration backlog. Now the path forward is backend work.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-06-06

Cx Dev Log — 2026-05-27

COMMENTERTHE9 — Sat, 06 Jun 2026 00:10:37 +0000

Three quiet days without any developer-authored commits. That's where we stand, with no changes to main since May 22 when the Type::Void variant merged in PR #278. Meanwhile, submain sits seven commits ahead, echoing the unmerged work from the recent tracker sprint. The passing matrix at 182 and zero failures is a testament to recent progress. But while it may seem like a standstill, the project is poised for a leap forward as integration nears.

Roadmap corrections

There's been a backlog of housekeeping, affecting our roadmap's clarity. Stuck on a May 9 version, it wrongly labeled the frontend as a "0.1 release candidate" and maintained an outdated "117/117" test pass count, despite 182 tests now passing. Today's log addresses these discrepancies. Key overlooked items in Phase 11 had already made their way to main yet remained unchecked:

Method call lowering (0ab7e9b): Executes literal-width narrowing for method calls on implementation types.
when block lowering (bed71c1): Handles Literal, Range, Bool, and Catchall arms alongside TBool wire-value unknowns.
DotAccess in compound forms (2d6804a): Enables compound assignments through dot-access paths, validated by the CX-187 parity fixtures.

These entries, committed weeks ago, highlight the pitfalls of maintaining documentation external to code changes. Delaying integration to main has hidden completion, but the overview now reflects the present state.

A growing submain backlog

Submain harbors seven pivotal commits from the May 24-25 sprint:

Tracker #001: Composite literal type-checking
Tracker #002 / #032: Improved IndexOutOfBounds diagnostics
Tracker #008: Builtin registry implementations
Tracker #009: Transition to BindingId-indexed variables; results in a substantial 57% speedup on arithmetic loops
Tracker #012: Introduction of the exit() builtin, as first discussed in the May 23 log

With no anticipated merge conflicts—submain already aligned with main via PR #282—the merge is strategic. An action expected for days, pending outcomes and persistent in daily logs since May 6.

The log branch tangle

We've accumulated seven daily-log branches (May 20 through May 26), each carrying roadmap updates and notes. The last log branch to merge was way back on May 9. Corrections in today's log address most of the lingering matters in these intermediate branches. Still, they need merging or closing to alleviate any branch clutter.

On the horizon

The focus remains firmly on these essential tasks:

Merge submain into main. This will incorporate critical structural improvements, performance refactors, and necessary fixes from our last sprint. A clean and essential step.
Deal with the daily-log branch backlog. With seven pending branches, tidying up is non-negotiable. Effective branch hygiene is critical, even if corrections lessen the pressure.
Next issues: Lazy arena (tracker #010) or JIT bounds checking (tracker #003). Deciding which to tackle will follow naturally. The former addresses a 64KB memset limit; the latter closes the jit_known_unsound gap.

The truth is, post-May 25, we've hit a productivity pause. The groundwork exists; we just need to anchor it into place.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-05-27

Cx Dev Log — 2026-03-29

COMMENTERTHE9 — Wed, 03 Jun 2026 00:12:20 +0000

Some days nothing ships. March 29 was one of those days when no new COMMENTERTHE9-authored commits landed, the working tree was spotless, and our test matrix held strong at 78/78 on main. But don't mistake this quiet for inactivity. Two key backend changes are stacked on submain, just waiting for their moment. It begs the question, why hasn't submain been merged yet?

The submain backlog

Right now, submain holds onto two locally branch-locked commits from March 28:

Wrapping arithmetic (d93582b) changes our runtime arithmetic methods from saturating_add/saturating_sub to wrapping_add/wrapping_sub in src/runtime/runtime.rs. It incorporates guards for critical edge cases like i128::MIN / -1 and i128::MIN % -1. While our arithmetic now wraps correctly at the i128 limit, this update is just a step towards fully enforcing integer overflow behavior—a hard blocker still looming.

Phase 10: while loop lowering (0fa06a6) adds a hefty 189 lines to src/ir/lower.rs. This update implements a header/body/exit CFG pattern, loop-carried SSA with block parameters, and introduces backedge generation. Right now, there are three tests supporting this Rust implementation. Notably, this is the debut of backend IR loop support in Cx.

Both commits represent solid progress but they already shipped on March 28, as noted in that day's log. Yet, for two days running, the merge to main remains in limbo. A snag: docs/frontend/ROADMAP.md is out of sync between branches. Main field's roadmap stands at v4.7, while submain's is at v4.6, dropping some annotations. Tackling this roadmap divergence will require a careful conflict resolution during the merge.

Roadmap v4.8

Version 4.8 of the roadmap brings a measured update:

"Backend ABI / Data Layout" now captures Phase 8's structured layouts for structs, arrays, and enums, and formally records the locking of calling conventions on submain. Phase 10's while loop lowering is flagged as active backend work.
"Multi-file imports" got a tick with the merging of PR #27 to main.
The "Integer overflow" known gap entry was adjusted to note the partial fix with wrapping arithmetic.
We confirmed struct field type checking and method call return type fixes on main post-PR #27.

Yet, no boxes were checked off. The wrapping arithmetic moves us closer to resolving the integer overflow blocker but hasn’t fully tackled it.

What is next

The list of upcoming tasks hasn't budged:

Merge submain to main. A merge is overdue by two days, complicated slightly by roadmap version divergence but not blocked.
If/else lowering in the backend. With IR lowerer now supporting while loops, the next logical step is handling conditional branches. This is crucial for supporting Cx 0.1-level programs.
Test runner and assert. A hard blocker, currently hitting day five of deferral.
Error model (Result). Another five-day deferral, another hard blocker.

Here’s the truth: March 29 wasn’t about breakthroughs. Our significant changes are parked on a branch, awaiting the merge. The blockers are still there, sitting quietly in the backlog. True advancement is on hold until we finalize the submain merge and move on to pick up if/else lowering or clear one of the deferred blockers.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-03-29

Cx Dev Log — 2026-04-08

COMMENTERTHE9 — Tue, 02 Jun 2026 00:12:38 +0000

Thirteen days and counting. That’s how long our submain branch has been sitting without a merge into main. We've got five solid commits tested and ready, yet they continue to loom over our work on Cx — haunting our 0.1 milestone with their unmerged status. It’s frustrating. It’s blocking. And it’s the heart of the current situation.

The Submain Standoffs

Let's break down why this merge gap is such a big deal. Those commits aren’t window-dressing. They tie up four hard blockers that are crucial for the 0.1 release. For instance, the move from saturating to wrapping arithmetic doesn’t just tick a box — it handles those tricky i128::MIN edge cases that could catch developers off guard. Then there's the Phase 10 while loop lowering, shifting to a cleaner CFG pattern with support for loop-carried SSA and backedge insertion. We’ve locked down our UTF-8 decision, ensuring consistency across the board with no Latin-1 fallback, and finally, our semicolon rule is established — optional except where it helps in expression statements for clarity. Add to that a basic test runner packing assert, assert_eq, and a neat --test mode, and it’s clear that these merged bits represent a meaningful slice of progress.

A quick glance at the diff between main and submain shows substantial activity — 24 files modified, 367 insertions, and 501 deletions across critical components like main.rs, runtime.rs, and the spec itself (cx_syntax.md). These aren’t superficial updates. They are pivotal changes dragging their feet in the review queue.

Branch Backlog Buildup

Our woes don’t stop with submain. We’ve also got eight daily-log branches hanging around, starting with daily-log-2026-03-29 through daily-log-2026-04-07. While these don’t carry the same weight as the five on submain, they do clutter our workflow. Some contain roadmap updates alongside daily changes, and the longer we let them accumulate, the more we risk avoidable conflicts when they’re finally addressed.

Stuck Roadmap

Our trusty roadmap still reflects main accurately, which is both strategic and necessary. It’s a balancing act — representing the truth of what’s merged against the aspirations of what’s ready but pending. Items like the test runner, integer overflow handling, and semicolon integration aren’t checked off because, well, they’re not on main yet. The roadmap makes a small nod to the decided UTF-8 direction despite its yet-to-be-merged status on submain. Prematurely marking these as complete would only add to the confusion.

What Needs to Happen

The path forward is clear, even if it seems like groundhog day admitting it again. Merge submain into main. Those five commits, resolving four blockers, are primed and should be the immediate focus. No apparent source conflicts should impede this, apart from an expected nudge needed in the roadmap file.

Once submain sees the light of main, we need to address the next high-impact blocker — the error model implementation, with Result, Ok, Err, and the ? operator framework laid out in the spec. There's also the daunting yet essential task of tackling the := type inference quality gate, which has yet to kick off.

Today might feel static without new landings, but beneath the surface, the code is waiting, complete, and eager to push us forward if we can just make the merge.

Follow the Cx language project:

Website: cx-lang.com
GitHub: github.com/COMMENTERTHE9/Cx_lang
Dev.to: dev.to/commenterthe9
Bluesky: thecomment.bsky.social
Twitter/X: @commenterthe9

Originally published at https://cx-lang.com/blog/2026-04-08

DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-05-20

Method-call lowering: synthesis over duplication

Print argument widening

Harness hardening

0.1 readiness audit

What's next

Cx Dev Log — 2026-06-13

The submain gap

Stalled example rewrites

Growing PR backlog

What didn't happen

Looking ahead

Cx Dev Log — 2026-05-21

How when Lowering Works

TBool Unknown Matching

Challenges with EnumVariant Arms

Compound-Assign Narrowing Etched Out

Hard Blocker Status and What Lies Ahead

Cx Dev Log — 2026-05-22

What the merge brought

Semantic analysis hardening

Build hygiene

README rewrite

Roadmap updates

What's next

Cx Dev Log — 2026-06-10

Taming the JIT with Unseen Crash Classes

Nailing a Performance Baseline

Tweaking Array Index Element Types

Integrating Integer-Width Facts

What's Next

Cx Dev Log — 2026-05-24

Composite Literal Type-Checking

The Four-Pillar Deep-Dive

Pillar 1: Performance Analysis

Pillar 2: Correctness Differential Audit

Pillar 3: Architectural Risks

Pillar 4: Developer Experience Hurdles

The Structural Culprit

What the Audit Doesn’t Decide

What’s the Next Step?

Cx Dev Log — 2026-05-25

BindingId replaces string hashing at runtime

Array bounds errors stop lying

Builtin registry

Deliberate sequencing

What is next

Cx Dev Log — 2026-05-26

Submain is sitting on real work

The daily-log branch backlog

Nothing in progress

What is likely next

Cx Dev Log — 2026-06-06

What shipped in v0.2.0

Three range-check fixes in one afternoon

The rule is now closed across five surfaces

What's next

Cx Dev Log — 2026-05-27

Roadmap corrections

A growing submain backlog

The log branch tangle

On the horizon

Cx Dev Log — 2026-03-29

The submain backlog

Roadmap v4.8

What is next

Cx Dev Log — 2026-04-08

The Submain Standoffs

Branch Backlog Buildup

Stuck Roadmap

What Needs to Happen

How `when` Lowering Works