DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-08-03

COMMENTERTHE9 — Wed, 12 Aug 2026 00:23:11 +0000

Eliminating Overhead for Non-recursive Code in Cx: The Cycle-Only Call-Depth Guard

Two host callbacks in every compiled call might sound minor, but they clocked in at about 11 ns per call in debug mode and around 14.5 ns debug-side. That's how our previous uniform call-depth guard in Cx worked—until today. It was effective but indiscriminate. Functions that couldn’t possibly recurse still took the performance hit.

Today’s change makes that a thing of the past: non-recursive code won't face any overhead for stack-depth protection now.

How cycle-only guarding works

So here's what's changed: a function that can't call itself through the call graph won't need a depth counter. Our solution starts by building a static call graph from the IR. This step is crucially done post-lowering to avoid a class of bugs tracked as C1-C4. Using Tarjan's strongly connected components algorithm, we've isolated functions that exist in call cycles. These are the only functions the guard touches.

We've added about 130 lines of code to host_boundary.rs. The core entry point—functions_that_can_recurse()—trims the call graph to module-internal edges only. Here's the catch: host intrinsics like cx_* end chains rather than completing cycles, so they're left out. A function gets the guard if it's part of an SCC larger than one or if it loops back to itself.

An insightful touch: Tarjan's algorithm here runs iteratively, not recursively, ensuring our compiler doesn't eat its own stack while guarding against stack overflows in user code.

Soundness? It’s all about the call graph’s completeness. The absence of indirect calls in Cx secures this. With IrInst::Call.callee being a String, the backend doesn't emit call_indirect, and there's no function or callable type in the language—ensuring every possible call edge is accounted for.

Performance results

Ran the numbers. Measured a few times, took the minimums:

Recursive calls like fib(30) (which stay guarded) showed negligible changes—141 ms to 139 ms in debug and 104 ms to 112 ms in release. Noise. The guard remains for recursives, so no surprise there.

Non-recursive code is where it shines: 6 million calls shifted from 200 ms to 110 ms in debug and from 128 ms to 106 ms in release. The cycle-only guard puts us on par with unguarded calls—103 ms release, 110 ms debug. Non-recursive performance? Back to business as usual.

For guarded functions, a call wears about 3.7 ns. The debug overhead that originally sparked this optim (11 ns/call) was nearly four times what ships.

Inline counter deferred on evidence

Yesterday, swapping the two host callbacks for a declare_data load/add/store sequence was flagged as a follow-up optimization. Not anymore. Cycle-only cuts the guard cost from non-recursive routines, which covers most code. For recursive code, at about 3.7 ns/call in release, it doesn’t merit more fiddling.

Consistently, we measure first, decide second, and document the reasoning afterward.

Test coverage

Our latest fixture, t_mutual_recursion_guard, digs into scenarios beyond self-loops alone—A to B and B to A kind of calls need complete SCC analysis. We've got new tests on self-loops, length-2 and length-3 cycles, non-recursive calls dodging guards, and host intrinsics not being treated as graph edges. Boundary checks hold steady at 255/256 across recursion shapes and backends.

The corpus climbed to 414 from 413 fixtures. Parity ticks up from 373/40/0 to 374/40/0. JIT tests climb to 426 from 425. Clippy stays perfect at 110/110.

State of the repo

Submain sees an advance of 26 commits over main, up from 24. The merge is one step closer, yet not done. The gap's there, and growing.

Merge that to the front, and two 0.3.3 milestones await: array-return lowering and expression receivers. They're on the horizon.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-08-08

COMMENTERTHE9 — Sun, 09 Aug 2026 02:43:25 +0000

Nothing landed today. The last real development commit was on August 2, and the repo has been quiet since then. Clean working tree, no staged changes, no branches moving. The test matrix on main holds at 380 pass, 0 fail, just like all week.

This is day six of the pause. Worth documenting because the state of the codebase itself is interesting right now, even if nothing is actively changing.

What's sitting on submain

The submain branch is 26 commits ahead of main. That gap represents the bulk of what will become 0.3.3 when it merges. The core pieces:

Generic-function monomorphization is the headline feature. Commit 959a980 introduced a worklist-driven instantiation system with a composition cap, living in a new monomorphize.rs module. Each concrete type combination gets its own instantiation. This is the piece that makes generic functions actually compile down to specialized code.

Generic-struct lowering (5dcd548) follows from the same work: one memory layout per instantiation, so Vec<i32> and Vec get distinct layouts.

Gene-bound soundness fix (e105e56) closed a hole where field access through type-parameter bounds was allowed. A gene (Cx's trait-like construct) promises methods, not fields. Accessing a field through a gene bound was unsound because different concrete types behind that bound could have different field layouts. Now it's rejected at analysis time.

Call-depth guards shipped in two forms. The interpreter version (878ba7c) turns recursion crashes into clean diagnostics. The JIT version (664850d) does the same for compiled code. Then ab62a6d (the last real commit, August 2) optimized both: it runs Tarjan's SCC algorithm on the static call graph at compile time and only instruments functions that participate in call cycles. Non-recursive code pays zero overhead for the guard.

Const lowering (6c37339) and exit lowering (3d7a2cd) closed known-issues #12 and #11 respectively. Two long-standing gaps in the lowering pipeline, now handled.

Enforcement-layer fixes (2de51aa, fa95c12) tightened the analysis pass: const immutability is now enforced, and field/variant/loop-counter facts are checked at analysis time rather than relying on runtime behavior.

Each of these features has paired documentation commits and README accuracy passes, so the merge to main should be straightforward. No conflicts are visible.

The pause

Six consecutive days with no development activity is unusual for this project. Nothing in the codebase itself suggests a technical blocker. The submain work is complete, tested, and documented. The merge to main has been the predicted next step since August 2, and it hasn't happened. The most likely explanation is that the pause is external to the codebase.

Thirteen daily-log PRs (July 27 through today) have also accumulated without being merged. These are documentation-only and could be batch-merged whenever things pick back up.

When activity resumes

The merge of submain to main is the clear first move. It brings 26 additive commits into the mainline and effectively constitutes 0.3.3 or the majority of it. After that, two 0.3.3 scope items remain: array-return lowering and expression receivers. Neither has been started yet.

The matrix should stay green through the merge since submain's test additions are all additive. The interesting question is whether array-return lowering or expression receivers will introduce new complexity in the lowering pipeline, but that's a problem for a future log.

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

Cx Dev Log — 2026-07-26

COMMENTERTHE9 — Sun, 02 Aug 2026 17:54:52 +0000

No commits landed today. The test matrix sits at 380 pass, 0 fail on main, same as yesterday. v0.3.2 is stable and nothing moved. This is a status-check log rather than a progress report.

Where things stand

The 0.3.2 release shipped with gene/phen support and has been clean since it landed. The seven documentation site commits from July 24 are still branch-local on site, unmerged. The eight example file rewrites (hello.cx, fibonacci.cx, fizzbuzz.cx, arrays_and_loops.cx, error_handling.cx, generics.cx, structs_and_methods.cx, tbool_uncertainty.cx) have been parked on the daily-log-2026-07-04 branch since late June. Those are tutorial-style expansions: block comments explaining language features, reorganized code for better demonstration, more diverse examples. About 280 insertions and 78 deletions across the eight files.

Neither of these queued items moved today.

0.3.3 scope

The next milestone is scoped but not started. Three items define it:

Array-return lowering. Same ABI-shape work pattern as the struct-return fix from 0.3.2. The approach is established; this extends it to array types.
Generic-function lowering. Bringing T: GeneName bounded generics into the Cranelift JIT path. This is the piece that turns generics from a type-system feature into something that actually compiles and runs.
Expression receivers. Unlocking chained method-style calls and operator expressions on user types beyond the current single-expression restriction.

None of these have started. They carry forward as the primary engineering targets once active development resumes.

Pending cleanup

Two items that could land independently of 0.3.3:

The site branch has seven verified commits from a documentation sprint on July 24. Whether these merge to main or deploy independently is still undecided, but the content is ready.

The example file rewrites have been sitting for roughly a month. They are a self-contained set of changes and could ship as a small cleanup PR without blocking or depending on anything else.

The roadmap's "Last updated" date was corrected from 2026-07-04 to 2026-07-26 today. The content itself had already been reconciled by the 0.3.2 merge (PR #352), but the date line had not been bumped. No substantive roadmap changes.

What's next

The same three predictions from yesterday carry forward unchanged: 0.3.3 implementation work, site branch merge or deployment, and a README feature audit to update sections that still describe pre-gene/phen capabilities. None were addressed today.

When work resumes, array-return lowering is probably the lowest-friction starting point since the struct-return pattern from 0.3.2 provides a direct template.

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

Cx Dev Log — 2026-07-29

COMMENTERTHE9 — Thu, 30 Jul 2026 00:12:29 +0000

Submain sits 12 commits ahead of main, ready for a merge that's been "most likely next" in every daily log for days. If you want to catch a project in a moment of tension, there's no better time. No commits added recently, but in the quiet lies the pushback of a pending decision.

Current State

Main holds strong at 380 passes and zero fails—a pristine test matrix. On its tail, submain checks in at 345 passes, zero fails, but with 51 skips across 396 test fixtures. Despite the skips, nothing's broken. As far as v0.3.2 goes, we're stable post-release after adding gene/phen support, operator overloading, and fixing the struct-return ABI. Not a single regression logged.

The Submain Situation

Let's talk about submain’s restless state, dangling those 12 commits. The work includes some key technical progress like exit and const lowering, a crucial parser guard fix, and a README accuracy pass. Moreover, there's a comprehensive audit pushing the C1-C4 enforcement layer to completion. We've got no visible merge conflicts. All that's missing is a green light for integration—tests are passing, the diff is clean, and yet, the commits remain stranded. Not a blocker in sight, just an unturned page in this project’s log.

Open Issues

Issues are stacking—#15 through #17—with tags since 07-27. These deal with constant-index out-of-bounds and division mishaps, runtime-checked string interpolation, and some diagnostic bugs. No hands have touched them so far. #16 might hold the path of least resistance, promising a cleaner follow-up by relocating validation to the analysis phase. Getting through these would clear some anxieties lying under the surface.

What's Next

The log keeps reiterating the same next steps, and they remain clear:

Merge submain into main. It's straightforward: zero conflicts, twelve commits, all tests clear.
Tackle Issues #15-#17. With #16 being most self-contained, it might deserve a start.
Scope for 0.3.3. Eyeing array-return lowering, generic-function lowering, and expression receivers for the future.

All this while holding strong in a stable post-release calm. The merge of submain and the 0.3.3 scoping represent the next milestones. Making space for untangling those issues could set the stage for forward strides.

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

Cx Dev Log — 2026-07-28

COMMENTERTHE9 — Wed, 29 Jul 2026 00:13:31 +0000

The parity harness has a blind spot. When a test expects failure, any non-zero exit satisfies it, and the JIT's exit-127 trap counts as a clean SKIP. That means a whole class of bugs can hide in plain sight: cases where semantic analysis knows something is wrong, rejects it on the write side, but silently accepts it on the read side. The interpreter runs the wrong program. The JIT refuses it for unrelated reasons. The harness sees green.

Today's work was a systematic audit of that pattern across submain, producing two commits that close four of these holes and a locked design principle that codifies the fix as a rule.

The four holes

All four follow the same shape. Semantic analysis validates a fact when a value is constructed or assigned, but not when it is accessed or used. The result is that the interpreter invents behavior for programs the language should reject.

C1 (struct fields): resolve_field_access() had three copies of the same field lookup, each ending in .unwrap_or(Unknown). Writing a.zzz = 5 on a struct that only declares x made the interpreter invent the field at runtime, exit cleanly, and print 5. The JIT refused it and counted a SKIP. Invisible to parity.

C2 (loop-counter writes): Immutability for loop counters was enforced by a flat scan of the loop body's top-level statements. One level of nesting defeated it. for i in 0..3 { if i >= 0 { i = 99 } print(i) } produced 99 99 99 on the interpreter and 99 on the JIT. This was a live PARITY_FAIL with no fixture covering it. The fix introduces a readonly_bindings: HashSet checked at the same two assignment choke points as reject_const_assignment, keyed by binding ID so shadowing works correctly.

C3 (enum variants): resolve_enum_variant() now provides a single resolver for value position, when patterns, enum-variant arms, and as v arms. Before this, c: L = L::Blue on an enum declaring only Red, Green ran to completion as a phantom variant.

C4 (index/dot on non-container): The lvalue paths for "index target must be array" and dot access on a receiver with no fields already rejected bad programs. Only the rvalue paths fell through.

The predicates are conservative. Unknown, TypeParam, Container, and Handle receivers pass through without rejection, so the new checks only fire when analysis actually knows the answer.

Why the harness missed these

The structural issue is that TestExpectation::Fail is satisfied by any non-zero exit code. When the JIT hits an unlowered or invalid construct, it traps with exit 127, which the harness scores as a clean SKIP. The interpreter, being more permissive at runtime, runs the program anyway and exits 0. Since the test only checks whether both backends agree on pass/fail, a case where the interpreter wrongly succeeds and the JIT wrongly refuses can register as "both handled it" rather than "both got it wrong in different ways."

This is the same structural mistake that produced the f64 comparison bug, the enum equality bug, the width-check gaps, the ordering allowlist issue, and the const-immutability hole fixed last session. Six prior bugs, one pattern.

The locked design principle

The second commit (0ee7766) adds docs/frontend/enforcement_layers.md, a 135-line document that locks the rule: if a fact is known to semantic analysis, semantic analysis rejects it. Any surviving backend check is defense-in-depth only.

This is the project's second locked design principle, after the method-ownership principle in gene_phen_design.md. Locked means it is not revisited per-instance. The document records the choke-point structure, explains why these bugs are invisible to the parity harness, and provides the keep-or-remove decision framework for redundant backend checks.

C2 bypass disposition

The audit found that the interpreter has by-name write paths (read(), input(), multi-alias method write-back) that bypass Stmt::Assign and could theoretically write to a loop counter. These are currently unreachable because the counter is typed t64 and the bypass paths carry str or struct payloads, which means a type mismatch in a different layer stops them. The commit records this as a latent hole that becomes reachable if loop counters ever gain non-t64 types, with an explicit instruction that whoever makes that change must add the runtime guard in the same commit.

New known issues

Three issues were filed, not fixed:

#15: Constant-index out-of-bounds and literal-zero division are decidable at analysis time but currently left to runtime, where the two backends reject them differently.
#16: String interpolation validation is runtime-checked, not compile-checked. The README claimed otherwise and was corrected.
#17: Diagnostics bugs: hardcoded position 0 in some error spans, and % operations reporting / in their error messages.

None of these block release, but #16 is called out in the known-issues doc as the cleanest follow-up target.

What is next

Submain is now 12 commits ahead of main with no merge conflicts visible. The merge has been predicted in every recent log and has not happened yet. Verification on submain stands at 396 fixtures, 345 PASS / 51 SKIP / 0 PARITY_FAIL. Main holds at 380/0.

The 0.3.3 targets (expression receivers, array-return lowering, generic-function lowering) remain unstarted. The most likely near-term work is the submain merge followed by triage on the newly filed known issues.

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

Cx Dev Log — 2026-07-24

COMMENTERTHE9 — Sat, 25 Jul 2026 00:13:28 +0000

v0.3.2 is out. The gene/phen sprint that started six slices ago is done, merged to main via PR #352, and tagged. Submain and main sit at the same commit for the first time since this work began. The verification matrix went from 321 to 380 fixtures, all passing.

The headline feature is operator overloading through an embedded prelude, which is the final architectural piece of the trait system. But the release is really the sum of all six slices: gene declarations, phen implementations, generic bounds, method dispatch, struct-return ABI fixes, and now operator contracts.

The embedded prelude

The capstone commit (e38024e, 526 insertions across 24 files) introduced src/prelude.cx, a 52-line Cx source file that defines eight operator gene contracts: Add, Sub, Mul, Div, Mod, Neg, Eq, and Ord.

This file is compiled into cx.exe via include_str! and injected as the first source unit of every program, before the root file and all imports. It goes through the ordinary lexer-parser-semantic pipeline. There is no filesystem probing, no fallback path, no special syntax. The embedded text is the only runtime path.

This was a deliberate architectural decision (decision 6 from the gene/phen design doc). The prelude is the permanent home for operator contracts, not a stopgap while something else gets built. There is no hardcoded operator-overloading syntax and no parallel system.

Operator-gene dispatch

The new try_operator_gene_dispatch() method in semantic.rs (~240 insertions) handles all binary operators (+, -, *, /, %, ==, !=, <, >, <=, >=) and unary -. When the left operand is a user struct that has a phen for the corresponding gene, the operator gets rewritten to the same MethodCall node that a hand-written a.add(b) call would produce. This reuses the dispatch machinery from slices 3 and 5 with no new mechanism added.

!= is derived as the logical NOT of eq(), matching the Eq gene contract. Types that don't have a matching phen fall through to the existing built-in numeric paths unchanged.

There is one interim restriction: operator dispatch requires a named variable as the left operand. Expression receivers like (v1 + v2) + v3 produce a clean error rather than silently misbehaving. This is a known gap, not a design position. It lifts when method receivers become expressions, which is scoped for 0.3.3.

Prelude injection and collision detection

The resolver now injects the prelude as module ID 0, before all other source units. Gene duplicate detection gained source-location tracking, so if a user redeclares a prelude gene, they get an error that names <prelude>:LINE using the same collision machinery every other declaration kind already uses.

Eight new test fixtures cover the operator dispatch and prelude injection: arithmetic dispatch on user structs, unary neg and equality via genes, all four ordering operators, the expression-receiver restriction error, rejection when a struct lacks an Add phen, prelude behavior with multi-file imports, and collision between user-defined and prelude genes. Four existing duplicate-detection fixtures were updated for the new source-location diagnostics.

The merge and the release

The full merge through PR #352 brought the entire gene/phen sprint into main: 133 files changed, 3301 insertions, 120 deletions. That covers all six slices of gene/phen implementation, the struct-return ABI fix, scope-variable hardening, and audit fixtures.

The roadmap was reconciled in a separate commit (71b5af4). The version sequence now reflects what actually shipped: 0.3.1 included pattern matching, and 0.3.2 contains gene/phen, operator overloading, generic bounds, the struct-return fix, and audit hardening. README status was updated to 0.3.2 with current verification figures: 245 unit tests, 420 with JIT, 380 fixtures, 319 JIT PASS / 61 SKIP / 0 PARITY_FAIL.

Bootstrap intrinsics

One detail worth noting: the built-in numeric paths in semantic analysis (addition, subtraction, comparison for primitives) now explicitly conform to the prelude gene contracts and are marked as bootstrap intrinsics. They are designed for removal. The known gap is that primitives do not yet satisfy T: Add-style generic bounds, since bound checks consult the phen registry and intrinsics are not registry entries. That will matter when generic functions lower through the JIT.

What is next

0.3.3 is scoped with three items:

Expression receivers for method and operator dispatch. This is the most visible gap in the freshly shipped system, and it unlocks chained operator expressions.
Array-return lowering, the same dangling-frame ABI shape as the struct-return bug that was fixed in this sprint. The slot convention needs array-layout awareness.
Generic-function lowering through the JIT. Generic functions with type bounds are semantically complete but not yet lowered.

There is also a pending README content audit. The feature sections still describe 0.2.0-era capability and need a documentation pass covering gene/phen, Handle, pattern matching, and operator overloading.

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

Cx Dev Log — 2026-07-21

COMMENTERTHE9 — Wed, 22 Jul 2026 00:12:06 +0000

Two substantial slices of gene/phen trait implementation just landed on submain. This shifts the needle significantly—contract checking and the capability for phen methods to actually get called at runtime are in the door. Previously, we only had the basic declarations and coherence working but now methods can type-check, Self can resolve per receiver, and calls execute. The submain branch now sits 15 commits ahead of main, holding the matrix at 321/0.

Contract Checking and `Self` Resolution (Slice 2)

Let's zero in on commit fcd3193, which makes waves with 594 insertions across 23 files. The big takeaway is Pass 0 contract conformance. The collect_gene_phen_registry() function now actively validates every phen against its gene. Consider everything from arity to positional parameter types (post-Self substitution), return types, and even checks for both missing and extra methods. If there's a mismatch, it doesn’t just shout—each one is a precise diagnostic identifying gene, method, position, and expected-vs-actual types. It's pinpoint troubleshooting.

The decision to resolve Self at the concrete level before analysis was deliberate. Self in phen signatures and bodies changes to the actual receiver type within the AST thanks to substitute_self_type(). This function even navigates through intricate structures like Array, Handle, and Result wrappers. There was an alternative: treating Self as a floating type parameter. But honestly, it doesn't cut it because types_compatible would unify any type param with anything. Sticking to the design docs, our path—Self is concrete, not a floating parametric.

How about ownership? It's strict. There's no room for unauthorized methods beyond the gene's contract. And we're talking multiple enforcement points: from Pass 0 checks to the phen_methods field on Analyzer triggered during per-file analysis, down to cross-gene-method name collisions caught by Pass 0. Every path specified is locked down, as envisioned by the design docs.

PhenDef’s semantic representation beefed up. SemanticStmt::PhenDef now contains Vec and Vec> instead of just plain method names. Methods undergo scrutiny in temporary scopes just like their impl-block cousins. Testing isn’t left out. We've packed ten new negative test fixtures plus a positive one to exercise every rejection path—think contract arity mismatches, missing and mismatched methods, and more. The positive test? t_gene_phen_contract_ok checks two phens of a single gene with Self in all type positions, acting as a 'leak' canary.

Phen Method Calls at Runtime (Slice 3)

Switch to commit cbb095e. This is the one where phen methods get street-legal, callable status. The insight here: phen methods log into semantic_impls keyed on (type_name, method_name) with receiver bindings—the same data architecture impl-block methods leverage. Therefore, call_semantic_method dispatches phen calls without any tweaks, reaffirming the design doc where phen methods function as full-fledged implementations identical to an impl block's.

Surprisingly, forward-reference support hitchhiked into the build. The pre-registration pass in run_with_interpreter_setup() slots in phen methods right alongside impl methods, seamlessly supporting forward-call breakouts. Picture it—textual call sites preceding phen declarations still dispatch accurately.

Six new test fixtures? You bet. We cover the gamut from basic construct-call-use-return pathways to multi-type dispatch and forward references. We didn’t overlook parity for phen versus impl methods in mutation scenarios, or Self typed params and returns in execution.

Design Decisions Confirmed

These slices pivot around the established design doc rather than veering off in new directions:

Self being concrete, not parametric, echoes decision 3. The t_gene_phen_self_leak_reject fixture underscores this—annotating an Enemy literal as Self in a Player phen remains a type error.
Dispatch mechanics tightly reuse the impl-block pathways, not distinguished at runtime, needs no parallel path.
Tightly enforced method ownership—as per decision 5—across all facets, rigorously tested.

Slice 2 carries a 'rebuild' hint in its commit note, indicating previous rewrites now shelved in favor of the cleaner final version.

What's Next?

Half of our six slices are ready and on submain. We're locked in with declarations, coherence, contract checking, Self resolution, core ownership rules, and interpreter dispatch. On deck are IR lowering for gene/phen constructs (vital for JIT backend handling), operator overloading, and the rollout of generics v3 type bounds, all part of the 0.3.4 roadmap.

Sure, submain is running 15 commits ahead of main, and the merge holds off while the 0.3.4 sprint drums on. Eventually, though, we need to consider the inherent risks of a ballooning batch size. Plus, issue #3 (explicit return paired with trailing expressions) remains open and is currently untouched with attention shifted toward the gene/phen sprint.

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

Cx Dev Log — 2026-07-18

COMMENTERTHE9 — Sun, 19 Jul 2026 00:11:59 +0000

Cx Dev Log — 2026-07-18: A Moment of Pause Before the Next Push

The Cx codebase has taken a breather. It's been quiet for five days, a rarity in the fast-paced world of solo-developed languages. Main is stable at commit 3430e4e, marked by the last 0.3.1 release tag from July 9. Submain's clocked at 3b7b7f8 with the freshly finalized gene/phen design as of July 14. Even the automated matrix stands firm: 321 tests passing, zero failing. But quiet isn't inactivity—it's anticipation.

Where the Project Sits

The significant chunk of work that wrapped on July 14 was hefty: the gene/phen design's v1.1 spec. It doesn't just wrap dispatch strategies; we're talking about cleaner Ord mappings, robust Self resolutions, and handling phen lookups with cross-module coherence. Those are down in a 13-commit series on submain, the product of a thorough hammering out of all six outstanding design questions. But it wasn't just theoretical.

These commits include necessary parser and semantic adjustments, say, coming out of our recent audit. Scoping issues are in check, width-range enforcement leveled up, and we've put any unnecessary comparison errors on Bool/Enum to bed. There's a crucial runtime patch too—no more enum ==/!= crashes blowing up the interpreter. We've also streamlined CI through direct run_matrix.sh runs.

These advances sit 13 steps ahead of main without a single technical barricade to rushing them into action. This delay in merging? It's purely deliberate, not dictated by troublesome conflicts or failing tests.

What's Queued Once Work Resumes

So, what's cooking when the fingers start flying across keyboards again? Here's what's lined up:

Merge submain to main. We've got 13 commits begging for integration. Expect this to be painless, almost ceremonial, since main's been untouched.
0.3.4: Gene/Phen Implementation. The design spec isn’t a riddle wrapped in an enigma—it's a clear blueprint. It's got everything: pass ordering, canonical key formats, robust collision detection, diagnostic frameworks, and essential test fixtures. The specs make the engineering path obvious and actionable.
Known Issue #3. It’s another loose end: explicit return with trailing expressions, tangled in the same territory where #2 was resolved. It's still up for grabs.

On Pauses

A five-day hiatus post-design isn’t unusual, especially for a language crafted solo. Ensuring the architecture's rock-solid—dispatch mechanics, coherence rules, semantics—takes its toll. Patterns being matched in 0.3.2 landed but haven’t seen a tagged release. We’ve got routine release housekeeping next to the real implementation grind.

Call it the calm before the storm. The project isn't at sea without a sail—the framework's in place, and the green-lit test matrix primes us for action. It's just about recharging before the next coding sprint.

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

Cx Dev Log — 2026-07-11

COMMENTERTHE9 — Sun, 12 Jul 2026 02:42:51 +0000

A parser with no changes to its lowering layer fixed a JIT failure. Sounds improbable? That's what we tackled recently in Cx development. Throughout our session, four issues were closed in two subsystems, focusing on correctness and stability, on the submain branch.

The Trailing-Builtin Parser Fix

Consider a print(x) as the final line of a function without a trailing semicolon. Previously, this line would be promoted to a ret_expr by our parser's func_body combinator — resulting in semantic artifacts that disrupted the lowering system. This oversight led to an unsettling "unresolved semantic artifact reached lowering" error.

The solution was a simple yet effective new predicate, is_statement_level_builtin_call(), in src/frontend/parser.rs. It specifically recognizes trailing calls like print, println, printn, assert, and assert_eq, and ensures they're treated as standard statements rather than being prematurely promoted. This fix bypasses unnecessary promotions and channels the calls through the existing lower_stmt dispatcher. Interestingly, this was purely a parser misclassification error, not a failure of the lowering layer.

Here's what changed: 5 JIT-SKIP fixtures are now back in action: t29_forward_decl, t31_strref_forward_combined, t67_macro_outer_test, t68_macro_outer_deprecated, and t_array_elem_arg_in_range. Initially, the prediction was 8, but two fixtures were disqualified earlier in macro processing, and t50_nested_func_no_leak remains on hold. JIT parity advanced from 261/60/0 to 267/55/0.

Scope Boundaries for Control-Flow Bodies

Variables declared within if, else, else-if, while, loop, and while-in bodies were unintentionally bleeding out into the surrounding scope. This problem boiled down to missing push_scope() and pop_scope() calls in src/frontend/semantic.rs. By adding these, we ensured proper scope boundaries.

Four new test fixtures (t179_if_scope, t180_while_scope, t181_loop_scope, t182_whilein_scope) now check that names declared within those bodies aren't accessible outside of them. Previously, incorrect programs could silently pass by misusing variables beyond their intended scope.

Width-Range Enforcement at Missed Sites

In check_semantic_num_fits(), our system ensures numeric values are within target type ranges. However, three assignment contexts were slipping through without these checks:

Variable reassignment (e.g., x = 300 where x: u8)
Array-index assignment (e.g., arr[0] = 300 where arr: [u8; 4])
Method-call arguments (e.g., obj.method(300) expecting a u8)

We addressed each of these scenarios. Six new test fixtures now verify both in-range and out-of-range values across these contexts. It's all about defensive correctness — repairs that should've been in the type system from the start.

Direction

We've consciously shifted focus from the challenging tasks ahead (like known-issues #5 I128 ABI sizing and #4 per-enum tag-to-name tables) toward more tractable correctness fixes. The semantic audit findings and parser adjustments made were straightforward but necessary. This involved four commits, 11 new test fixtures, and the closure of two known issues and two audit findings.

Currently, everything remains on the submain, with main topping at v0.3.1.

What's Next

Submain leads the main by four commits, all with clean fixture runs, setting the stage for a potential merge to main and possibly v0.3.2 in the future. Known-issue #3 (explicit return + trailing expression) becomes the natural follow-up, sitting right within the modified parser framework. Major items, like the I128 ABI and enum tag-to-name tables, will stay on the backburner for now, while we concentrate on feasible victories.

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

Cx Dev Log — 2026-07-10

COMMENTERTHE9 — Sat, 11 Jul 2026 01:14:03 +0000

The v0.3.1 release is finally here, capping off a series of daily logs predicting its arrival. The integration on July 9 brought us more than what was initially scoped, folding in Handle core, pattern matching enhancements, an f64 comparison fix, and a new known-issues tracker. It's been a significant addition, pushing our test matrix from 292 to 321.

What shipped

Handle core (D2.5a/b/c). We've introduced the Handle construct, adding read/val and drop functionality for scalar payloads. This uses a packed i64 representation—slot and generation fields, anchored by a host-side registry. Empirical tests confirm no aliasing on double-drop and generational safety. Nine new test fixtures ensure coverage.

Pattern matching first slices. Originally destined for 0.3.2, enhancements like as v named bindings and guard clauses in when enum arms have arrived early. Guard clauses repurpose existing mechanics, avoiding new control-flow constructs. The additions were well-received, with twenty new fixtures targeting positive behavior and leak rejection.

Interpreter f64 comparison fix. This fix addressed missing Value::Float match arms for comparison operators like <, >, <=, >= in src/runtime/ops.rs. Interestingly, the JIT got it right from the start, reversing an often-seen pattern where the interpreter leads. Five new fixtures ensure correctness.

Known-issues tracker. We've established a tracker in docs/known_issues.md, cataloging ongoing divergences between the interpreter and JIT. The f64 issue is resolved, but others like bare builtin in trailing positions and print issues remain.

The I128 host-boundary finding

The standout technical takeaway? A failed fix on our JIT system. Trying to pass a raw i128 by value proved unsuccessful—it segfaulted. This boundary scenario, untested before, requires a pass-by-pointer strategy instead. This insight, although not immediately operational, is crucial for any wide scalar work moving forward.

Attempting to resolve the print(enum) issue revealed another layer of complexity. It involves setting up tag-to-name tables rather than simple dispatch-arm fixes. This pivot in approach, while unplanned, is necessary for the print parity objective.

State of the project

Following the merge, both submain and main branches are aligned, leaving our working tree clean. 321 tests now pass without failure—a testimony to the release's impact, bolstered by 29 new fixtures.

What is next

Addressing the I128 host-boundary ABI snag is next up, with a sizing pass pinned as our most pressing task. The subsequent task involves implementing the tag-to-name string tables for full JIT print parity. Issues around expression handling (#2 and #3) remain unsized and open, awaiting attention.

For the feature roadmap, the gene and phen design pass is queued for release 0.3.2. However, the timeline is uncertain as multiple pull requests linger, awaiting review.

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

Cx Dev Log — 2026-07-09

COMMENTERTHE9 — Fri, 10 Jul 2026 00:21:18 +0000

No developer commits landed on any branch today. That marks five days in a row. Despite this lull, the matrix remains at 292/0, keeping the working tree clean and submain nine commits ahead of main. These aren't trivial changes waiting in the wings—they're foundational adjustments covering critical components like Handle core, pattern matching, and float comparison fixes.

What's waiting on submain

Let's dive into what's been brewing on submain since the last merge. There are three feature scopes waiting to be seen:

Scalar Handle core (D2.5a/b/c) made some significant strides by introducing construct, read, and drop with proven generational safety via Cranelift. This isn’t just a bunch of lines in code—it's a packed-i64 representation complete with slot and generation fields, a host-side registry, and an out-parameter validity checking pattern. Six test fixtures back up these additions, supporting functionality and correctness.

Pattern matching first slices took an ambitious step by incorporating as v named binding on enum arms and guard clauses on when arms. This might not sound flashy, but it's a crucial move towards making pattern matching useful for real control flow—not merely for type discrimination anymore.

Interpreter float comparison fix addressed four missing Value::Float match arms for relational operators. It’s a straightforward correction, but an essential one, especially for anyone relying on numerical evaluations in the interpreter path. Without it, mathematical consistency would be the first to go out the window.

Alongside these language updates, submain also carries a roadmap reconciliation to fix stale version sequences—ranging from 0.3.1 through to 1.0+—alongside a new known-issues tracker found at docs/known_issues.md. This catalogues five interpreter/JIT divergences. Yet, all of this remains invisible to those on main.

The integration gap

Merging submain to main has been the forecasted step every day since July 4th. But it hasn't happened. Missing the mark five times on the same forecast is concern-worthy.

From an outsider’s perspective, the repository state appears healthy: passing tests, a clean working tree, and finished code on submain. There's no technical debt or failing tests barricading this merge. The real barrier might be review cadence, a confidence threshold, or something unrelated to the repo entirely.

Adding to the backlog, five daily log pull requests (#328 through #332) remain unmerged. Essential roadmap updates, particularly the major restructuring from the July 5th log, haven't reached main. The main-branch roadmap lags behind in its May 18th state, almost two months stale compared to submain’s last update on July 4th. The gap closes once submain merges or any daily log PR lands, but without action, neither clears.

What's next

Carrying predictions forward feels less certain as each day passes:

The submain merge remains the most impactful step we could take. Nine commits, three feature scopes, roadmap reconciliation, and a known-issues tracker—all poised to deliver significant updates once merged. Known issue #5 (I128 printing) is primed and waiting—needing just one match arm plus one host callback for completion. Plus, at least one daily log PR could independently help update the main roadmap without relying on the full submain integration.

The repeated inactivity isn't inherently alarming. Software development seldom moves in a straight line, and holding patterns are par for the course. However, the gap between submain's accomplishments and main's current state widens with each passing day. Merging grows more complex as the branches diverge further.

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

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

DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-08-03

How cycle-only guarding works

Performance results

Inline counter deferred on evidence

Test coverage

State of the repo

Cx Dev Log — 2026-08-08

What's sitting on submain

The pause

When activity resumes

Cx Dev Log — 2026-07-26

Where things stand

0.3.3 scope

Pending cleanup

What's next

Cx Dev Log — 2026-07-29

Current State

The Submain Situation

Open Issues

What's Next

Cx Dev Log — 2026-07-28

The four holes

Why the harness missed these

The locked design principle

C2 bypass disposition

New known issues

What is next

Cx Dev Log — 2026-07-24

The embedded prelude

Operator-gene dispatch

Prelude injection and collision detection

The merge and the release

Bootstrap intrinsics

What is next

Cx Dev Log — 2026-07-21

Contract Checking and Self Resolution (Slice 2)

Phen Method Calls at Runtime (Slice 3)

Design Decisions Confirmed

What's Next?

Cx Dev Log — 2026-07-18

Where the Project Sits

What's Queued Once Work Resumes

On Pauses

Cx Dev Log — 2026-07-11

The Trailing-Builtin Parser Fix

Scope Boundaries for Control-Flow Bodies

Width-Range Enforcement at Missed Sites

Direction

What's Next

Cx Dev Log — 2026-07-10

What shipped

The I128 host-boundary finding

State of the project

What is next

Cx Dev Log — 2026-07-09

What's waiting on submain

The integration gap

What's next

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

Contract Checking and `Self` Resolution (Slice 2)