DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-07-04

COMMENTERTHE9 — Sun, 05 Jul 2026 02:43:00 +0000

Handles in Cx have taken a big step forward with two key commits now on submain. The Handle type has finally become a real machine value processed through Cranelift, marking a major milestone for Phase 8 Round 2.

The packed-i64 Representation

In Cx, a Handle is straightforward: a packed single i64 represented by slot | (gen << 32). Both slot and gen are unsigned u32s and we use a u64 reinterpretation to avoid any sign-extension issues. Specifically, lower_type(SemanticType::Handle(_)) outputs an IrType::I64.

Handling these machine values required placing runtime state in a HandleRegistry<i64> behind a OnceLock> static in host_boundary.rs. This setup is a workaround for Cranelift limitations. The constraint? jit_builder.symbol() relies on raw function pointers, not state-capturing closures. Safety here comes from run_jit_subprocess which isolates states by using fresh OS processes for each fixture, preventing cross-test state carryover.

A helper, widen_handle_payload_to_i64, converts inner expressions' lowered types to i64 but only for {I8, I16, I32, I64, Bool} types. Notably excluded are:

Ptr: We'd face the Handle<str> issue, where a raw scalar or a string descriptor pointer could confuse operations.
F64: This would lead to silent truncation, not suitable for types requiring round-trip fidelity. Consideration here is crucial, reflecting intentional design rather than future work placeholders.

Handle.val and the Out-parameter Approach

Reading the value (commit D2.5b) posed more challenges than expected. Our initial "uniform-i64" hypothesis didn't hold water due to strict type equality required downstream. Instead, HandleVal's semantic design uses I128, not i64, so handling it involves widening the i64 payload via sign-extending Cast to output a legitimate IrType::I128.

For validity checks, an out-parameter is used instead of sentinels, given that the slot+gen packed space leaves no room for reserved bit patterns without conflicts. _cx_handle_val(handle: i64, out_valid: *mut i8) -> i64_ performs the out-parameter check and defaults to IrTerminator::Trap if invalid. The reuse of the Alloca/Store/Load pattern, similar to Results, adapts well, though a single-byte slot suffices here.

Though the Trap path is hardwired, we can't yet test invalid handles through current Cx code; since there’s neither HandleDrop nor uninitialized reads. The real testing awaits D2.5c alongside generational reuse that will naturally generate stale handles.

Handle+Array Composition Success

A third commit by early July 3rd confirmed the correctness of Handle+array composition. An earlier syntax error audit, using arr[i] instead of the correct arr:[i], had been resolved. Now, Handles in array literals process and return expected results. Notably, the t_handle_array_no_drop fixture confirms this improvement.

Test Matrix Progress

The matrix on submain now stands at 297/0 after rising from 292. Parity scores are 237 PASS / 60 SKIP / 0 PARITY_FAIL across this set. Recent commits introduced several new fixtures, such as:

t_handle_construct_cross_fn (from D2.5a, provisional)
t_handle_val_positive (standard round-trip case)
t_handle_val_negative (tests for sign-extension)
t_handle_val_bool (validates discrimination)

Currently, all updates remain within submain, with main unchanged.

What's Next

Up next is the HandleDrop (D2.5c), set to handle generational reuse and empirically prove the stale-handle Trap path. An integration point approaches with submain now four commits ahead of v0.3.0 and a merge to main beckons. Still in the wings are DotAccess updates in compound forms, alongside uncommitted tutorial rewrites—280 lines ready to fit into the broader narrative.

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

Cx Dev Log — 2026-06-28

COMMENTERTHE9 — Mon, 29 Jun 2026 00:10:00 +0000

Labeled break/continue is now live across the entire Cx language stack. From the lexer to the JIT, two commits streamlined the implementation into a complete vertical slice. No parts left out, no corners cut—everything just works.

The lexer seam

If you're handling character literals and labels in the same codebase, you'll know what a pain this can be. We opted for a Rust-like syntax: 'ident for labels, with no closing quote. The label regex sits right after LiteralChar in the logos enum. Thanks to longest-match, 'x' becomes a char literal, while 'outer is parsed as a label. Escape sequences? They can't match labels because they have a backslash, making 'x' always look cleaner in code. A test fixture (t_char_literal_guard) ensures this order and regex integrity hold. Change the lexer rules, and it'll catch any mistakes immediately.

Two-commit split

We didn't cram this into a single mega-commit. No, we split it into two. Commit f94c6a5 laid down the frontend groundwork—adding the Label token, allowing loops and breaks to carry optional labels, and rejecting any misuse with semantic checks. The interpreter and JIT, however, initially took a back seat, guarding themselves against mislabeled jumps.

Then came commit 0f56f1e, which wiped out these guards and enabled real execution on backends. Now all parses and semantic checks play nicely without rogue labeled breaks sneaking into the wrong loops.

Interpreter changes

The interpreter now handles BreakSignal and ContinueSignal carrying labels. Loops catch these signals when the label is either absent (defaulting to the innermost loop) or matches their own. The difference from before? Zero unlabelled break/continue behavior change while facilitating outward jumps.

JIT changes

The JIT saw more extensive adjustments, gaining a label field within LoopContext. Push and pop that context on a stack, trace it through lowering calls, and you've got labeled jumps pinpointed. The unlabeled jumps? They get the same treatment as before by taking the top of the stack. Existing codegen remains untouched, minus this stack expansion for labeled functionality.

Test fixtures

To solidify all this, we introduced four new test fixtures. Semantic rejections? Covered. Breaking and continuing to outer loops? Nailed. This test suite now boasts stability: 292 pass, 0 fail.

Other changes

We've also logged a packed-i128 representation and updated the ? operator details on the site branch (07bef03).

What's next

Labeled breaks dug into the core of semantic.rs and lower.rs, setting the stage for optimizing when block lowering. Projects like DotAccess in compound forms and dynamic strings are still in queue, waiting for their time in the spotlight. But, the submain branch grows restless, 26 commits ahead and aging since its last merge—no regressions, just merge delays.

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

Cx Dev Log — 2026-06-27

COMMENTERTHE9 — Sun, 28 Jun 2026 02:42:44 +0000

Result just crossed a major compiler boundary in Cx, marking a significant step forward in our error handling journey. Two key commits have successfully integrated the packed-i128 representation and introduced the ? (Try) operator within the JIT pathway. Let's explore how these changes shape the overall architecture and what they mean for developers working with Cx.

The packed-i128 representation

Storing Result as a packed i128 turned out to be an interesting technical challenge. We split the i128 into a tag and a payload, with the high 64 bits reserved for the tag (Ok = 0, Err = 1) and the low for the payload. The goal was to maintain clear separation without arithmetic packing, which would risk sign-extension messing up the tag when handling negative payloads. Instead, we opted for a memory round-trip approach: allocate, store, and then load both parts into a single i128. This method is mechanically heavier but it confidently preserves data integrity—an essential choice.

One key safeguard is a canary fixture named t_result_ok_negative.cx, ensuring negative payloads don't corrupt the tag. Any future attempt to optimize this away would trigger the test.

On the Cranelift front, we had to tweak the settings a bit with enable_llvm_abi_extensions in host_boundary.rs to handle i128 arguments correctly. It’s a small but critical adjustment to maintain byte-for-byte output consistency between JIT and interpreter.

The ? operator

Bringing the expr? operator into the picture with D2.4b required an ingenious unpacking process. Here, the packed i128 unpacks using result_unpack, allowing us to branch on the tag. For an Ok tag, execution proceeds by narrowing the payload back into its original form. For an Err, we return the entire i128 early, preserving error data consistency to the caller.

Importantly, Cx's semantic analyzer ensures ? is context-appropriate—enforcing its use only within Result-returning functions. This preemptive check simplifies the lowering and avoids unnecessary runtime consistency checks.

It's worth noting that the Result usage is bounded by T's ability to fit within a single i64 word. While this decision limits nested Results, it keeps us honest about representation constraints and prevents unknown behavior, clearly marking where further work lies.

Example suite rewrite

Apart from the core changes, the examples/ directory got a fresh, comprehensive rewrite. The examples now include more intuitive code patterns, richer demonstrations, and polished documentation. The error_handling.cx example stands out, showcasing the Result and ? operator now viable due to these backend improvements. These changes, though uncommitted, prepare the ground for developers to see these new capabilities in action, adding roughly 280 lines across the suite.

What's next

Our upcoming focus is on D2.4c, addressing equality routing for Result types. While assert_eq functions effortlessly for Result due to i128 equality on Ok tags, Err comparison will rely on cx_str_eq for fairness on strings. These finer routing details are pivotal for robust error-type handling.

Meanwhile, the example documentation overhaul is pending commit. The error-handling example, central to our recent changes, waits in the wings for the new commits to merge into main, already 24 commits behind the action.

Looking ahead, our roadmap includes tackling dynamic strings (R6) and DotAccess in compound forms to complete Phase 11. Parity benchmarks have already improved with 229 tests passing out of 287 on submain, whereas main lingers a bit behind.

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

Cx Dev Log — 2026-06-26

COMMENTERTHE9 — Sat, 27 Jun 2026 00:08:17 +0000

No code landed today. No commits from the developer across any branch for the second day in a row. The only repo activity was automated: yesterday's daily log commit and a site blog post. That makes this a good moment to take stock of where things actually stand.

Static strings are done, dynamic strings are not

The static string subset (D2.3a through D2.3d) shipped to submain and has been stable for about 48 hours now. That covers len() constant folding, string literal lowering, concat folding with content equality, and string interpolation with f64 print support. Everything that can avoid runtime allocation is handled.

The next real frontier is R6: dynamic strings. This means runtime allocation, lifetime management, and a new string representation. It is a qualitative step up from the static work. It has been the predicted next move on daily logs for ten consecutive days now, but no work on it has started yet.

The submain-to-main gap keeps growing

Submain is 22 commits ahead of main. The last merge (PR #295) was 21 days ago. The test matrix on submain is clean at 286 pass / 0 fail, with parity numbers at 222 pass / 64 skip / 0 parity fail. Main sits at 230 pass / 0 fail out of 230.

There is no technical blocker to merging. The gap is just growing through inertia.

The daily-log PR backlog

There are at least 10 open daily-log PRs (June 16 through 25, PRs #308 through #317), and none have been merged. The last daily-log PR that actually landed on main was from late May. This matters because those PRs carry roadmap updates that check off real completed work: range-check hardening (CR#1 through 4), arithmetic safety gates, when block lowering, unknown/TBool lowering, and the full static string subset. Main's ROADMAP.md still reads "Last updated: 2026-05-18," which is over five weeks stale.

The roadmap on main does not reflect the current state of the project. Anyone looking at main alone would have no idea that the static string subset is done.

What is actually next

The same three items that have been predicted for the last ten days remain the natural continuation:

Dynamic strings (R6) is the clearest technical frontier. It requires allocation infrastructure that does not exist yet.
Merging submain to main would close the 22-commit gap and bring the roadmap current. Zero regressions stand in the way.
DotAccess in compound forms is the last unchecked non-string item under Phase 11.

Two rest days in a row might mean the developer is away or working on something outside this repo. When work does resume, any of these three would move the project forward.

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

Cx Dev Log — 2026-06-25

COMMENTERTHE9 — Fri, 26 Jun 2026 00:09:05 +0000

No code landed today. The static string subset wrapped up yesterday with D2.3d (print-time interpolation and f64 print lowering), and today was a genuine pause. Sometimes those are worth documenting too, because the project state right now is interesting.

Static strings: done

The D2.3a through D2.3d arc is complete on submain. The JIT now handles string literals, compile-time concatenation, content equality, and print-time string interpolation. Every string operation that can avoid runtime allocation is covered.

The approach to interpolation is worth noting: print("a {x} b") decomposes at lowering into a sequence of inline prints rather than building a new string in memory. That was a deliberate design call to keep R6 (dynamic string allocation) out of scope for this batch. It works for print statements; string interpolation in general expression context will need the allocation infrastructure that R6 brings.

The parity numbers tell the story. Submain sits at 222 PASS / 64 SKIP / 0 PARITY_FAIL across 286 fixtures. Those 64 SKIPs are the dynamic string cases and JIT-unsound paths that need R6 or bounds checking to resolve. Main's matrix holds steady at 230/0.

The merge gap

Submain is now 22 commits ahead of main. The last merge was PR #295 (the v0.2.0 batch), and that was 20 days ago. Every daily log for over a week has predicted a submain-to-main merge, and it keeps not happening.

There are zero regressions on submain and no merge conflicts expected. The accumulated work includes range-check hardening, arithmetic safety gates, when block lowering, the full static string arc, and multiple rounds of parity improvements. It is a lot of verified work sitting in a branch.

This is not a technical blocker. It is just a prioritization pattern where new feature work keeps winning over integration. At some point the gap gets unwieldy enough that the merge itself becomes a task worth scheduling explicitly.

Roadmap catch-up

The roadmap on main was last updated 2026-05-18, which is over five weeks stale. Today's daily log branch brought it current by checking off all the submain work through D2.3d: range-check hardening (CR#1-4), arithmetic safety gates, when block lowering, and the full static string series. No new tasks were added since the natural next steps are already represented in existing items.

What is next

The next real frontier is R6: dynamic strings. Everything the JIT handles today involves strings that are fully known at compile time or decomposed into inline print sequences. Dynamic concatenation with runtime operands, string values flowing through non-print expression contexts, runtime string construction -- all of that requires allocation infrastructure, lifetime management, and potentially a new string representation.

That is a qualitative step up from the static subset. The static string work was a series of lowering patterns and host callbacks. R6 means building actual memory management into the runtime.

The other long-deferred item is DotAccess in compound forms, the last unchecked non-string Phase 11 sub-item. It has been predicted in every daily log for over a week and not started. Whether it gets picked up before or after R6 remains to be seen.

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

Cx Dev Log — 2026-06-24

COMMENTERTHE9 — Thu, 25 Jun 2026 00:07:39 +0000

Two significant commits hit submain today, closing out the static string subset for the JIT. D2.3d brings print-time string interpolation and f64 print support, and D2.3c adds compile-time literal string concatenation and content equality. The commit sequence moved our parity numbers from 215/71/0 to 222/64/0 across 286 fixtures—submain is advancing fast.

D2.3d: print-time interpolation and f64

This is the heavyweight commit. We've got print("a {x} b") now breaking down into an inline print sequence during lowering. No runtime string construction here; we're passing literals and values through type-suited intrinsics and completing the statement with a cx_print_newline. The aim? Completely sidestep R6 by avoiding dynamic string allocation.

We diverged from the interpreter in a couple of nuanced areas: shadowed names after exiting inner blocks and handling use-before-declaration. Neither scenario is covered by current fixtures, so it's deliberate, not a silent ship. It's linked to an ongoing interpolation-scoping question we've been nudging down the road.

Five new host intrinsics are onboarded in HostBoundary— cx_print_str_inline, cx_printn_inline, cx_print_bool_inline, cx_print_f64_inline, and cx_print_newline. Normal print behavior remains unchanged.

f64 print also gets support. Now, print(some_f64) takes the cx_print_f64_inline path, aligning with the interpreter's method using Rust's Display. Previously, f64 was completely off the table for print. Updated fixtures t75_string_interpolation and t55_f64_basic confirm byte-for-byte matches with interpreter output.

D2.3c: literal concat folding and string equality

Technically slightly before midnight, this commit went live on June 23. The str + str concatenation collapses compile-time-known operands into one static descriptor at lowering time—employing the static leak mechanism similar to D2.3b, with runtime skipping beyond R6.

For content equality, we added a cx_str_eq(a_desc, b_desc) callback. It handles descriptors by checking length and memcmp. != is simply == negated. String equality checks, like assert_eq, follow this route. Five fixtures transitioned: t_concat_basic, t_concat_chain, t_concat_empty, t_concat_eq, t78_assert_eq_strings.

Static string subset: done

With D2.3d in, our static string subset is complete. JIT now rolls with string literals, compile-time concat, content equality, and print-time interpolation. Anything necessitating runtime allocation—like dynamic concatenation of non-literals—remains deferred to R6. We've defined a clean boundary: no heap-allocated string type, no dynamic work.

Submain gap keeps growing

There's a 22-commit gulf between submain and main. Submain stands at 222/64/0 across 286 fixtures, while main hovers at 230/230. This separation spans 19 days and counting; predictions of a merge have been off for eight straight days. No technical hurdles in sight—submain's ready.

What's next

Next up is R6 (dynamic strings), signaling a big leap beyond static strings. This means allocation, lifetime management, maybe revisiting the string representation. DotAccess in compound forms is the loose end of Phase 11, predicted for eight days now—a start is overdue. The submain merge remains our best low-effort/high-impact move.

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

Cx Dev Log — 2026-06-20

COMMENTERTHE9 — Sun, 21 Jun 2026 00:06:34 +0000

Six weeks without new code might sound like development downtime, but in reality, the Cx project's roadmap had a few cobwebs that needed addressing. Imagine working with an ever-evolving roadmap, only to find out that confirmed work wasn't synchronized with the larger picture. That's exactly what happened with Cx — a six-week lag in roadmap updates was finally reconciled, albeit with no new commits landing.

Roadmap reconciliation

The drift in the roadmap file dates back to May 18, with a slew of confirmed work on submain going MIA from the living document. The gap? Closed today. Essential updates were added, marking the completion of the when block lowering trilogy in Phase 11. While these were previously committed on submain, they hadn't made it to the roadmap:

D1.2a: Unified statement/expression handling
D2.1: If-expression merging via shared branch-value blocks
D2.2: Implemented tag-only enum construct and match using variant_id

Other significant updates include post-release hardening details with the CR#1-4 fixes series, which tighten up range checks. Furthermore, the Gate-1a through 2b JIT safety checks were documented, addressing potential arithmetic vulnerabilities—highlighting the period from June 6 to June 15.

Parity numbers reflected this hidden progress, adjusting from a stale state to current figures: 205/81/0 out of 286 fixtures, with the frontend matrix ticking up from 182 to 230. What does this signify? Real strides in development, previously invisible in the roadmap.

The submain gap continues

Submain is racing ahead, 16 commits beyond the main, devoid of any regressions. Since the last merge on June 5, the gap widened — 15 days of clean contributions still waiting to be merged. This backlog comprises the entirety of the range-check series, all arithmetic safety gates, and the aforementioned when block trilogy, all yet to reach the main.

The merge appears risk-free on paper; yet, it remains in the queue, stuck in development limbo — the ongoing saga of this development log.

The daily-log PR backlog

PRs remain unresolved from June 13 through June 20, continuing the trend of pending merges. Much like the main/submain situation, a backlog of clean and handy PRs waits, grounded in non-technical bottlenecks.

Predictions vs. reality

Anticipations for June 19: DotAccess in compound forms, a submain merge, unknown-value lowering, and clearing the daily-log PR backlog. Result? None materialized. Notably, DotAccess, the remaining to-do for Phase 11, hasn't been initiated despite repeated predictions. This marks it as a likely candidate for priority when development resumes in full swing.

What's next

Priorities steadfastly persist:

DotAccess in compound forms: The solitary piece to complete Phase 11. Clearly marked as the starting point when work kicks back into active gear.
Submain merging to main: Sixteen commits, zero regressions — straightforward.
Unknown-value lowering (D2.x): Marked as a blocker in D2.2's commit notes, critical for test fixtures like t47_edge_mix.
Phase 8 Round 2: Incorporates str/strref layout updates, Handle adjustments, and TBool calling conventions, anticipated post-Phase 11.

Today may have been about documentation cleanup, replacing development with roadmap accuracy. Significant groundwork sits on submain, queued to bring more substantial updates when they inevitably land.

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

Cx Dev Log — 2026-05-18

COMMENTERTHE9 — Wed, 17 Jun 2026 00:09:19 +0000

Two big threads today: the ongoing push towards backend determinism in submain and a solid feature wrap-up that brings the while-in loop full source-to-IR lowering. That while-in loop is finally closing its parity gaps.

While-in Loop Source-to-IR Lowering

Particularly noteworthy is CX-233. It replaces the previous unsupported!("WhileIn") stub with a full-blown lower_while_in_single function. You're looking at roughly 210 lines of new IR lowering in src/ir/lower.rs. This implementation's core is a 5-block CFG: entry, header (where counter comparison kicks in), body (think array element loading via PtrOffset and stride multiplication, followed by storing to start_slot, then executing body statements), increment (adding to counter and looping back to header), and finally, exit.

Here’s what’s interesting technically:

Switching between CompareOp::Le and CompareOp::Lt in the header for inclusive vs exclusive range is what handles range checks. For iterators, the code navigates through then_chains, threading the active block through each lower_while_in_single call, which makes chained iteration click without special routing or exceptions.

On semantics, arr_binding (BindingId) and arr_ty (SemanticType) are passed through the WhileIn AST node and chained thens. Opting to address the array variable with lookup_var during semantic analysis rather than at IR time maintains consistency with other paths' approach to binding metadata.

The tests reflect improvement: WhileLoop parity climbed from 6 PASS / 2 SKIP to 8 PASS / 0 SKIP. t34 (while-in range-based) and t35 (while-in-then) tests are passing. Markedly, this is the introductory ranged iteration construct receiving full IR lowering. This branch with changes sits in origin/stokowski/CX-233, awaiting the green light from the PR review.

Backend Determinism Train Rolling Into Submain

Rolling over to PR #268, we’ve got the train/backend-determinism branch landing into submain. This involves a strategic approach—gather related determinism and parity efforts into a "train" of tickets (CX-223 through CX-230 in this case), then pushing them in with a single merge PR.

That merge is no slouch: affecting 28 files, with host_boundary.rs witnessing the most impact (+2494/-588 lines) due to determinism test suites lining up from multiple instruction categories spanning those tickets. ir/lower.rs gains (+144) while diff_harness.rs follows with (+116), alongside documentation tweaks to JIT's determinism and parity guides.

New Parity Fixtures: CX-228

Inside the train branch, CX-228 delivers a hefty 19 new .cx test fixtures to the verification matrix. Among them:

Direct calls: covering implicit and explicit return, zero-arg runs, chains, forward declarations, and recursive forms.
Unary operations like neg int and not bool.
Various infinite loop models.
Compound assignments within functions.
Builtin assert/assert_eq.
t128 arithmetic quirks.
Constant declarations with block scope shadowing.
Implementation details for basics, return scenarios, and multiple aliasing.

Bumping the fixture tally to t159 through t177 using current test numbering.

The Submain-Main Gap Isn't Shrinking

Submain stands 171 commits forward of main, creeping up from 164 just two days prior. This has hit the radar in each log since May 6, ballooning from 16 on May 7 to 171 at present. There’s no technical blockade for the merge. The matrix is solid at 117 PASS / 0 FAIL; it’s strictly merge lag, yet risk compounds with inaction.

What's in the Pipeline

First on deck is charting CX-233 into submain—a straight, single-commit enhancement clearing the final WhileLoop parity gap. Coming up next, target remaining parity objectives: the VariableDecl, DirectCall, InfiniteLoop, and BuiltinAssert segments still showing SKIPs.

The bridge from submain to main merge remains unresolved. At 171 commits, it’s never been wider for this project.

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

Cx Dev Log — 2026-05-19

COMMENTERTHE9 — Tue, 16 Jun 2026 00:09:03 +0000

No new code landed in the last 24 hours. The activity was entirely infrastructure: a blog post for the May 9 dev log was published to the site, run_matrix.sh picked up an execute-permission fix, and the May 18 daily log was pushed to its branch. The matrix holds steady at 117 PASS / 0 FAIL. Days like this are worth documenting because the project state between commits still matters.

What actually happened

Three commits went out, all from the automated pipeline rather than manual development:

The May 9 blog post (commit 23672a9) was published to origin/site as src/content/blog/2026-05-09.mdx. Content publishing, not code.

The run_matrix.sh execute permission fix (86901ce) was pushed on the daily-log-2026-05-18 branch. Without the +x bit, the test matrix script required manual bash run_matrix.sh invocation instead of ./run_matrix.sh. Small thing, but these permission mismatches cause confusion in CI environments.

The May 18 daily log itself (1c2bd98) was committed and pushed to origin/daily-log-2026-05-18, but the PR was never merged to main. That log documented the real work from May 18: CX-233 (while-in IR lowering), CX-228 (19 parity fixtures), and PR #268 (the backend-determinism train merging into submain).

The while-in branch is ready and waiting

The most significant thing sitting unmerged is CX-233 on origin/stokowski/CX-233. This branch implements while-in loop source-to-IR lowering in a 307-line change across four files: src/ir/lower.rs, src/frontend/semantic.rs, src/frontend/semantic_types.rs, and the parity checklist.

The implementation uses a 5-block CFG: entry, header, body, increment, exit. It threads arr_binding and arr_ty through the semantic layer and adds Op::Mul cursor-deref unary lowering. With this work, WhileLoop parity moves from 6 PASS / 2 SKIP to 8 PASS / 0 SKIP. Once it merges to submain, all loop variants (while, for, while-in, loop/break/continue) will have full source-to-IR lowering.

The remaining unsupported statement kinds after that merge would be When (match/when blocks) and EnumDef.

The submain gap

The submain-to-main gap sits at 171 commits, unchanged from May 18. This number has been tracked in every daily log since May 6 and the growth has been steep: 16 on May 7, 40 on May 9, 164 on May 16, 171 on May 18. With CX-233, the actual divergence is 172 commits.

Nothing is blocking the merge technically. The matrix passes at 117/117. The gap is purely merge latency, and the integration risk grows with every day it stays open.

What's next

The obvious first move is merging CX-233 into submain. It is a clean single-commit PR that closes the last WhileLoop parity gap. After that, the parity targets shift to VariableDecl, DirectCall, InfiniteLoop, and BuiltinAssert categories.

The submain-to-main merge needs to happen. At 171 commits of divergence, this is not something that gets easier with time.

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

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

DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-07-04

The packed-i64 Representation

Handle.val and the Out-parameter Approach

Handle+Array Composition Success

Test Matrix Progress

What's Next

Cx Dev Log — 2026-06-28

The lexer seam

Two-commit split

Interpreter changes

JIT changes

Test fixtures

Other changes

What's next

Cx Dev Log — 2026-06-27

The packed-i128 representation

The ? operator

Example suite rewrite

What's next

Cx Dev Log — 2026-06-26

Static strings are done, dynamic strings are not

The submain-to-main gap keeps growing

The daily-log PR backlog

What is actually next

Cx Dev Log — 2026-06-25

Static strings: done

The merge gap

Roadmap catch-up

What is next

Cx Dev Log — 2026-06-24

D2.3d: print-time interpolation and f64

D2.3c: literal concat folding and string equality

Static string subset: done

Submain gap keeps growing

What's next

Cx Dev Log — 2026-06-20

Roadmap reconciliation

The submain gap continues

The daily-log PR backlog

Predictions vs. reality

What's next

Cx Dev Log — 2026-05-18

While-in Loop Source-to-IR Lowering

Backend Determinism Train Rolling Into Submain

New Parity Fixtures: CX-228

The Submain-Main Gap Isn't Shrinking

What's in the Pipeline

Cx Dev Log — 2026-05-19

What actually happened

The while-in branch is ready and waiting

The submain gap

What's next

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

How `when` Lowering Works