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.

Ori v2026.04.14.1-alpha Release Notes

This release focuses on compiler verification and correctness infrastructure: AddressSanitizer support lands for AOT-compiled programs, Alive2 formal translation validation is now integrated into the build pipeline, and a representation optimization bug that could produce incorrect code for narrowed list types is fixed.

Compiler

• AddressSanitizer and UBSan support for AOT programs — Ori-compiled binaries can now be instrumented with sanitizers via ORI_SANITIZE=address,undefined. Compilation is delegated to Clang, which handles sanitizer instrumentation; the Ori runtime (ori_rt) is now also built with an ASan-compatible variant. Use scripts/sanitizer-smoke.sh for a quick 17-program matrix or scripts/sanitizer-full.sh for a full spec sweep. This makes it dramatically easier to catch memory and undefined-behavior issues in programs compiled from Ori source.

• Alive2 translation validation integrated — The build pipeline now includes formal LLVM IR translation validation via Alive2. A curated corpus of 8 functions ships with the compiler (tests/alive2/), and diagnostics/alive2-verify.sh supports per-function verification, full codegen sweeps, and JSON output for CI integration. A false-positive suppression system (9 categories) prevents known-safe patterns from producing noise. Use scripts/build-alive2.sh to build the validator from the pinned LLVM 21 commit.

• Representation optimization narrowing confined correctly — A bug caused integer narrowing from representation optimization to propagate beyond the list storage boundary into adapter code, producing incorrect sign-extension in contexts where the narrowed representation should not be visible. This is now correctly confined to the storage layer. Existing programs with narrowed list types may see corrected runtime behavior.

Bug Fixes

• Invalid sign-extension removed from join trampoline — The join iterator trampoline was emitting a spurious sext instruction on list element types, which could produce incorrect values when element types were narrowed by representation optimization. Fixed, with regression tests covering adapter boundaries for narrowed lists.

Tooling

• Intelligence graph covers sentiment and issue signals — The /query-intel command now surfaces sentiment signals and issue trends from cross-language prior art (open issues, PR discussions). Use query-intel sentiment "<topic>" to get a read on how other language communities have received similar features before making design decisions.

• AIMS formal rule set codified — The rules governing ARC Intelligent Memory System placement decisions (RC elimination, reuse, FIP certification, demand propagation) are now captured in a formal ruleset document (codegen-rules.md). This has no immediate user-visible effect, but it is the foundation for verifying that the compiler's memory decisions are provably correct and will underpin future automated audit tooling.

What's Next

• Optional semicolons after block expressions — A proposal to make trailing semicolons after if/match/block expressions optional has been approved. Implementation will follow in an upcoming release, reducing visual noise in common expression patterns.
• Post-FFI sanitizer tooling — Once FFI lands, sanitizer propagation across the FFI boundary (so C/C++ code called from Ori is also instrumented) is planned as a follow-on.
• Alive2 CI sweep — The curated Alive2 corpus will expand to cover more codegen patterns, with a weekly full-sweep job running against all generated LLVM IR to catch translation-correctness regressions early.

Ori v2026.04.13.1-Alpha Release Notes

This release focuses on correctness throughout the ARC analysis pipeline: a soundness fix to the AIMS lattice, a rewritten contract coherence oracle with richer diagnostics, and a string join memory leak fix. Alongside those, LLVM IR test coverage expands significantly and contributor tooling gains proposal-gate enforcement.

Compiler

• Fixed a soundness bug in the AIMS memory analysis lattice. An anti-monotone rule (Rule 4) could produce incorrect ARC analysis results in aliasing scenarios where the same value was accessed through multiple paths. Removing it and widening Rule 6 restores monotonicity across all reachable lattice states, meaning the compiler will no longer misclassify aliased values and emit incorrect reference-count operations.

• Rewrote the contract coherence oracle with aliasing-aware analysis. The oracle that checks whether FIP/AIMS contracts hold at call sites now tracks aliasing relationships through the full intraprocedural dataflow. When a mismatch is detected, the diagnostic now reports each individual contract violation with its specific cause rather than a single generic error, making it much easier to understand what the analysis found.

• Enriched contract coherence diagnostics. Violations now show per-mismatch detail — which field mismatched, what was expected, and what was inferred — alongside the existing summary. Previously the error offered no breakdown.

Standard Library

• Fixed a memory leak in string join. Heap-backed str temporaries created during the join trampoline path were not being freed. Programs that join collections of strings would leak memory proportional to the number of elements joined.

Tooling

• Added spec and grammar proposal-gate enforcement hooks. Pre-commit hooks now block direct modifications to grammar and spec files unless they are accompanied by an approved proposal. This prevents accidental drift between the spec and the implementation and formalizes the process for contributors proposing language changes.

• Wired cross-language intelligence queries into code review and bug-fix workflows. The /tpr-review and /fix-bug skills can now query a cross-language intelligence graph to surface relevant prior art, similar bugs in reference compilers, and applicable design patterns automatically during review.

Bug Fixes

• Fixed a dispatch order bug in protocol consumers. When iterating over a collection using a protocol receiver, method dispatch could select the wrong implementation if the receiver had mixed ownership. The correct implementation is now selected in all cases.

• Fixed iterator borrow promotion for mixed-ownership receivers. A collection iterator that held a mix of owned and borrowed elements could incorrectly promote a borrow to ownership under certain patterns. The promotion now correctly handles the mixed case.

What's Next

• Iterator element ownership. A tracked issue (filed this cycle) covers missing ownership analysis for certain iterator element types including compound keys. Fixing this will remove a remaining class of incorrect RC operations on collection elements.
• Entry-point diagnostics. A draft proposal landed this cycle for improving error messages at program entry points — covering missing @main, wrong arity, and incompatible return types. Implementation is queued.
• Set<int> support. A blocker was identified and filed this cycle: the LLVM codegen for Set<int> produces incorrect matrix fixtures. Resolving it unblocks a range of collection-type tests currently pinned as negative.