Ori v2026.04.26.1-alpha

This release tightens iterator correctness end-to-end — from type checking through code generation — and improves the precision of several diagnostics that previously pointed at the wrong location or emitted the wrong error code.

Compiler

• flat_map closures now get a precise, well-located error. Previously, passing a non-iterator-returning closure to flat_map either silently miscompiled or produced a confusing "cannot infer type" (E2005) at the call site. The type checker now catches the shape mismatch early and emits E2001 (unsatisfied bound) pointing directly at the closure body. Divergent closures (panic, unreachable, infinite loops) are handled correctly and no longer leave unbound type variables that trigger spurious follow-on errors.

• E2005 ("cannot infer type") messages are now site-aware. Empty list literals ([]) suggest an explicit type annotation (let x: [int] = []). Lambda expressions with an unresolved parameter type narrow the error span to the specific parameter token rather than the entire lambda body. Other expression sites retain the existing wording. This makes ambiguous-type errors actionable without hunting for the right sub-expression.

• Free variable collection now covers all compound types. A silent gap in type generalization caused bindings whose initializers contained Struct, Enum, or Scheme types with free variables to be under-generalized — those type variables were quietly dropped rather than collected. This is now fixed, and the implementation delegates compound-tag traversal to a shared canonical walker so new compound types are covered automatically going forward.

• Codegen adds safety guards at JIT and AOT monomorphization entry points. Secondary assertion hooks now fire if any unresolved type variable survives into the pre-monomorphization IR, attributing the violation to the correct pipeline stage rather than surfacing it deep inside lowering.

Bug Fixes

• Fixed incorrect memory strides in flatten and flat_map for non-pointer-sized element types. The LLVM emitter was passing the size of the iterator handle (always 8 bytes) to the runtime instead of the size of the inner element. This was accidentally correct for int but silently produced wrong-stride memory operations for bool (1 B), char (4 B), and tuples. Both iter.flatten() and iter.flat_map(f) are now fixed; flat_map additionally had a second bug where it used the outer input element type instead of the closure's return type when computing the stride.

What's Next

• Method-level generics and where clauses — A proposal to allow @method<T> where T: Trait syntax directly on trait and impl methods has been reviewed and approved. Implementation work on the parser, AST, and monomorphization keys is the immediate next step.
• Empty container typing — Ongoing work to fully specify and validate how empty list literals, empty maps, and empty sets interact with the type system, including multi-error fault tolerance and JIT/AOT parity.
• AOT iterator test coverage — AOT execution paths for iterator operations currently lack executable test coverage; closing this gap is a tracked near-term priority.

Ori v2026.04.22.1-alpha Release Notes

This release focuses on type inference correctness and ARC lowering reliability, resolving several soundness issues in polymorphic code and closure capture analysis. It also lays down compiler pipeline validation infrastructure that will underpin upcoming codegen hardening.

Compiler

• Fixed type variable substitution in polymorphic code — A bug in how the type checker resolved type variables during substitution caused incorrect unification results in certain polymorphic expressions. The checker now correctly follows union-find roots during substitution, producing accurate type errors and eliminating spurious unification failures.

• Fixed closure capture analysis for nested scopes — body_captures_outer was not correctly identifying variables captured from lexically-outer scopes in nested closures. This could silently produce unsound capture sets. The analysis is now lexical-scope-aware and sound.

• Added codegen seam validation for impl methods — The compiler now enforces pipeline-phase constraints when type-checking trait impl method bodies, catching violations earlier with a clearer error rather than surfacing them as a downstream codegen panic.

• Landed LLVM codegen seam hooks with Result cascade — The LLVM backend now has explicit seam points between compiler phases, with error propagation threaded as Result chains. This makes codegen errors recoverable rather than fatal, improving the overall compilation error experience for programs that hit backend issues.

• Renamed internal bound type variable representation — The compiler's internal type for universally-bound type variables was renamed from Generalized to BoundVar. This change improves the clarity of type-related diagnostic messages and internal error output.

Bug Fixes

• Fixed stack overflow in the test runner when ARC lowering fails — If ARC lowering produced errors on certain inputs, the test runner could recurse unboundedly and crash with a stack overflow instead of reporting the lowering error cleanly.

• Fixed newtype lowering under ARC — Newtype wrappers were not lowering correctly through the ARC pass in all cases, leading to incorrect retain/release placement. Newtype lowering and scheme-body handling are now consistent.

Tooling

• Synchronized documentation to current compiler architecture — Multiple stale references across the compiler design docs, crate READMEs, testing guide, and formatter style guide have been updated to reflect the current CLI flags, module structure, and runtime ABI.

What's Next

• FFI boundary safety — An approved design for safe FFI boundary handling is now moving into implementation. This will give Ori programs principled, checked interop with native code at capability boundaries.
• Polymorphic lambda improvements — Ongoing work on how the type checker handles polymorphic lambdas, particularly around generalization and imported-generic leaks, is nearing completion and will land in an upcoming release.
• Expanded codegen validation — The seam validation infrastructure introduced this release will be extended across more compiler phases, moving the compiler toward catching phase-contract violations as structured errors rather than panics.

Ori v2026.04.17.1-Alpha — Release Notes

This release focuses on type inference correctness, fixing two bugs that caused the type checker to fail or produce false errors on otherwise valid generic and iterator code.

Bug Fixes

• Fixed: fold/rfold accumulator type fails to infer when unused in the closure body. When calling fold or rfold with a closure that never performs operations on the accumulator directly — for example, counting elements into an integer accumulator without referencing its value — the type checker could not resolve the accumulator type and emitted an inference failure. The fix unifies the accumulator parameter type with the return type of fold/rfold so inference succeeds even when the closure body provides no additional constraints. Patterns like iter.fold(0, |acc, _| acc + 1) and cross-type accumulations (e.g., collecting strings into an integer count) now work correctly.

• Fixed: false E2005 "ambiguous type" error inside generic function bodies. The type checker incorrectly reported E2005 for type variables that are legitimate polymorphic parameters of a generic function. This happened because union-find can promote a fresh instantiation variable to the root of a scheme variable's equivalence class, making it look like an unresolved, unbound type — even though it is fully constrained by the function's declared type parameters. Generic functions that left some type parameters unconstrained in the body (but constrained at call sites) were falsely rejected. The fix builds an exempt root set from the function's declared scheme variable IDs before walking the type tree, so polymorphic parameters are never reported as ambiguous.

What's Next

• Iterator trait coverage — continued work on inference correctness across iterator combinators, building on the fold/rfold fix to harden the full iterator protocol.
• Type checker validation hardening — further auditing of the validate_body_types pass to eliminate remaining false positives in generic and polymorphic contexts.
• Bug tracker triage — newly filed issues in the type checker (including a body_type_map duplication) are queued for upcoming cycles.

Ori v2026.04.16.1-Alpha

This release focuses on type checker correctness — specifically, closing gaps in how generic type variables flow through scheme bodies — along with internal compiler infrastructure work that sets the stage for more substantial type checking improvements landing in upcoming builds.

Compiler

• Fixed type variable propagation through generic schemes — The type checker now correctly propagates the HAS_VAR flag from a scheme's body type, as required by the type inference rules. Previously, certain generic definitions could reach validation with their variance flags incorrectly absent, producing misleading or missing errors in downstream checks.

• Fixed validator gate ordering in body type checks — The HAS_ERROR and HAS_VAR gates in the body type validator are now checked in the correct order. The previous ordering could suppress valid type errors in the presence of inference variables, causing some ill-typed programs to pass type checking silently.

• Introduced body type validation pass — A new structured validation pass (validate_body_types) is now wired into the type checking pipeline. This lays the foundation for catching a broader class of type errors in function and method bodies with precise, well-anchored diagnostics.

Tooling

• Fixed intel-query status path resolution — The intel-query tool now correctly resolves the language intelligence graph path when invoked from a Git worktree, fixing a breakage that affected contributors working in multi-worktree setups.

• Per-repo symbol counts in intel-query status — The status output now surfaces symbol counts broken down by repository (Ori + all 10 reference compilers), making it easier to spot indexing gaps or staleness at a glance.

What's Next

• Empty-container type inference — The team is completing the type checking pass for empty container literals ([], {}), ensuring they unify correctly with annotated types rather than defaulting to ambiguous error states.
• Bodies-pass integration — Broader integration of the new body type validation pass into the type checker is in progress, which will surface more precise errors for ill-typed function bodies.
• Documentation sync tooling — A redesigned /sync-docs workflow using batch third-party verification is being finalized to keep language documentation consistently accurate against the compiler's actual behavior.

Ori v2026.04.15.1-alpha Release Notes

This release tightens ARC memory soundness in the AIMS pipeline, corrects type generalization consistency in the type checker, and expands the formal verification suite. The primary theme is correctness: several latent unsoundness issues have been identified and addressed before they could affect user programs.

Compiler

• Type generalization is now fully consistent across all call sites. The rule determining when a let-bound value should be generalized was previously duplicated across three independent locations, making it possible for the same expression to be treated differently depending on how it was elaborated. All three sites now share a single authoritative implementation, eliminating the inconsistency.

• The Alive2 formal verification corpus has grown to 15 functions. Alive2 translation validation now covers a wider set of LLVM optimizations emitted by the Ori backend, including Z3 solver discovery fixes that previously caused some verification runs to silently skip.

Bug Fixes

• Fixed a soundness bug in ARC uniqueness analysis. The AIMS pipeline was applying cross-dimensional uniqueness proofs that could be unsound in certain aliasing configurations — concluding a value was uniquely owned when it was not. This has been removed. Affected programs may see slightly more conservative reference-count operations, but will no longer risk incorrectly elided RC ops.

• Fixed a borrow overlap false negative for unique COW sites. A check that validates borrow lifetimes at copy-on-write mutation sites was not running for values classified as uniquely owned. This could allow a borrow and a mutation to overlap without being caught. The check now applies uniformly regardless of ownership classification.

• Iterator pipeline lowering produces correct output. An investigation confirmed that the iterator pipeline canonicalization path produces semantically equivalent results across interpreter and LLVM backends. No code change was required, but the verification matrix is now in place to catch regressions.

Breaking Changes

• Collection element narrowing has been disabled. Type narrowing applied to elements extracted from collections (e.g., pattern-matched values from a List or Map) was unsound when those elements were subsequently passed through collect. Narrowed types could be used to bypass RC discipline in a way the backend could not validate. Narrowing is now suppressed at collection element sites. Programs that depended on narrowed types flowing through collect will need to add explicit type annotations. A tracked path toward re-enabling this safely (with a sound formulation) is being investigated.

What's Next

• Collection element narrowing re-enablement. The disable was necessary for soundness, but narrowing is a valuable precision tool. Work is underway to design a sound formulation that accounts for the collect aliasing case.
• Empty for-do body handling. A compiler crash when a for-do loop body is empty has been filed and will be addressed in an upcoming release.
• Sanitizer coverage in CI. Address sanitizer and undefined behavior sanitizer builds now have CI infrastructure in place; the next phase is extending coverage across the full spec test suite.