Two hard blockers crumbled today, signaling significant progress in the Cx language project. In one productive session, the test runner found its place on submain, and the complete Result error model passed all tests. With these advancements, our matrix jumped from 78/78 to 90/90. These steps were predicted as imminent in the past eleven daily logs, and today they became reality.
Test runner
Commit 762b188 brought the test runner to life on submain. It introduces two essential functions: assert(cond) and assert_eq(a, b). There's also a new --test CLI mode. These changes touched eight existing files and introduced four additional matrix tests.
Here’s how it works: if the condition in assert is false, the program halts with "assertion failed." For assert_eq, a mismatch results in an expected/got diagnostic halt. Meanwhile, the semantic layer handles the recognition and type-checking for both call types. Wiring for the --test flag was implemented in main.rs.
The four new tests ensure basic functionality:
-
t77andt78verify correct operation ofassert(true)andassert_eqon strings. -
t79andt80ensure thatassert(false)and mismatchedassert_eqcases fail properly.
This achievement cleanly closes the "Basic test runner" hard blocker.
Result error model
The Result implementation was a larger task, affecting 162 lines across 9 source files, and added 16 new untracked test files. These changes aren't committed yet, but they’ve passed all local tests.
Following the spec, the syntax involves Result with angle-bracket delimiters, Ok(val), Err("msg") constructors, and ? for propagation.
The work impacted several layers:
Lexer — Result, Ok, Err now have keyword status.
Parser — Handles Result with </>. Parses Ok(expr) and Err(expr) as primary expressions. ? parses as a postfix operator.
Semantic layer — This area holds many key decisions. Ok(expr) wraps the type in Result, while Err(expr) mandates a string, creating Result. The ? operator ensures that the expression it modifies returns a Result, checking compatibility with its enclosing function.
Runtime — New Value::ResultOk and Value::ResultErr variants were added. The ? operator evaluates: Ok unwraps, Err triggers EarlyReturn(ResultErr(...)). It leverages the existing RuntimeError::EarlyReturn, keeping things neat.
IR — For now, ResultOk, ResultErr, Try, and the Result type are unsupported in the lowerer. This phase mirrors handling for structures, methods, and when expressions.
The eight new tests map key scenarios:
-
t81-t84checkOkandErrreturns,?unwrapping, and propagation across a chain of three functions. -
t85-t88ensure?isn't used outside Result-returning functions, it rejects non-Result values, confirms Result comparison usingassert_eq, and forms thatErrdemands a string, not another type.
Choosing to make Err string-only in this release helps keep the system simple, dodging potential type inference complexities. Type-specific error payloads are a future task.
Branch state
submain is currently five commits ahead of main, up from four yesterday. Recent commits entail wrapping arithmetic, lower-loop handling, UTF-8, semicolon rules, and now this test runner. No merges into main were made in the last 24 hours, with a growing gap over the past week.
What's next
Immediate tasks include committing the finished Result work and addressing the overdue submain-to-main merge. With the test runner and error model resolved, attention turns to := type inference, finalizing diagnostics, and drafting example programs. The roadmap emphasizes that a language release without examples isn't much of a release, so now with most blockers cleared, crafting examples is a feasible next move.
Follow the Cx language project:
- Website: cx-lang.com
- GitHub: github.com/COMMENTERTHE9/Cx_lang
- Dev.to: dev.to/commenterthe9
- Bluesky: thecomment.bsky.social
- Twitter/X: @commenterthe9
Originally published at https://cx-lang.com/blog/2026-04-04
Top comments (0)