DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-04-23

COMMENTERTHE9 — Tue, 26 May 2026 00:04:21 +0000

No code landed today. That makes five consecutive days without a developer-authored commit on any branch. The test matrix on main sits at 78/78, unchanged. The working tree is clean. On the surface, the project looks stalled. But the real story is about the gap between where the work actually is and where it is visible.

The submain integration gap

The submain branch is carrying 15 unmerged commits. The last human commit there, eb65acf, is a parser/semantic/interpreter audit (Part 1) plus a parser body-gap fix, now 10 days old. That branch contains real feature work that would move the project forward significantly if merged:

Result error model with Ok, Err, and the ? operator
Integer overflow enforcement
Semicolons made optional
A diagnostics pass
Parser audit Part 1
Phase 10 control flow lowering (while, for, loop/break/continue)
A basic test runner

Several of these directly satisfy hard blockers on the roadmap. On main, those roadmap items remain unchecked because the code hasn't been merged. As of the 2026-04-18 log, uncommitted audit Part 2 work in a submain working tree context had reportedly pushed the test matrix to 116/116, with a recursive type parser refactor, struct field type resolution, a 64 MB interpreter thread stack increase, struct field truncation fixes, 6 new matrix tests, and 8 new example programs. Whether that uncommitted work still exists is unknown from the main checkout.

This is the single highest-leverage bottleneck right now. One merge would jump the matrix from 78 to potentially 116+ tests, check off multiple hard blockers, and unblock the final audit and 0.1 gate work.

Branch clutter

Twenty-two daily-log branches (2026-03-29 through 2026-04-22) sit on the remote without being merged to main. The last daily log that actually reached main was 2026-03-31. It is operational noise, but it keeps growing by one branch per day.

Roadmap state

The roadmap on main is at v4.8 (docs/frontend/ROADMAP.md). The unchecked hard blockers include: basic test runner, minimal error model, integer overflow enforcement, consistent semicolon rules, parser/semantic/interpreter agreement, no soundness holes in the memory boundary model, all examples passing, readable diagnostics, and roadmap/spec alignment with actual behavior. Submain has commits that would partially or fully satisfy at least five of those items.

There is also a version discrepancy: submain carries roadmap v4.7 while main has v4.8. That will need reconciliation during or after the merge.

What's next

The same five items predicted across the last five logs, none of which happened today:

Commit the audit Part 2 sprint on submain
Merge submain into main
Update the roadmap post-merge
Broader audit Part 2 coverage
IR lowering for Result

The merge remains the critical path item. Until it happens, main stays frozen and the roadmap stays blocked. If the uncommitted audit Part 2 work exists in a local working tree somewhere, committing it before it gets lost should be a priority.

Five idle days in a row. The work exists, it just hasn't moved to where it counts.

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-23

Cx Dev Log — 2026-04-24

COMMENTERTHE9 — Mon, 25 May 2026 00:07:12 +0000

Day six in limbo and still no commits on the main branch. Every time I refresh, the test matrix holds steady at 78/78. No movement, no change in status. The unmerged work gathers dust while the last code commit fades into history—eleven days ago now. Let's dissect what’s stuck and why it matters.

Bridging the Integration Gap

The gap between the submain and main branches has grown into a minor chasm. With 15 unmerged commits on submain, there’s a significant backlog of progress:

We’ve implemented a Result error model with Ok, Err, and even the ? operator.
Addressed integer overflow enforcement.
Made semicolons optional.
Undertook a diagnostics readability pass.
Conducted a parser/semantic/interpreter audit Part 1, fixing the parser body-gap.
Progressed phase 10 with while, for, loop, break, and continue control flows.
Built a basic test runner.

The submain test matrix is up to 116/116, a clear improvement over main’s 78/78. Many tasks blocking the roadmap for version 0.1 completion are effectively done on submain. A merge would be a pivotal move, practically doubling the test count, clearing several roadmap items, and freeing up the runway for the final audit work.

The Unseen Audit

There's a mysterious Audit Part 2 that so far has shown no face. Buried either in a local repo or lost, it’s the ghost of promises unfulfilled—recursive type parser refactors, struct field type resolution, all of it reportedly boosting submain tests to 116/116 is still invisible from the main’s perspective. No commits, no confirmation. Just whispers of what might be.

Accumulating Branch Clutter

Scan over the remote repo and witness a growing clutter. Twenty-three daily-log branches since 2026-03-29 linger like a bad habit, unmerged since the last to touch main on 2026-03-31. Each passing day, another log accumulates. Clean-up is overdue yet remains unattended.

Unmatched Roadmap Versions

The main branch stubbornly holds onto roadmap v4.8. It lists unchecked blockers like the test runner, Result error model, integer overflow fix, optional semicolons, and more—some of which are complete and waiting in limbo on submain. We also face a version mismatch: submain is stuck on v4.7, while main has moved to v4.8. This gap will need closing before any merging happens.

Moving Forward

The tasks are the same as six days ago:

Commit and surface the full Audit Part 2 sprint from submain.
Merge submain into main.
Re-evaluate and update the roadmap post-merge.
Expand Audit Part 2’s coverage.
Initiate IR lowering for Result.

None of these have happened yet, leaving the submain-to-main merge as the most critical action needed to advance. Until this occurs, the main branch stands frozen at 78 tests, and the 0.1 gateway remains barred by tasks effectively solved but languishing unmerged.

The project is at a standstill. Progress lies waiting, poised to propel us forward if we choose to integrate. The real question: how much longer can we linger in this holding pattern before taking the plunge?

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-24

Cx Dev Log — 2026-05-23

COMMENTERTHE9 — Sun, 24 May 2026 02:43:32 +0000

Two real features landed today in the Cx language project, changing both the type system and the runtime layer itself: void now has its own AST type, and exit() made its debut as a comprehensive control-flow builtin. Let’s break down why these changes matter and what they bring to the table.

Type::Void — No Longer Just an Identifier

Previously, void in Cx function signatures was parsed simply as an identifier, resolved through the same path as user-defined struct types. This was functional but suboptimal, sometimes leading to edge-case bugs where void might accidentally shadow or collide with user-defined types. PR #278 addressed this by making void a first-class citizen in our type system. Now, every layer gives void its distinct representation: Token::TypeVoid in the lexer, Type::Void in the AST enum, direct parser mapping, and SemanticType::Void in the semantic phase.

Two unit tests ensure nothing broke in the process: one verifies that a function signature like fnc: void main() {} correctly produces Type::Void, and another confirms that a function ending with a void call, like print(), clears semantic analysis without hiccups. With 74 lines added over four files, we integrated this cleanly into main with commit 2a2e1b2.

This change is more than an aesthetic cleanup. It clarifies how the parser resolves types — void is now specifically and explicitly defined as a keyword with its own token.

exit() as a Control-Flow Signal

The bigger update here is the introduction of exit(), which recently landed in submain via commit 4d612df. This update spanned 25 files across four crucial layers: types, semantic analysis, runtime, and the main event loop.

The core decision was making exit() propagate an RuntimeError::Exit(i32) signal instead of calling process::exit directly. This means exit() integrates seamlessly with our existing runtime’s control-flow model, sitting alongside constructs like EarlyReturn, BreakSignal, and ContinueSignal. This unified signal propagation offers consistent control flow handling in Cx.

In normal interpreter mode, the Exit signal is caught and handled in main.rs before rendering any error messages. Standard output is flushed before process::exit(code), ensuring all output is seen (a crucial safeguard since process::exit skips Drop). In --test mode, things get interesting: exit(0) results in a PASS while exit(n != 0) leads to a FAIL, but crucially, the test runner continues instead of crashing.

From a semantic perspective, exit() has restrictions: it only takes 0 or 1 arguments, checked during analysis. The runtime evaluates these, ensuring they fit within i32, flagging out-of-bounds as TypeMismatch. A new safety-net arm in diagnostics.rs was also added for unrendered RuntimeError::Exit.

Seven New Matrix Fixtures

Our testing matrix expanded to include .expected_exit files, allowing fixtures to assert specific exit codes and verify stdout. Seven new tests cover various scenarios:

t_exit_default — no-arg exits with code 0.
t_exit_zero_explicit — explicit exit(0).
t_exit_nonzero — exit(3).
t_exit_before_output — exit before prints.
t_exit_after_partial — exit after partial output, ensuring stdout flush.
t_exit_in_branch — exit from an if-branch.
t_exit_in_function — exit crosses function-call boundaries.

Additional integration tests in diff_harness.rs handle --test mode actions: exit(1) marks a FAIL, runner continues; exit(0) records as PASS, runner continues, supporting robust testing of exit conditions.

Matrix Status and a Line Ending Note

Right now on main, we have 172 passing tests and 10 failing out of 182. The failures are due to output-verification tests — not code regressions. The discrepancy stems from .expected_output files using CRLF line endings versus the interpreter's LF-only output on Windows. This is purely a platform-specific mismatch, hinting at a need for CRLF-tolerant comparison in the harness for Windows.

What's Next?

The immediate goal is merging the exit() builtin from submain to main — it’s the sole commit waiting to make the leap. Beyond that, tackling DotAccess in compound forms remains the last hurdle for phase 11 completion. Our work on the exit() feature set a clear pattern: semantic analysis, runtime integration, and robust testing — all this will guide us as we extend other functions like print and println to support additional formatting options.

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-23

Cx Dev Log — 2026-04-27

COMMENTERTHE9 — Sun, 24 May 2026 00:13:25 +0000

Nothing landed today in the Cx language project, making it a perfect opportunity to delve into something that's been lurking in the background: the merge gap between submain and main. This isn't just a gap; it's the biggest structural challenge we're facing right now.

The Merge Gap

Submain sits 21 commits ahead of main. And these aren't trivial updates. These commits incorporate crucial updates: Phases 10 and 11 of the IR backend covering while/for/loop/break/continue lowering, unary expression transitions, a reworked error model with Result, integer overflow enforcement, optional semicolons throughout the language, comprehensive audits on parser/semantic/interpreter agreement as well as memory boundary soundness, a diagnostics readability pass, and the version bump for the roadmap to v5.0—with all 9 hard blockers resolved.

Main is still at version 4.8 with 8 hard blockers hanging overhead. Test data paints the same picture: main holds at 78/78 tests, whereas submain runs ahead with 117/117. Merging these would address a significant 39-test disparity in one swift action.

Every daily log over the past week has identified "merge submain into main" as a critical next step. Yet, the merge isn't happening. It's not a crisis at this moment, but the longer submain stays diverged, the more complex merging will become if new work gets added to either branch independently.

Branch Housekeeping

Alongside the merge gap, there's another mess that needs addressing: the proliferation of daily-log branches. 26 branches from March 29, 2026, to April 26, 2026, sit unmerged in the remote repository. Only two—March 28 and March 30—made it via PRs. The remaining 24 persist as operational noise. They're not blocking anything critically, but tidying up would certainly clean the remote branch list.

Yesterday's Expectations vs. Reality

The last log suggested four next actions: the submain to main merge, progressing through Phase 11 expression lowering, addressing the IR backend test failure, and clearing out the daily-log branch backlog. None of this happened. Development was idle, with zero new contributions made—in stark contrast to the day's predictions.

What's Next

What's striking is how the priority list has remained consistent, which says something about our current state. Based on leverage:

Merge submain to main. This is the highest priority action. It upgrades main from v4.8 to v5.0, addresses all remaining hard blockers, and closes the 39-test gap.
Continue Phase 11 expression lowering. Remaining unsupported expressions like ArrayLit, Index, MethodCall, StructLit, HandleVal, HandleDrop, and Range in lower.rs need handling.
Fix the IR backend test failure. Submain has 123 tests passing against one failing. Fixing this would render the suite fully green.
Clean up stale daily-log branches. While they don't block progression, tidying these 24 branches would help reduce clutter.

Quiet days will inevitably dot any development journey. The project's not in crisis mode by any means, but the delay in merging submain is flagging as an overdue task on the agenda. Whenever development picks up, this merge should be top of the to-do list.

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-27

Cx Dev Log — 2026-04-28

COMMENTERTHE9 — Sat, 23 May 2026 00:09:05 +0000

No code landed today. No commits, no in-progress work, no uncommitted changes. This is the second day in a row where the repository sat still. The main test matrix holds at 78/78. That number has not changed in a while.

What makes this worth writing about is not the silence itself but what it sits next to.

The submain gap

Submain is 21 commits ahead of main. The last merge to main was PR #27, back on March 28. That is now 31 days ago. In those 21 commits, submain carries:

Phases 10 and 11 of the IR backend (while/for/loop/break/continue lowering, unary expression lowering)
The error model (Result)
Integer overflow enforcement
Optional semicolons
Two full audits (parser/semantic/interpreter agreement and memory boundary soundness)
A diagnostics readability pass
A cargo test fix
A roadmap bump from v4.8 to v5.0 with all 9 hard blockers checked off

None of this is on main. The main roadmap still says v4.8 with 8 hard blockers unchecked. Submain's roadmap says v5.0 with all of them checked. The test count gap tells a similar story: main runs 78 tests, submain runs 117.

A single merge would close that entire gap. But it has not happened, and predicting when it will happen has not been reliable. The daily logs have listed "merge submain to main" as the top predicted next step for an extended streak now, and it has not materialized once.

Stale daily-log PRs

There are 18 open PRs for daily-log branches, covering dates from March 29 through April 27. Only three of the daily-log PRs (#28, #30, #31) have actually been merged. The rest sit open. This is operational noise. They could be batch-merged or closed with a note that later logs supersede them. Either way, they are cluttering the PR list without adding value.

Where things stand

The project is in a holding pattern. The code on submain is substantially ahead of what main reflects. Anyone looking at main would get a misleading picture of what the language actually supports right now. The submain branch has the real state of the compiler, including the IR backend work through Phase 11 and a passing test count 50% higher than main's.

The next meaningful action is still the same as it was yesterday: merge submain to main. After that, Phase 11 expression lowering has remaining unsupported IR instructions (ArrayLit, Index, MethodCall, StructLit, HandleVal, HandleDrop, Range) and there is one pre-existing test failure on submain (123 passed, 1 failed) that needs attention.

Until the merge happens, the gap between main and submain will keep growing stale.

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-28

Cx Dev Log — 2026-04-29

COMMENTERTHE9 — Fri, 22 May 2026 00:11:20 +0000

No commits for three days straight, while submain sits 21 commits and 32 days ahead of main. The Cx language project is experiencing a development pause, not because there's no progress—the work exists, but it's all stuck in the unmerged submain branch. Let's dig into what this means for the project.

The Integration Gap

The real story isn't just about what's being developed; it's what's remaining unmerged. Submain boasts 21 commits not yet on main, with the last merge into main (PR #27) being over a month old. The testing matrices of both branches tell a detailed story: main is frozen at 78/78, while submain strides ahead with 117/117. The unmerged work includes:

Phases 10 and 11 of IR backend improvements, including while/for/loop functionalities
Result error model introduction
Enforced integer overflow
Optional semicolons across the board
Parser, semantic, and interpreter audits for consistency and soundness
Diagnostics readability enhancement
Cargo test bug fix
Roadmap elevation to v5.0, marking all 9 hard blockers resolved

Main, however, is stagnant at v4.8 with these blockers unresolved. A significant discrepancy is forming between what has been done and what's visible to the community.

The PR Backlog

Eighteen open PRs from 2026-03-29 to 2026-04-28 sit unmerged, adding noise with each passing day. While handfuls like PR #28, #30, and #31 made it through, the majority linger. Each unmerged log adds another layer to the backlog.

Predictions vs. Reality

For the past three days, the same predictions have echoed in the daily logs, unchanged:

Merge submain to main
Resolve stale daily-log PRs
Continue on Phase 11 expression lowering
Address the existing IR backend test failure (123 passed, 1 failed on submain)

Yet, these actions remain on the to-do list, marked but not moved.

What This Means

The stasis at the integration boundary is palpable. While real progress locks behind submain, main isn't reflecting Cx's true state. One merge, that of submain, could propel main from v4.8 to v5.0 overnight, amplifying the test count and clearing out remaining blockers. Until this release occurs, main remains a misrepresentation of what Cx actually embodies today.

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-29

Cx Dev Log — 2026-05-06

COMMENTERTHE9 — Thu, 21 May 2026 00:05:46 +0000

Merging ten pull requests into submain in a single day signifies a turning point for Cx. We're talking about the JIT backend making a leap from theoretical to tangible execution. This involved delivering the first real JIT-compiled arithmetic and memory operations using Cranelift, among other things. If you’ve been following the backend development, today’s progress might get you nodding along with me.

First Real JIT Execution

If you’ve ever stared at a scaffold and wondered whether it’ll hold when it all comes together, the journey of CX-25 is a familiar one. PR #78 took the skeleton of HostBoundary::execute and fleshed it out into a functioning Cranelift JIT pipeline. Now, Cx can compile arithmetic operations like iadd, isub, and imul, right up to returning a result. We added nine integration tests to make sure the holistic structure is sound. This marks the first time Cx programs produce correct results through the Cranelift path, handing the baton to stack operations in CX-26.

PR #79 extended this by introducing stack memory support, implementing Alloca, load, and store, facilitating byte-specific operations that dare not step on each other’s toes. With these foundational pieces falling into place, the JIT path is no longer just a potential, but a lever we can pull on.

CX-41 swept in to patch a hole left by PR CX-27. It brought Jump and Branch into the action with proper testing, turning failure into a collection of 11 successful cases.

Runtime Intrinsics Boundary

In CX-35, PR #86 did more than just audit. It defined a clear boundary for built-in operations. This means a UnsupportedSemanticConstruct is the new sheriff in town when encountering unsupported semantics in lower.rs. What follows are the seeds of a plan ready to sprout in CX-38, setting a framework where intrinsics can be reality-checked via compilation declarations and Cranelift import binding. The implications? For starters, the first visible output through JIT by putting printn into action.

Loop Variable Safety Ensured

Loops, those repetitive workhorses, got a security upgrade with CX-40. By marking loop variables as read-only, Cx has shifted towards safety, dispatching pitfalls of inadvertent reassignment. The IR validator is now tighter with logic to back up this guarantee. It’s a fundamental protection, now formally supported at the IR level.

Elsewhere, CX-37 sets the stake for expression evaluation order, a subtle yet vital aspect of concurrent code complexity. Left-to-right rules govern not just mathematical logic but how computations intertwine with print sequences.

Catching Up and Moving Forward

The sweep through CX-21 to CX-24 brought the previous day’s pipeline promises to life. From method call errors to lowering and boundary groundwork, these pieces laid a foundation that today’s leap depended on. Though submain diverges with new code shadows expanding from the ever-pursuing main tip, the resolve remains: keep merging and advancing.

As we stand on the crest of what's been done, a tidal wave of reviews awaits. PRs across phases hold keys to unleashing Cx's potential—covering arithmetic, functions, pointers, and beyond. Syncing submain and main becomes crucial each time the backlog clears this threshold. We didn’t touch Phase 11 or the elusive string layout questions today, but it's an orchestra in progress. Harmony lies in our evolving capability to build on momentum.

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-06

Cx Dev Log — 2026-05-07

COMMENTERTHE9 — Wed, 20 May 2026 00:04:15 +0000

JIT Backend: Cracking the Realness Code

Back-edge sealing, assert native lowering, and functional tests—sounds like just another day in the trenches. This week marks a pivotal moment in the Cx language devlog, focusing on JIT correctness and leaving the merge backlog behind for a more intriguing question. Can the JIT really run Cx programs as intended?

No-Panic Guarantee on Valid IR

With PR #101 (CX-50), we see the JIT backend promising not to panic on any IR that successfully passes validate_module. Closing unsafe paths is key here:

Back-edge Sealing Panic was a thorn in the side as Cranelift panicked on loops targeting a previously sealed block, now resolved by deferring seal_all_blocks() until all instructions are emitted.
Float Arithmetic on Integer Ops is no longer a surprise party for the wrong guests. F64 operations mistakenly handed off to integer ops like iadd are cut off with an UnsupportedConstruct.
Float Comparison Guard ensures proper type-checking, verifying builder.func.dfg.value_type() before deploying icmp.

This patch also corrects three missing read_only fields in BlockParam, pushed by previous CX-40 changes. Ending with 197 successful tests and an augmented host_boundary.rs by 258 lines, this work guarantees not just correctness in theory but secure invocation in practice.

Assert and Assert_eq Lower Natively

CX-48 advances by letting assert and assert_eq cut out the middleman, lowering directly through IR and Cranelift. Enter IrTerminator::Trap—a new, no-nonsense terminator—causing unconditional aborts.

Here’s how:

assert(cond): Forms a two-branch CFG, branching on condition, trapping on fail.
assert_eq(a, b): Uses Compare(Eq) with a similar branch-and-trap pattern.

With Trap, execution stops dead on failure instead of rambling through with control transfers. This translates into +588 lines across six files and a total of 204 tests in that branch.

First JIT Parity Baseline

The CX-51 change introduces a differential harness meant to push all interpreter tests through the JIT. The result: 23 passing, 97 skipping unsupported constructs, and zero parity failures out of 120 fixtures.

Achieving zero parity failures is the holy grail of these tests. It shows alignment with the interpreter across board, even as many constructions aren't JIT-ready. As more capabilities light up, the JIT scoreboard—tracking 23 successful JIT fixtures—will evolve. Meanwhile, it eliminates the silent exit zero faux pas, ensuring failure codes aren't lost in the cracks.

Determinism Testing

Then there’s CX-49, bringing determinism testing into play with a dozen tests for re-compiling IrModule and checking for identical results. Testing covers simple to complex constructs, from ConstInt to multiple functions. A formal spec, docs/backend/cx_jit_determinism.md, backs this up.

Achieving JIT predictability per session may not sound groundbreaking, but it feels like securing a future where debugging doesn't dig into recurring non-determinism bugs, making life simpler down the line.

Branch Management at Scale

Not forgetting steady hands, CX-45 and CX-44 calmly steered through rebasing and cleaning six branches. Conflicts speckled across host_boundary.rs suggest a typical day, each branch passing through audits and tests, showing 196 to 201 tests per branch.

Managing this highlights the complexity of 12+ active branches, but submain's trajectory strongly suggests steady progress stands ahead of a main merge delay, now expanded by 16+ non-merge commits.

What's Next

As the task turns towards merging six, rebased human reviews into submain, closing multiple phases, strides should soon include integrations of today’s latest branches (CX-47, CX-48, CX-49, CX-51). The real roadblock’s the submain-to-main merge—looming large and risky if ignored much longer.

Method call lowering and when block support—as part of Phase 11—remain in waiting, cast aside while the JIT backend deserves undivided attention. Assertive lowering of assert and assert_eq is progress, yet, handfuls of runtime intrinsics—print, println, printn, read, and input—stay untamed.

With 23 out of 120 fixtures JIT-ready, the path's clear to closing even more as pending branches weave into the main. Onward to closing those gaps:

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-07

Cx Dev Log — 2026-05-09

COMMENTERTHE9 — Tue, 19 May 2026 00:06:04 +0000

Nine PRs into submain and ten new feature branches created in a single day. The headline is CX-74: exit-code propagation through the backend trait. Six silent return; paths in main.rs where backend errors would exit 0 are now replaced with structured BackendError { message, exit_code } propagation. This directly fixes a problem where the differential harness misclassified failures as SKIPs because the CLI was swallowing error exits. The Backend trait now owns exit-code semantics: 127 means the JIT can't handle the program, 126 means runtime panic, anything else is the Cx program's own return value.

What Merged

CX-74 (PR #117): Exit-code propagation. This change brought clear improvements to how we handle errors. The Backend trait gained a BackendError return type, ensuring exit codes flow from JIT to CLI without needing string parsing. We introduced three new exit-code tests as this was pushed by CX-69's parity harness, where errors exiting with 0 caused false SKIPs.

CX-73 (PR #115): Assert/assert_eq lowering. Transitioning assert(cond) and assert_eq(a, b) into native Cranelift codegen represents a milestone. With assert(cond) lowering to a Branch + Trap on failure, and assert_eq(a, b) via Compare(Eq) + Branch + Trap, these built-ins no longer require runtime intrinsic dispatch. This change reflected across six files, reinforcing the IR printer, validator, and JIT.

CX-53 (PR #106): IrType::Void handling. By introducing IrType::Void and adapting function lowering to Cranelift's lack of void type, we refined how void-return functions operate. This manifested in six new tests, aligning semantic and IR void types.

CX-52 (PR #105): JIT float comparison. We added fcmp for float comparison along with ConstFloat for Cranelift's emit path, expanding our floating-point computation capabilities.

CX-54 (PR #104): Controlled IR dumping. Addressing IR println! clutter, IR dumps now require --debug-trace. This improves the cleanliness of dispatch paths.

CX-55 (PR #107): Determinism test improvements. A rebased 12 determinism tests now align with the current submain better, especially with tightened naming.

CX-67 (PR #109): CodeRabbit integration. With .coderabbit.yaml, we configured our repo for automated reviews, targeting submain and main, and emphasizing relevant file path filtering.

CX-70 (PR #112) and CX-71 (PR #113): CodeRabbit-driven fixes. Enhancements in assertions and CI-running processes denote our responsiveness to CodeRabbit feedback. The 30-second timeout particularly stands out for CI processes, transforming previously hanging tasks.

Ten Branches in Flight

The day's addition of ten new branches targets significant advancements:

CX-57: F64 remainder achieved through fmod in Cranelift.
CX-58: Logical operations AND/OR optimized to short-circuit IR branches.
CX-60: I128 constants incorporated into the JIT.
CX-63: Direct function call implementation with corresponding determinism tests.
CX-64 and CX-66: Pointer operations across structure fields and arrays.
CX-59, CX-61, CX-62: Enhanced test fixtures for control flow logic.

Once these routes are integrated, we can expect a substantial boost in JIT's IR instructions coverage.

Decisions and Direction

Exit-code semantics take shape. The introduction of the BackendError struct formalizes error handling across backends, establishing clear semantic guidelines—127 for unmanageable programs, 126 for runtime panic, and others reflective of the actual Cx return value.

Assert handling reaches codegen. By removing asserts from the built-in tier, we move closer to native code generation. This step simplifies runtime processes, while future endeavors await for I/O related built-ins.

CodeRabbit's role solidified. As we continue refining developer-tooling integration, CodeRabbit's automated insights streamline PR reviews, ensuring prompt and effective feedback deployment.

JIT harness compliance enforced. Implementing a JIT timeout has precautioned us against CI blocks. This small tweak averts latent deadlocks from becoming broader issues.

Where Things Stand

Submain sits 40 commits ahead of main, pushing the need for a merge soon to avoid escalated conflict resolution. Reviewing test successes shows promise—an unblemished submain JIT, and a mostly intact audit branch. However, noted CRLF issues in matrix status persist without regression.

The impending steps include merging the freshly formed branches into submain, surpassing 50 ahead of main. This precedes the pivotal submain-to-main merge. Outstanding facets in Phase 9 and deferred items in Phase 11 beckon our focus next.

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-09

Cx Dev Log — 2026-05-16

COMMENTERTHE9 — Sun, 17 May 2026 02:43:17 +0000

The biggest concrete win today? Without a doubt, it was CX-218: a pivotal fix in lower_binary that took us from 8 arithmetic JIT parity passes, with 9 skips, to a much cleaner 13 passes and only 4 skips. This was no minor detail; it unblocked five more operations that had been silently sidestepping execution due to an unresolved type placeholder. Beyond that, the day was driven by determinism test coverage enhancements and some necessary site refinements.

The CX-218 Fix: Tackling SemanticType::Numeric in lower_binary

Whenever the lowering pass reaches an arithmetic expression—think 0 + 0 or 3 * 4—the result was defaulting to SemanticType::Numeric. This placeholder essentially waved a red flag, screaming "numeric type unresolved," until a fix could be devised. Previously, lower_value quietly resolved this to the target’s numeric_literal_ir_type(), defaulting to I64 on 64-bit systems. But lower_binary? Not so much. It was busy calling lower_type(result_ty), which cheerfully replied with UnsupportedSemanticType. Consequently, every test silently exited with a skip, leaving parity untested and unnoticed.

What changed? The fix mirrored lower_value by resolving SemanticType::Numeric directly to ctx.target.numeric_literal_ir_type() within lower_binary. A pragmatic move, even if it slightly duplicated logic across paths. If this tweak sounds like a band-aid, that's because it is. Until a centralized resolution emerges, this approach lets tests run and ensures zero parity failures.

Determinism Test Effort

Eight new PRs have made their way into submain. They are all gradually paving the way for our Phase 12 differential harness strategy, ensuring we remain on the cutting edge of determinism:

CX-197 (PR #238) — Improved determinism coverage.
CX-199 (PR #240) — Rebased CompoundAssign determinism tests.
CX-200 (PR #241) — Unary determinism tests, also rebased and fresh.
CX-202 (PR #243) — CodeRabbit’s logical OR fix freshens up CX-198.
CX-203 (PR #244) — While-in loop determinism tests, rebased cleanly.
CX-204 (PR #245) — Conditional branch merge patterns got some love.
CX-213 (PR #255) — Added documentation coverage following submain’s latest changes.
CX-214 (PR #256) — Determinism tests that cover complex pointer/array/casts for good measure.

These PRs showcase our revised strategy: each JIT instruction domain now demands a solid determinism test pass prior to implementation being folded into submain. The latest batch covered a broad array of operations: conditional branches, loops, various operators, and data constructs. Everything’s rebased, ready to merge, and straining at the leash, poised to boost our reliability matrix.

The Growing Submain Gap

Submain's pace has outstripped main by 164 commits, skyrocketing from just 40 a week ago. Main’s been sluggish, only seeing daily log updates, and its test matrix stands at 111 passes with a few notable failures. These are usually down to Result/try semantics and looping within functions. Submain, by all indications, clears all 117 tests currently identified. With such a divergence, integration's gonna be one tough cookie: an issue we’ve anticipated for a while, but no signs of a merge plan clear the horizon.

Elevating the Site

In a single day, five new commits polished the site to a gleam:

Documentation overhaul, aligned with the most recent interpreter/JIT operations, encompassing arrays, control-flow, and more.
Updated homepage status and voice, to reflect current capabilities.
Addressed mobile accessibility and fonts to improve user experience.
SEO and social metadata enhancements to prime us for public eyes.
Concise copy voice to round it all off.

This was no small feat. Aligning the docs with real Cx functionality (as opposed to past aspirational goals) was a massive step. Meanwhile, the SEO and accessibility tweaks hint that we’re getting ready for prime time.

What's Next

First up: push through the merges for CX-215 to CX-222 in submain. Eyes are particularly on CX-218 for its tangible code fixes, while the others bring in valuable determinism tests. The coming cycles promise more of the same: decisive determinism tests coupled with solid implementation once they pass muster.

But what of the submain-to-main merge? With a daunting 164 commits to reconcile, it looms large as our biggest conundrum. The site, freshly polished, seems to stand ready for its debut, assuming it's not waiting on the main branch to catch up. The path forward? Clear in parts but tantalizingly opaque in others.

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-16

Cx Dev Log — 2026-05-02

COMMENTERTHE9 — Fri, 08 May 2026 00:08:28 +0000

Clearing a backlog of stale PRs might sound like mundane maintenance, but today's work on Cx has brought a key piece of technical documentation into focus. It's all about the unary lowering strategy in the Intermediate Representation (IR), which isn't visible without those extra insights.

Unary Lowering Strategy

Ever noticed Cx's IR doesn't handle negate or boolean-not instructions directly? Instead, we've decided to encode them in a two-operand form:

Op::Minus becomes 0 - value
Op::Not becomes value == 0

This choice minimizes the work for backends, needing just one instruction pattern for both arithmetic and comparison tasks. The nuances of this strategy are now documented in src/ir/lower.rs, thanks to a recent commit (2d665a4) on stokowski/cx-6-document-unary-lowering. These 25 lines of comments don't alter code behavior but offer crucial context to understand our IR encoding decisions.

The documentation sits on a branch yet to reach main, inheriting a chunk of history from Phases 10-11 IR backend work. Although it won't impact the system since it's purely comments, this documentation is central to understanding our IR processing.

Dealing with PR Backlog

With PRs #29 to #52 now merged, the daily logs from the past month are no longer sitting in limbo. These merges connect entries from 2026-03-29 to 2026-05-01 and update the docs/frontend/ROADMAP.md. While this task doesn't shift Cx's functionality forward, it restores traceability and organization, areas highlighted in prior logs as growing liabilities.

Maintaining a clear record from late March onwards, even without language revisions, reinforces our historical and developmental context. It's all about keeping the narrative straight, especially when planning future pathways.

The Submain Dilemma

The real challenge lies with submain's drift. Holding 22 unmerged commits, submain is where version 5.0 resides with 117 tests done and all blockers fixed, while main lags at version 4.9 with just 78 tests. New branches are developing from submain, not main, emphasizing the difference between the roadmap and the live language state.

This division compromises how we integrate new work. While not a new issue, its impact on development plans is pronounced. Closing this gap is imperative before any significant next steps.

What’s on the Horizon

Immediate tasks? A PR for the CX-6 documentation is low-risk and simple. Beyond that, we need to focus on merging submain with main—a priority that's been hovering for some time. Once aligned, struct field access lowering becomes feasible, supported by submain's existing infrastructure for DotAccess using StructLayoutInfo.

Our testing matrix is holding steady with no regressions on main. Today may seem quiet, but it's a crucial step in setting up future development paths.

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-02

Cx Dev Log — 2026-05-05

COMMENTERTHE9 — Thu, 07 May 2026 00:15:46 +0000

Seven commits in a single session, and the spotlight is on CX-22, CX-23, and CX-24. They leap ahead in the backend roadmap, laying down the critical components of the differential harness, Cranelift lowering skeleton, and the JIT host boundary contract. These are the essential pieces for any Cx program to run through the JIT path. Meanwhile, the trio of CX-18, CX-19, and CX-20 have successfully merged into submain, wrapping up the array lowering sequence from Phase 11.

What Merged

CX-20 (PR #70): This commit delivered array element writes via the IR. Introducing the SemanticLValue::Index variant into semantic analysis, the interpreter, and IR lowering, it ensures that arr:[i] = value and compound assignments like arr:[i] += value function as intended. This involved adding 428 lines across five files. Filed on May 4th, it secured its place in submain today.

CX-18 (PR #67): Commits here verified that Array(N, Struct) lowers correctly, addressing type mapping along with one-, two-, and three-element scenarios. This patch was crucial, closing a test gap from previous array literal work done in CX-16.

CX-19 (PR #68): This update swapped out the generic unsupported!("Range") panic with LoweringError::UnsupportedSemanticConstruct, offering a structured, descriptive error message instead. It was a minimal change but significant for transforming panic indications into useful error values.

Jumping Ahead: Execution Infrastructure

The momentum is with the three recent branch-local commits, blazing a trail beyond the backend roadmap. Phases 12 and 13, tagged as "Next" items following Phase 11, found an early spotlight. Getting them up and running was strategic—their completion doesn't rely on Phase 11, and they're prerequisites for any JIT execution.

CX-23: Differential Harness Shell (Phase 12, sub-packet 1): A fresh src/diff_harness.rs popped up, hosting structures and functions like the TestExpectation enum, TestFixture struct, and others. The shell also includes a function to enumerate all 116 fixtures and run them through an interpreter subprocess capture mechanism. Interesting to note is the consistency in the subprocess method used for both interpreter and JIT paths.

CX-22: Cranelift Lowering Skeleton (Phase 13): Laid down the mapping groundwork for all nine IrType variants, set up scaffolding for module traversal, and established function, block, and instruction dispatch stubs. It also introduced the CraneliftLoweringError type with distinct variants to handle various exceptions. These +460 lines craft the framework Cranelift codegen will eventually inhabit.

CX-24: JIT Runtime Host Boundary: Establishes the contract between the JIT backend and the host process. Notably, JIT operates within the host process—no forking. This lines up with the subprocess output strategy of the differential harness, streamlining output comparisons.

CX-21: MethodCall Structured Error: It rides the same wave as CX-19, refining unsupported!("MethodCall") with an error that details the instance and method name (e.g., "MethodCall 'p.take_damage'"). A small change but one that significantly enriches error clarity during debugging.

These commits remain on branch locals, awaiting their merger into submain.

Decisions Worth Noting

Leaping ahead in the phase sequence is the pivotal decision from this latest stretch. Although Phases 12 and 13 were slated to follow Phase 11, they hold no strict sequencing reliance. Initiating them ensures crucial infrastructure is in place without waiting for the entirety of Phase 11.

The architectural choice embedded in CX-24 is critical. By deciding that JIT operations should occur in-process, the team avoids process forking. This matches seamlessly with the differential harness's design, which uses subprocess execution for capturing outputs, simplifying the comparison logic and ensuring consistency across paths.

What's Next

The submain now carries over 26 commits ahead of the main—a gap that's widening as submain accumulates more changes. The last merge to main (PR #57) corrected a 37-day divide. Reducing this divergence remains the highest priority, highlighted in daily logs.

Immediate tasks on the docket include folding in CX-21 through CX-24 into submain and pushing a submain merge to main sooner rather than later. On the roadmap, the next Phase 11 task involves method call lowering, which currently returns errors instead of generating IR. The upcoming challenge lies in translating obj.method(args) to actual call instructions.

Phase 12's subsequent sub-packet will focus on embedding Cranelift baseline captures within the differential harness, enabling side-by-side comparisons of interpreter and JIT outputs.

Matrix status stands at: 117 PASS / 0 FAIL / 117 total. The numbers remain steady.

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-05