DEV Community: COMMENTERTHE9

Cx Dev Log — 2026-03-31

COMMENTERTHE9 — Thu, 02 Apr 2026 00:06:07 +0000

Nothing shipped today. No compiler changes, no spec updates, no runtime work. The only commits in the last 24 hours were automated documentation: yesterday's blog post on site and the daily log branch for March 30. The working tree is clean across all branches.

This is the first fully idle day in a while, so it is worth taking stock of where things actually stand.

The submain gap, day five

The submain branch is still 4 commits ahead of main, unchanged since March 27. Those commits represent real, landed work:

Wrapping arithmetic enforcement
Phase 10 while loop lowering
UTF-8 string encoding decision locked
Semicolon rule refinement

All four are meaningful. The while loop lowering is backend progress. The wrapping arithmetic commit tightens numeric semantics. The UTF-8 and semicolon commits are spec-level decisions that close hard blockers and unblock downstream work.

None of it is on main yet. The merge has been predicted every day since March 27 and has not happened. The roadmap versions have diverged further: main is on v4.7, submain is on v4.6, and there is a v4.8 floating on an unmerged daily-log branch. Each day the gap sits, the docs/frontend/ROADMAP.md conflict gets slightly worse. It is not a crisis, but it is accumulating friction for no clear reason.

Hard blockers holding steady

The test runner and assert infrastructure have now gone eight consecutive days with no movement. Same for the Result error model. Both are listed as hard blockers. Both keep getting predicted as "next" and keep not happening.

To be clear, these are not blocked by technical dependencies. The spec decisions that needed to land first (UTF-8, semicolons) have landed, at least on submain. The test runner needs implementation work: a way to discover and run test functions, and a basic assert mechanism. The error model needs a design decision on Result semantics and then implementation. Neither is waiting on anything except someone sitting down and doing it.

Matrix status

78/78, unchanged. The frontend test matrix has been stable for over a week now. This is good in the sense that nothing is regressing, but it also reflects the lack of new work. New features or parser changes would be expected to temporarily bump or stress the matrix. Flat stability for this long just means nothing is moving.

What is next

The same list as yesterday, honestly:

Merge submain to main. The most straightforward action item. Four commits, one known roadmap conflict. Should be a 10-minute task.
Test runner and assert. Hard blocker, eight days deferred. This is the thing that would most change the project's development velocity if it landed.
Error model. Another hard blocker with extended inactivity.
Backend work. If/else lowering and struct layout are the natural continuation of the backend progress that already landed on submain.

Yesterday's predictions all missed. None of them happened. Today had zero language development activity. Whether tomorrow breaks the pattern or extends it will say a lot about the project's current momentum.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-03-25

COMMENTERTHE9 — Wed, 01 Apr 2026 00:05:23 +0000

Two major threads converged today in the Cx language project, making a significant technical leap forward. The IR backend refactor has finally merged into main, transitioning the Backend trait interface from raw AST to a more robust IR. Simultaneously, over at submain, a newly introduced 301-line module resolver is set to redefine how we handle dependencies, circular imports, and topological sorting.

IR is now the backend interface

March 24th saw the successful merge of PR #19, a union of four commits that ushered in Phase 0.5 of our backend architecture changes. The crux? Moving the Backend trait from using &Program (AST) to &IrModule (IR). With this one-way door, all backend development now requires IR input, no turning back to the AST-based approach. Cranelift and LLVM backends received immediate updates in response.

The additional commits introduced vital debugging tools for the IR pipeline. These might not seem groundbreaking, but when you need to diagnose a validation failure, having an automatic IR module dump can save a lot of headaches. There's also a new --backend=validate mode crafted for running IR lowering and validation sans any codegen backends. For a more granular look, the --debug-trace flag will now print each IR instruction as it gets emitted during lowering. These utilities make working on the IR pipeline significantly less of a chore, particularly with upcoming complexities like loops and structs.

Module resolver on submain

The module resolver emerged as submain’s headline contribution. Clocking in at 301 lines, resolver.rs constructs dependency graphs, shines with circular import detection, and supports path-based topological sorting. Through ModuleId, ImportEdge, ResolvedFile, and ResolvedProgram, it ensures a verified process for relative ./ paths, and caps recursion depth at 100. Note that std/ imports without a local file aren't supported in v0.1 and will raise clear errors immediately.

The resolver has now threaded into main.rs, positioned squarely between parsing and semantic analysis. For single-file programs, you'll notice no difference. But when it comes to multi-file programs, missing imported files prompt clear error messages instead of cryptic failures.

A third notable addition, the ExportTable struct arrived in semantic_types.rs, complete with maps for functions, structs, consts, and enums. This sets the stage for robust cross-file symbol resolution. Public symbols in a resolved module now populate the export table, effectively allowing importing files to reference them using alias.symbol.

Tests t65 and t66 on submain intentionally flipped to expected_fail to reflect the resolver's accuracy. On main, they would erroneously pass due to lack of meaningful import resolution.

Design choices worth noting

Building a real dependency graph was a deliberate choice despite the extra effort. It offers more than simple file loading by providing stable module IDs and import edges necessary for dead symbol elimination and circular import detection in the future. Possible ../ path traversals are permitted but will be managed better beyond v0.1.

What's still in progress

Everything implemented today resides in submain, pending a merge request to integrate onto the main branch. The ExportTable is present, yet it doesn't populate during analysis. Up next is populating the export table with symbols from the topologically ordered files, making these symbols available to files through alias mapping.

Tests t65 and t66 are yet to tackle real-world, multi-file test programs. Creating these programs, like stubs for player.cx and std/math, would help validate the full resolver-to-execution flow.

What's next

The next big milestone? Bringing submain’s resolver and ExportTable onto the main branch. Prioritizing the integration of ExportTable into semantic analysis is vital for fully functional multi-file support. On the IR frontier, turning our attention to loop and struct lowering is crucial now that the debugging tools are in place and the backend expects &IrModule.

The good news? The test suite stands firm with 72 out of 72 tests green, signaling no regressions from today’s work.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-03-30

COMMENTERTHE9 — Tue, 31 Mar 2026 00:16:43 +0000

Two spec-level decisions have landed on submain today. The UTF-8 string encoding model for Cx is locked, and the semicolon rule has been defined with more precision. Neither commit introduces a new feature, but they remove blockers by clarifying design decisions. The current progress holds at 78/78 in the matrix.

UTF-8, locked everywhere

The debate over string encoding is concluded: Cx is strictly UTF-8. Here’s what that means:

All source files must be in UTF-8.
str values must be valid UTF-8 at runtime, or they trigger an error.
char refers to a Unicode scalar value.
Binary data? That's for byte buffers, not str.

This decision is now documented in Section 25 of docs/cx_syntax.md and checked off as a completed hard blocker on the roadmap. No changes to runtime or compiler code here—this is a purely spec decision. Yet, it's significant because it paves the way for critical stdlib and filesystem work. Without a locked string encoding model, defining file I/O or string manipulation functions was impossible.

The decision deliberately mirrors Rust's approach—no room for Latin-1 fallback, no WTF-8, and no byte strings pretending to be str. For a systems language that aims for predictable string behavior, this choice makes sense. The design space is now firmly closed on this front.

Semicolon rule refinement

The semicolon policy got stricter yet remains unresolved. A single parser edit at src/frontend/parser.rs:377 now permits declaration semicolons to be optional using .then_ignore(semi.clone().or_not()), but expression statements still need them.

The logic isn't complicated: since the parser lacks newline awareness, it sees x + 1 in an expression statement context as ambiguous. Is it a complete statement or part of something larger? To avoid ambiguity, semicolons are required for expressions—without rewriting the parser.

The roadmap now includes an updated Known Gaps entry that shifts from a vague note on inconsistent behavior to a specific outline of the workable and non-workable bits. The goals for fully optional semicolon syntax are officially postponed beyond version 0.1, pending a newline-aware parser redesign.

This transparency about design and implementation shortfalls doesn't mask the situation. The commit essentially lays bare where the project stands and why it isn't quite there yet.

Spec-tightening phase

Today's contributions lean heavily on documentation rather than code. The UTF-8 commit involves no code changes, and the semicolon tweak is a single line paired with documentation updates. This indicates that the project is in a spec-tightening phase—locking choices, documenting limits, and finalizing design questions instead of cranking out new features.

It's a sensible focus. The frontend matrix remains stable at 78/78. Backend operations, like scalar layout, have previously been solidified through ABI work. Upcoming challenges like the test runner and error model benefit from a settled spec foundation.

The submain gap

These updates are on submain, which is now four commits ahead of main. Other recent commits address arithmetic wrapping and while loop lowering initiated earlier. None of these have merged into the main branch yet. The roadmap has diverged (version 4.7 on main versus 4.6 on submain), hinting at merge conflicts ahead in docs/frontend/ROADMAP.md.

This marks the fourth day in a row where a predicted submain-to-main merge hasn't happened. While it's not blocking anything critical now, the unresolved state only risks complicating future merges.

What is next

Clearly, the merge is the immediate priority. Beyond that, ongoing hard blockers like the test runner and Result error model have lingered without progress, tailing a week of predicted advancement without payoff. On the backend, if/else lowering and struct layout present logical targets for upcoming work. We'll soon see whether the project remains in spec-tightening mode or shifts back into full implementation.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-03-26

COMMENTERTHE9 — Mon, 30 Mar 2026 00:13:51 +0000

Multi-file imports actually work now. Yesterday, the parser could read the #![imports] syntax, but nothing happened at runtime. Today, 10 commits on submain have built a complete pipeline: file resolution, dependency graphing, semantic merging across file boundaries, and runtime dispatch. The first multi-file Cx program runs end to end.

The import pipeline

Three critical commits form the core of this work. We have module alias resolution now wired into analyze_method_call in semantic.rs, making method calls on imported module aliases resolve correctly through the module's export table. A new function, analyze_resolved_program, now exists in semantic.rs. This function takes a ResolvedProgram from the resolver and performs unified semantic analysis across all files in topological order. Importantly, main.rs has been updated to use analyze_resolved_program. The pipeline now looks like this: parse, resolve imports, topo-sort, semantic merge, runtime dispatch.

In the resolver module (src/frontend/resolver.rs, 301 lines), the graph infrastructure covers ModuleId, ResolvedFile, ResolvedProgram, ImportEdge, circular import detection, and topological sorting. Although this infrastructure came from earlier submain commits, it ties cohesively into today's semantic and runtime developments.

Testing with t74_import_basic.cx proves the concept by importing t74_import_basic_lib.cx and successfully calling math.add(10, 20) and math.multiply(3, 4) across the file boundary. This is the first multi-file program compiling and running in Cx. We're also testing pub enforcement. The test t64_import_pub_only specifically checks that only pub-marked functions have visibility across import boundaries — the resolver is enforcing visibility rules effectively.

Audit pass and cleanup

Post-pipeline deployment, an audit caught five semantic and runtime bugs in parser.rs, semantic.rs, and runtime.rs. Corrections involved small fixes (+22/-11 lines) addressing correctness-related issues.

We also removed dead code from the old interpreter path across 8 files. Functions like Print and PrintInline, along with a few others like Range, Placeholder, and wait_for_step, were stripped from ast.rs, diagnostics.rs, parser.rs, semantic.rs, semantic_types.rs, lower.rs, main.rs, and runtime.rs. These were leftovers from an earlier phase.

Test infrastructure improvements

Improvements to our test infrastructure include enhancements to the matrix runner (run_matrix.sh) for output verification. Now, tests with a .expected_output sidecar file compare actual results with expected outputs, reporting PASS (output verified) or FAIL (output mismatch) instead of just exit codes. Two sidecar files shipped with this change (t75 and t76).

Six new tests have been added to submain:

t64_import_pub_only — Testing pub visibility enforcement.
t74_import_basic — An end-to-end test for two-file imports.
t75_string_interpolation — validates {varname} expansion in print statements.
t76_block_comments — testing block comment syntax.

Today, our submain matrix sees perfect results — 78/78 tests passing, compared to 72/72 on the main branch.

Documentation sync

Our documentation has caught up with the current state of the language, with six files updated: ROADMAP_v3.1.md, cx_backend_roadmap_v3_1.md, backlog_notes.md, cx_flags.md, cx_syntax.md, and docs/frontend/ROADMAP.md. The syntax reference saw the most changes (+158 lines) as it reflects everything we've built since its last update.

The submain roadmap (v4.5) is now marking significant progress milestones like struct field type checking and method call return type resolution as complete. There's a version misalignment between main (v4.6) and submain (v4.5) that we'll address when reconciling these branches.

The submain gap

While all of these changes are branch-contained, submain is currently 13 commits ahead of main. We haven't merged them in the past 24 hours. The multi-file import pipeline is blocking 0.1 right now, and it's ready on the branch. We've added 6 tests, fixed bugs, cut dead code, and synced docs, but all this waits in limbo.

What's next

Merging to main is overdue. Holding 13 commits of working, tested code introduces greater risk with each passing day. Moving forward, we need to improve the test framework and assertions (#[test], assert(cond), assert_eq(a, b), cx test). The error model (Result) still blocks 0.1 and needs progress. Backend IR work, specifically loops and structures in the lowering pipeline, has been deferred multiple times for front-end fixes.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-03-27

COMMENTERTHE9 — Sun, 29 Mar 2026 00:21:22 +0000

Scalar layout definitions and ABI design—sounds routine, right? Except this time, our Cx language backend takes a significant leap forward. The Phase 8 Round 1 commit introduces the first formal ABI groundwork focusing on scalar layout and ABI documentation, assigning a solid design-first methodology.

Scalar Layout and the ABI Document

The latest commit lands on submain, adding 134 lines across two files, most notably docs/backend/cx_abi_v0.1.md. This document is where the scalar layout for Cx's integer types (t8, t16, t32, t64, t128), f64, and bool is locked. Details like size, alignment, representation, and how they map to Cranelift types are stipulated.

The alignment model follows natural alignment principles, meaning each type aligns according to its size. For example, t8 aligns to 1, t16 to 2, and t32 to 4. This choice simplifies the design for x86-64 and mirrors what typical C compilers produce. Right now, there are no packed or special alignment modes.

There's one crucial thing: i128 is emulated using two i64 values instead of having native support, as it would in LLVM. Not a hurdle for correctness but a known performance consideration.

On the coding side, we see new size_bytes() and align_bytes() methods added to IrType in src/ir/types.rs. Seven unit tests, each focusing on different scalar types, now ensure that sizes and alignments are correctly handled. These are strictly Rust-level tests—not touching the main testing matrix, which sits impeccably at 72/72.

Design-First Mentality

This phase marks a shift to documenting before implementing—a design-first mantra. The ABI document locks some scalar layout decisions with accompanying tests, marking them as LOCKED, whereas OPEN marks those awaiting further exploration.

Among the interesting OPEN topics:

TBool Representation involves complexities with its three-state value (true/false/unknown) handling across function calls.
String Layout in JIT Mode and Struct Layout require alignment and padding rules that need drafting.
Array and Enum Layout are potential upcoming challenges.
Copy Parameter Convention remains undecided for call handling.

This approach sets a clear path and helps prevent technical debt accruing from hasty, undocumented choices.

The Submain Gap

Despite putting substantial work into submain, the main branch hasn't seen these fruits yet. Now stacking up to thirteen commits including the multi-file import pipeline—critical for the 0.1 release—plus bug fixes and additional tests, submain is becoming the storehouse of progress. The import pipeline is particularly vital and ready but sits awaiting integration.

What's Next?

With the scalar layout solidified, the focus shifts toward more nuanced decisions like struct layout and TBool representation, mostly because these elements already have a presence in the frontend. However, the need to merge submain to main grows pressing, especially with pending tasks like the test runner and assert infrastructure still blocking essentials for the 0.1 release. Similarly, the error model (Result) is crucial yet stalled.

Steps from here involve wrapping up the backend tasks and addressing these blockers, possibly setting the stage for the next major release.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-03-24

COMMENTERTHE9 — Thu, 26 Mar 2026 00:12:06 +0000

The macro system and #![imports] syntax just landed, paving the way for more complex multi-file programs and new attribute-driven function features in Cx. The recent commit (cda45f7) merged as PR #17, introduced these key changes, complete with nine new matrix tests (t65-t73) all passing. This marks a big step, as the total matrix tests jumped from 63 to 72.

What shipped

Key changes affected 8 source files and brought in 9 additional test files. In total, 22 files changed, with +210 and -13 lines. Here's the breakdown:

Lexer changes. Introduced two new tokens: MacroInnerOpen (#![) and MacroOuterOpen (#[). The existing PunctBracketClose token now serves as the closing delimiter for both.

Import block parsing. A new ImportDecl AST node with alias, path, and position arrives alongside a Stmt::ImportBlock variant. This allows the parser to handle the #![imports] block properly:

#![imports]
math: use "std/math"
player: use "./player"

import_decl and import_block combinators now parse these alias-colon-use-path structures within the block.

Import semantic validation. The system now catches duplicate aliases and enforces path restrictions, allowing only ./ (relative) and std/ (stdlib) paths. This is strictly syntax validation for now; actual file loading and resolution aren't implemented yet. Syntax first, resolution next.

Outer macro parsing. Added CxMacro enum to the AST with six variants. Each outer macro, whether simple #[name] or #[name(args)], is parsed by the single_outer_macro combinator. A new macros: Vec field now sits under Stmt::FuncDef.

Outer macro semantic validation. Enforcement rules in place:

No return types for #[test] functions.
#[reactive] and #[cfg] produce locked "reserved, post-v0.1" errors.
Unknown macro names are immediately rejected.
#[test], #[inline], and #[deprecated] tags are allowed on functions.

Matrix tests. Comprehensive testing covers all macro and import behavior:

t65: Basic imports parsing in block
t66: Standard library paths imported with std/
t67: #[test] attribute in functional context
t68: Using #[deprecated] attribute
t69-t73: Various rejection and validation scenarios (expected fail tests)

Design decisions

Import syntax, not resolution. #![imports] parsing and validation exist, catching any mishaps, like duplicate aliases or invalid paths. But without file loading, multi-file programs can't yet run. Validation leads, resolution follows.

Structured outer macros. Only six outer macro types exist. No extension yet in Cx 0.1, with #[reactive] and #[cfg] specifically reserved for later.

Test capabilities are building up. Parsing and validation happen for #[test], but no runner operates yet. Likewise, std/ paths parse, but resolution lags. These elements are inching toward a full Cx test system, piece by piece.

Roadmap movement

Must Ship tasks now check off #![import] block parsing. Macro and Import syntax's sprint status recently turned Done. Syntax implementation is complete, pushing module resolution into Active, though heavier work on file operations and detection remains.

We face two tough blockers: effective multi-file import functionality and fully functioning test runner development. The syntax aspect is rolling, but multi-file execution isn't yet seamless.

What's next

Tackling module resolution tops the list. Ensuring use "./player" brings actual player.cx file content to the importer is essential, involving public symbol resolution and accessibility.

The processes around the test runner and assert support are very close on the heels. Parsing of #[test] is there, and implementing assert(cond) and assert_eq(a, b) next, alongside cx test, would clear this blocker.

Generic structs Phase 3 and backend IR Phase 6 remain queued behind macros and imports work, ready to move once the immediate priorities settle.

Nine new tests now mean 72/72 pass, from a previous 63/63. Zero backward steps.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-03-23

COMMENTERTHE9 — Wed, 25 Mar 2026 00:10:23 +0000

The big story today is that Cx has revamped its entire IO structure. Gone are the days of print, printn, read, and input being treated as special cases in the lexer and parser. Now, these are unified under function syntax, marking a significant shift along with the completion of Phase 1 and 2 of generic structs, introduction of string interpolation, and stdin built-ins. This update, encapsulated in PR #15, closed four critical blockers for the 0.1 release, pushing forward with a test matrix now showing 63 green tests.

Print Promoted to Function

This was the major structural change everyone is talking about. KeywordPrint and KeywordPrintInline have been removed from the lexer's vocabulary. We’ve deleted 47 lines of combinator spaghetti from the parser that were handling print statements. Now, print and printn are parsed as Expr::Call, making them akin to any other function call. printn has been duly registered as a built-in within call_semantic_func.

While the transition was largely smooth, we had to tweak the call_arg parser to better handle nested calls and method calls when they appeared as arguments. So, 47 parser lines out, 11 runtime lines in. This transformation unexpectedly resolved a longstanding issue with the t42 TypeParam-vs-Struct ambiguity, a clash existing since generics v2. It turned out that print as a keyword was creating parsing conflicts that no longer exist with it being a standard function call. As a result, we removed the expected_fail marker on t42.

String Interpolation and Stdin Built-ins

String interpolation is finally here. By utilizing the expand_interpolation method in the runtime, placeholders like {varname} within string literals are expanded when printing. Importantly, variables not recognized within these placeholders simply pass through unchanged, providing a predictable output especially during the initial development phases.

We’ve also introduced built-in functions for standard input operations. read(var) reads a line from stdin directly into a variable, and input("prompt", var) first prints a prompt before reading. This keeps the consistency with our redesigned IO surface, confirmed by test t60 covering basic read operations using this interpolation syntax.

Generic Structs Phase 1 and 2

Phase 1 ushered in type_params for Stmt::StructDef and SemanticStmt::StructDef. Our parser can now handle syntax like struct Foo { field: T }, allowing the analyzer to correctly resolve type parameters. During field analysis, current_type_params are set, while a struct_type_params registry tracks them methodically. Tests t61 and t62 validated basic generic struct definitions and instantiation using f64.

With Phase 2, AstValue::StructInstance now supports Vec type arguments. Consequently, the parser now understands Pair<t32> { ... } instantiations, and we updated all StructInstance match sites to accommodate this expanded form with three fields. Test t63 thoroughly tested explicit type argument instantiation.

However, some gaps remain, specifically type arguments in variable type annotations (p: Pair<t32>) and enforcement of generic field type checking, both marked for follow-up despite their current lack of implementation.

Dead Code Cleanup

Goodbye to unnecessary code. We’ve stripped out the enum group runtime infrastructure, including EnumRuntimeInfo, the enums field on RunTime, and super_group_handler_index. These components were purely write-only and no longer had a purpose as SemanticWhenPattern now supports all when-group matching needs. This cleanup freed 37 lines from runtime.rs and 8 from main.rs. It follows closely on the heels of our recent 790-line AST interpreter removal, further reducing the codebase and emphasizing the newfound dominance of the semantic path.

What's Next

Up next, we're eyeing Phase 3 of generic structs: tackling type arguments in variable declarations and enforcing checks on generic fields. Multi-file imports remain a tough nut to crack for 0.1, with syntax locked in but functionality yet to be implemented. Although backend IR tasks like loop and struct lowering were scheduled, they did not land; however, the IO unification has cleared a prerequisite hurdle for backend work involving calling conventions.

Our test runner and assertions (assert(cond), assert_eq(a, b), test blocks) are open blockers that demand attention, although no progress has been made there yet.

As it stands, the test matrix is solid at 63/63 with no regressions. We'll keep pushing 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-03-23

Cx Dev Log — 2026-03-22

COMMENTERTHE9 — Mon, 23 Mar 2026 02:42:22 +0000

The Cx project just had its most significant update yet, pushing over 25 non-merge commits onto submain. Let's break down what's been accomplished: the closing of four major blockers, the removal of the old AST interpreter, substantial backend IR progress reaching Stage 3, and the expansion of our test suite to ensure stability.

Four hard blockers knocked out

Getting these blockers cleared has been pivotal. First up, the f64 type keyword (commit 7c1768d) has traversed the entire pipeline, from lexer to runtime, confirmed by test t55. This paves the way for the numeric functionalities in our 0.1 release.

Next, const declarations (a7ece34) arrived with literal-only initializers. We've also imposed a restriction against reassignment, covered by tests t56 and t57. Along for the ride is the pub keyword, marking a step forward for export visibility.

The new value-producing when (d24b462) means when blocks are now usable as expressions—a major flexibility gain shown effective in test t59.

Lastly, when block-body arms (e0f989e) have moved from a gap to a verified feature (test t58 backs this up). Each feature is live and tested with no regressions in sight.

Saying goodbye to the old AST interpreter

The burden of maintaining a synced parallel execution path via the old AST interpreter is now lifted. The execution path (eval_expr ~314 lines, run_stmt ~462 lines) was axed in commit cdffec7. This means about 790 lines of dead code were removed from runtime.rs. Additional cleanups followed, with dead code like FuncDef and friends getting the boot, making the codebase leaner.

Full-speed-ahead code quality

This sprint was more than a cleanup; it was refinement. Function bodies shifted to Arc storage (0c0cb8a) to eliminate unnecessary clone overhead. Reducing redundancy, semantic_type_to_ast was streamlined with a proper From for Type implementation.

We merged print_value and print_value_inline into one value_to_string function (878029a).

Two macros, unsupported! and unsupported_type! (5819185, 14c63e5), optimized 35 match arms. Similarly, sem_err! (f8e021d) decreased 51 SemanticError constructions to concise one-liners.

Another noteworthy addition is SemanticType::Void (642a327), enabling void function calls to type-check correctly through semantics and IR.

Backend IR: Elevating function call logic

Backend advancements are noteworthy. Phase 6 Stage 2b (a6d7701) introduced direct function call lowering, complete with validation mechanisms in ir/lower.rs. Moving swiftly to Phase 6 Stage 3 (ee2c357), cross-function call validation is now solid, resolving callees and verifying function signatures comprehensively.

An IR pretty printer is queued up in src/ir/printer.rs, offering a textual representation for debugging—a critical tool for developers that's already in development and under testing.

Integrating the progress

PRs #9 through #14 have aligned main with submain as of 642a327, setting the stage for the next pushes. Yet, there are three commits still residing locally: two related to Phase 6's different stages and one involving documentation cleanup.

The test matrix renumbering (d8cf3ef) closed duplicate issues and filled gaps. We also tidied up with ample housekeeping: stale files, leftover branches, gitignore contradictions, and unused worktrees were removed, tuning the project for more efficient progress.

What's on the horizon

Top priority remains the IR printer—it's the key piece yet to be committed, essential for stable backend debugging. As the phase nears an end, the on-deck IR lowering objectives include loops, when blocks, and structs. Beyond these, the roadmap targets multi-file imports, the fleshed-out error model, transitioning print to a function, and solidifying UTF-8. Of those, multi-file imports loom largest for completion before the 0.1 release.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-03-19

COMMENTERTHE9 — Fri, 20 Mar 2026 02:42:52 +0000

Semantic Interference Complete: Cx Runtime Hits Major Milestone

The verification matrix now shows a perfect 47/47, indicating that every test passes with the runtime executing fully through SemanticProgram. This marks the end of raw AST interpretation for all supported constructs. Semantic interpreter Phase 2 just landed with two significant commits on submain, marking a major milestone on the path to version 0.1.

What Landed

Two pivotal commits took the verification matrix from incomplete to flawless.

The first major commit (369a2e9) involved 693 net insertions across 9 files, fundamentally altering the runtime. The execution now primarily uses run_semantic_stmt and eval_semantic_expr in runtime.rs, which process SemanticStmt and SemanticExpr instead of raw AST nodes. We've introduced a semantic_funcs registry that holds SemanticFunction objects for correct dispatch. Handle operations like HandleNew, HandleVal, and HandleDrop have realized true arena semantics. Method calls, struct instantiation, enum matching, and all forms of control flow are now processed through the semantic pathway.

On the analyzer side, semantic.rs gained awareness of generic parameters and solved the age-old ambiguity between TypeParam and Struct for bare identifiers—always parsing them as Type::Struct and resolving to TypeParam in generic contexts. The jumble around duplicate StructDef handling was sorted this time, and new IR nodes (IfElse, WhileIn, SemanticWhileInChain) were established as essential semantic types.

Additionally, main.rs was revamped so run_with_interpreter could take SemanticProgram directly. There’s a new pre-pass that registers structs, functions, and impl blocks from semantic IR, bridging function registration between semantic and legacy registries amid ongoing migration.

That commit shot the matrix up to 44/47. Three complex failures lingered in deeper stubs.

The second commit (c730bd7) was smaller but packed a punch with 69 net insertions over 4 files:

Introduced recursive array element coercion in types_compatible.
TypedAssign finally uses current_type_params, ensuring generic variable declarations resolve correctly.
A new function, substitute_type_params, resolves generic return types at the call site—making sure fnc identity(x: T): T called with an i64 returns SemanticType::I64.
SemanticType::Array(usize, Box) now exists, giving array types a complete path—declaration, assignment, function return, and type compatibility.
Handle operations in the runtime were upgraded from stubs to live implementations with stale detection through RuntimeError::StaleHandle.
A parsing order fix positioned handle_drop and handle_val before method_call, addressing a precedence issue where handle syntax was mistakenly consumed as method calls.

Key Decisions

Arrays as First-Class Citizens. Previously, arrays were basically a wild card with SemanticType::Unknown, raising havoc with type checking. With the new Array type, they flow through the semantic process transparently.

Generic Return Type Substitution. This happens at call sites, not definitions, preventing broken downstream type checks when dealing with generic function results.

Real Handle Operations. The runtime now effectively manages handles with actual arena operations, closing the gap between IR and runtime behavior.

Parser Ordering and Handle Syntax. Initially, the parser was greedily munching handle syntax as method calls. The fix addressed the priority to handle this correctly.

Current State

The submain branch remains unmerged with main. It's two commits ahead, along with previous work from structure sprints, operators, generics v1, and semantic parity Phase 1. The merge looms larger and more hazardous the longer it's delayed, with 1578 insertions and 1959 deletions across 35 files to consider.

While the old AST interpretation code persists, it's no longer in use and its removal is the final check under the Semantic/Interpreter Parity on the frontend roadmap.

What's Next

Immediate tasks are clear-cut. Merging submain into main will enable CI to run against our true language state. Once the dormant AST interpreter path is axed, semantic parity will be officially closed. Following this, the path to 0.1 is wide open: multi-file imports, generics v2 finalization, and backend Phase 6 (focusing on function call lowering) can advance on a stable semantic ground. The backend work, in particular, stands to gain tremendously from a firm semantic layer, allowing confident consumption of the semantic IR.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-03-18

COMMENTERTHE9 — Thu, 19 Mar 2026 02:42:49 +0000

The biggest piece of work happening right now in Cx is Semantic Parity Phase 2: migrating the interpreter from raw AST execution to running off SemanticProgram. No commits landed today, but there are 782 lines of uncommitted changes across 9 files in the wonderful-saha worktree. The interpreter migration is being written. Here is where things stand.

The semantic interpreter exists

The core of the work is in src/runtime/runtime.rs, where a full semantic IR interpreter has been written. New methods -- eval_semantic_expr, run_semantic_stmt, and call_semantic_func -- implement expression evaluation and statement execution against SemanticExpr and SemanticStmt types instead of raw AST nodes.

The RunTime struct now has a semantic_funcs registry (HashMap) alongside the existing function registry. This is a dual-registry setup, and that is deliberate.

In src/main.rs, run_with_interpreter now accepts SemanticProgram instead of Program. The pre-pass that registers structs, functions, and impl blocks has been rewritten to work with SemanticStmt variants. Function registration bridges both the semantic and legacy registries so the old copy/bleedback fallback behavior still works during the transition.

This is not a clean swap. It is a staged migration. Both the old AST function registry and the new semantic function registry run at the same time. The old paths remain as fallback, which means the 45-test matrix does not have to pass through the new interpreter all at once. Work can land incrementally.

Control flow gets first-class IR nodes

As part of this migration, IfElse and WhileIn have been promoted to first-class nodes in both the AST and the semantic IR.

In src/frontend/ast.rs, new statement variants for IfElse and WhileIn were added along with a WhileInChain struct for cursor iteration chains. The corresponding SemanticStmt::IfElse, SemanticStmt::WhileIn, and SemanticWhileInChain variants were added in src/frontend/semantic_types.rs.

Previously these control flow constructs were handled through more general paths. Giving them dedicated variants in both layers makes the semantic IR complete for control flow. That is a prerequisite for the interpreter to run entirely off the semantic IR without falling back to AST interpretation for certain constructs.

Groundwork for generics in the semantic layer

A smaller but notable change: the analyzer's semantic_type_from_decl now takes a generic params slice, and analyze_function gains a type parameters argument. Duplicate StructDef handling was removed. This is not the generics work itself, but it prepares the analyzer for generics-aware semantic analysis. It came along naturally while reworking the semantic layer for the interpreter migration.

Branch state

Submain still has not been merged into main. This was flagged yesterday and remains the case. Main is still missing structs, operators, and Semantic Parity Phase 1 from the March 17 work. The wonderful-saha worktree branches from submain, so until submain merges, none of this Phase 2 work can reach main either.

The branch situation is straightforward but it needs to be resolved. Two feature branches are stacked (submain, then wonderful-saha on top of it) and main is behind both.

What is next

The immediate path forward has two threads:

Finish the semantic interpreter migration in wonderful-saha. The interpreter is largely written, but the bridge between old and new runtime paths still needs work. Once the full test matrix passes through SemanticProgram, the raw AST interpretation path can be removed.
Merge submain into main. This unblocks everything downstream. Until it happens, the real development state of the language lives on feature branches rather than main.

On the backend side, Phase 6 (function call lowering) is next on the roadmap. No work started on it today, but it can proceed in parallel once the branch state is cleaned up.

Follow the Cx language project:

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

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

Cx Dev Log - 2026-03-17

COMMENTERTHE9 — Wed, 18 Mar 2026 02:43:23 +0000

Bringing control flow to a compiler and shipping a more feature-complete frontend branch in one day changes the landscape for the Cx language project.

Backend Phase 5: Control Flow Takes Shape

We nailed the largest lump commit in backend history on codex/backend-ir-from-main. If you looked under the hood, you'd see 2,559 insertions across three files. Most notable are the 1,656 new lines within lower.rs and the creation of validate.rs with 1,052 lines.

Prior to this, IR was pretty much linear—a straight shot from start to finish. Now we’ve integrated true control flow graphs. This means we've got conditional branches, explicit blocks for then/else/merge, and chaining for else-if clauses. Critical here is how SSA (Static Single Assignment) environments are split and merged, ditching phi nodes in favor of block parameters especially for merge points. This shift wasn't new—it harks back to decisions made in Phase 1, but today marked its real-world test and validation. It's cleaner, lighter on bookkeeping, and passed through branching logic without a hitch.

We’ve also dealt with dead branches elegantly, ensured branch-specific temporaries work seamlessly, and the validator is up to scratch for multi-block functions and a synthetic main routine.

Let's not overlook the validator overhaul itself. This beast of a file includes over a thousand lines of checks, making sure nothing slips through unnoticed. Mismatching IR or malformed structures are caught immediately—a necessity as we expand capabilities without trialing features in the wild before they're tested.

Submain: A Frontend on the Brink of Change

Over in the submain branch, three distinct commits moved the needle further than ever, elevating submain above the main for now.

Starting with structs, the first two development phases landed in one go, stepping through 19 files across the pipeline. Struct definitions, instancing, reading/writing fields—it's all there. Add in method dispatch via impl blocks, including mutations propagated back to callers, and you're looking at robust support for compound assignments like p.health -= amount, facilitated by a new AssignTarget enum helping differentiate variable versus field targets. Three verification matrix tests ensure these changes don't break anything: impl_basic, impl_return, and compound_assign_dot.

A smaller change, but significant, added != and unary ! operators while also tidying up process exit codes to properly signal errors. Negative testing got a boost with .expected_fail markers, and run_matrix.sh entered as the definitive test runner.

Last up, we tackled Semantic Parity Phase 1. This translates frontend structures into the semantic layers fully, covering constructs from StructDef to MethodCall. Important note—while some paths still rely on the raw AST, this phase preps everything for the full semantic shift later.

Every change passed the verification matrix with greens across all tests—nothing broke.

Why It Matters

Submain is standing as the proving ground for frontend consolidation. It’s about gestating feature changes together and deploying them as coherent units. Today’s push exemplified this as structs, semantic improvements, and operator handling merged into submain.

Incremental semantic parity is the name of the game. We pinpoint types and analysis, leaving the interpreter with the raw AST for now, but eventually, that dependency will dissolve post-parity verification.

The Road Ahead

The endgame is merging these branches, both carrying critical updates. Submain’s structural and semantic parity features need to meet main, clearing the way for further semantic work. But there’s backend momentum too, heading into Phase 6 which involves function call lowering, allowing these lowered functions to communicate fully—arguments, validations, the works. Keep an eye on Semantic Parity Phase 2, as it transitions from the raw AST to a SemanticProgram for interpretation. These advancements will run parallel until convergence in main, pushing Cx to new heights.

Follow the Cx language project:

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

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

Cx Dev Log — 2026-03-16

COMMENTERTHE9 — Tue, 17 Mar 2026 02:43:37 +0000

Generics v1 has officially shipped. This isn't a halfway parser prototype; it's full-stack coverage straight from parsing, through semantic analysis, to runtime, with three verification tests. Plus, GitHub Actions CI went live—built and debugged in just four commits.

Generics v1

Our implementation tangled with six files: ast.rs, parser.rs, semantic.rs, semantic_types.rs, lower.rs, and runtime.rs. We introduced Type::TypeParam at the AST level and SemanticType::TypeParam in the semantic layer, integrated type_params in FuncDef, SemanticFunction, FunctionInfo, handled `parsing, and ensured type consistency at call sites. Thetypes_compatiblefunction now transparently handlesTypeParam`.

Testing isn't a hand-wavy success story. We ran three specific tests: t37 for basic generic function calls, t38 for generic array returns using [N]T, and t39 for scenarios with multiple arguments sharing a type parameter. This was all achieved with just 88 insertions—mindfully compact, while ensuring full compiler layer interaction. We intentionally scoped to single type parameters: no struct dependencies or bounds. This keeps v1 lean, laying the groundwork for v2 (multi-parameter support) and v3 (bounds) without refactoring core principles.

CI from zero to green

Our GitHub Actions CI came online with commit 1514c16, designed to run a 113-line workflow managing frontend and backend verification, including a stale-base gate. The CONTRIBUTING.md rolled out alongside, laying out four branch rules for collaborators, whether human or automated.

We hit two bugs right off. First, an unintentional Windows target-dir in .cargo/config.toml inserted a C:\Users\Gabri\cx-build path separator error on Ubuntu runners. That was cleaned up quickly. Secondly, merge commits to main tripped the branch protection guard, failing CI until we exempted these from the branch name check.

These hiccups revealed a key point: development primarily happens on Windows, but CI runs on Ubuntu. Platform-specific path issues like our target-dir snafu are precisely why cross-platform CI exists. Detecting these on day one is a win.

Documentation and infrastructure

A busted memory_safety.md link was culled from the README. The roadmap pushed to v3.1, mapping out the arrival of generics v1, CI status, next steps for structs, and generics v2's graduation to active development.

Meanwhile, on the site branch, we started testing an automated blog post notification setup via Telegram. Though not quite production-ready, the foundational work is underway.

Backend IR: stashed, not abandoned

Right before generics and CI merged into main, we stashed backend IR development. An ir/validate.rs module and associated imports were part of this pause, intended to streamline merging stable features. Function lowering is progressing; next in line is working if/else constructs into the process.

What's next

Naturally, generics v2 takes precedence. Multi-type-parameter support (fnc swap(a: A, b: B)) is already noted as active. Thanks to the v1 groundwork, the parser extension needed here is minimal.

Another live effort is in our backend IR stream. We'll pick back up on the validation module where progress left off. These projects work on distinct compiler layers, so they can operate simultaneously.

Now with CI, regression is not an optional diagnosis—it's actively policed. This adjustment in our workflow marks a genuine shift to proactive error detection before main 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-03-16