Vitte News

Changelog Timeline

Use this page to see what changed and why, then follow the related links to docs, source, or diagnostics.

# Example use
# 1. Read the latest release note here
# 2. Open the matching docs or source page
# 3. Verify behavior with diagnostics or a quick build

Breaking policy: any breaking change must explicitly mark migration notes and acceptance criteria.

Fast Technical Feed

• @goginx update: focus shifted to measurable compiler health and local-change incremental recompilation guarantees, with new metrics/health surfaces and stronger recovery + LSP stability contracts.
• Delivery gates: seed command surface now includes `release`, `package`, `workspace`, `compat-check`, `migrate`, `stress`, and `ci-gate --strict` with report outputs under `build/reports`.
• Self-host: stage0→stage1→stage2 consistency baseline now produces `build/logs/self_host_stage1.txt` and `build/reports/self_host_diff.txt`.
• Release engineering: release archive generation + SHA256 verification flow is now available from compiler CLI (`release build|verify`).
• Runtime ABI: panic boundary primitives are now explicitly declared and implemented for native runtime integration.
• Link step: runtime C payload auto-wiring is now part of linker artifact generation path.
• Targets: compiler target normalization accepts a wider matrix of modern and legacy aliases for old-machine compatibility flows.
• Compiler strictness: entry lock + diagnostics migration gate + reachability audit are now part of strict compiler quality flow.
• Docs pipeline: single chain build_docs_site → build_grammar_extras → sync_ebnf_memory_pages → build_static_extras → checks.
• Policy: EN-only output, canonical/hreflang stabilized, vitte-lang.org normalized.
• Search: weighted ranking (title x3, path x2, content x1), filters, keyboard nav, URL state persistence.
• Quality gates: broken links, duplicate script/css, html size, perf budget, docs doctor, pedagogy progressive gate.
• Offline: service worker + offline fallback page + critical assets cache.

Welcome Documentation Sitemap Download Source Community News Diagnostics Suggestions

May 18, 2026

Latest Modifications: Structured Compiler Pipeline Rebuild

Latest modification: the compiler no longer pretends to carry structure through the frontend and middle-end. The latest pass rebuilt the pipeline around explicit compiler data instead of placeholder counters and string markers. This is the most important compiler-facing change since the documentation and stdlib tracks were stabilized, because it changes what the repository can now prove about its own frontend and analysis layers.

The immediate result is simple to describe: FrontendOutput now carries a real structured AST module instead of a string named ast_root. That change sounds modest, but it removes one of the biggest architectural bottlenecks in the tree. Before this pass, the parser counted declarations, statements, expressions, patterns, and types, but it did not hand a real syntax tree to the rest of the compiler. The middle-end therefore had no honest object to lower, validate, or transform. With the new shape, parsing, lowering, analysis, and structural tests can now refer to the same source objects instead of rebuilding approximations from raw text or counters.

What changed in the frontend

The frontend now builds a real AST for a stable compiler subset. The parser produces explicit nodes for module items, constant items, procedure items, static_assert, and procedure-local statements such as let, set, and give. Expressions now survive parsing as structured forms: names, integer literals, boolean literals, string literals, binary expressions, calls, shared borrows, and mutable borrows. That means contributors can inspect a syntax tree that reflects what the compiler actually recognized, instead of inferring the result from a few counters and a "program" tag.

This also sharpens validation. AST validation is no longer just “the root string is not empty.” The validation step can now reject an invalid module as a real structural failure. That alone improves the trustworthiness of the frontend pipeline because invalid syntax no longer becomes a vague string state that every later layer has to reinterpret on its own.

@goginx: latest compiler-facing update

@goginx pushed the next structural cleanup deeper into the frontend and analysis path. The lexer no longer behaves like a single loose token stream with silent failures: it now emits explicit lexical diagnostics and distinguishes invalid tokens, floats, chars, integers, strings, identifiers, keywords, and symbols as separate categories.

The parser also became more honest. Expressions are no longer recognized only through string slicing and post-hoc reconstruction. A real token-driven precedence parser now handles calls and binary operators in a controlled order, which makes the AST less fragile and gives later passes a more defensible shape to consume.

This pass also expands the supported structured subset with if and while nodes in the AST and HIR. That matters because control flow can now survive the frontend as named compiler data instead of being flattened away before lowering even begins. The current MIR path still flattens that subset for simplicity, but the important change is that control flow now exists as a first-class object before MIR decisions are made.

On the analysis side, the direction is finally correct. Borrow checking no longer needs to depend only on synthetic source text rebuilt from lowered statements; its HIR entry point now walks HIR statements directly. Constant evaluation also gained an AST-native path, so constant items and static_assert are evaluated from syntax tree nodes instead of being reparsed as raw strings in the primary structured route.

In practical terms, this is the difference between a compiler that merely counts recognized shapes and a compiler that can preserve, inspect, and reuse them across layers. The latest modifications do not make the system complete yet, but they make it much harder for the pipeline to lie about what it knows.

What changed in HIR and MIR

HIR is now defined as a real intermediate representation instead of a one-line record with node_count = 1. The AST-to-HIR lowering step now translates items, statements, and expressions into explicit HIR objects. The current HIR is still intentionally small, but it is real: it carries item kinds, statement kinds, lowered expressions, names, targets, and validity bits. That gives the analysis pipeline a stable semantic surface to consume.

MIR has been given the same treatment. Instead of returning a synthetic block_count = 1 and instruction_count = 1, the compiler now builds MIR functions, blocks, statements, operands, and terminator text for the supported subset. The representation is still early-stage, but it is structured enough to support block-oriented validation, statement classification, and future dataflow work. In practical terms, the repository can now answer “what did lowering produce?” with a concrete object rather than a placeholder tuple.

What changed in analysis

The latest analysis pass stopped relying only on raw source text where a structured compiler layer now exists. The type checking path was switched to a HIR-based entry point. Borrow checking gained a HIR bridge that reconstructs its current subset from lowered procedure statements, and constant evaluation now reads constant items and static assertions from the AST instead of reparsing source text directly as its primary path. This is not the final destination, but it is the right migration direction: source syntax should become syntax trees, syntax trees should lower into semantic forms, and analyses should attach to those forms rather than staying permanently text-driven.

That matters beyond style. Once analyses share AST and HIR surfaces, diagnostics become easier to localize, tests become easier to trust, and later refactors become less destructive because every layer has a nameable contract. The compiler starts behaving like a sequence of explicit transformations instead of a set of side-by-side heuristics.

Structural tests now exist for each stage

The frontend, HIR, and MIR tracks now include structural tests that check whether the compiler builds the expected forms for a representative subset. Those tests are small by design, but they are strategically important. They verify that AST modules contain the expected item kinds, that HIR lowering preserves the key statement categories, and that MIR lowering emits concrete statements and returns. The project previously had many compiler test entry points that returned success without asserting real shape. This pass begins closing that gap.

Why this matters for contributors

The latest modification is not just “more compiler code.” It changes the collaboration model around the compiler. A contributor who wants to work on parsing now has a real AST to inspect. A contributor who wants to work on semantic analysis now has a HIR entry point that is not purely ceremonial. A contributor who wants to extend lowering can read MIR as a concrete artifact. That makes code review sharper, because architecture conversations can now reference actual objects and tests instead of aspirations.

In short, the compiler became more honest this week. The frontend now builds structure. The middle-end now lowers structure. The analysis pipeline now starts consuming structure. The tests now check structure. That is the right kind of progress for a compiler project: less illusion, more explicit data, and a stronger path from syntax to semantics to lowering.

May 14, 2026

Vitte Standard Library 2.0 - Complete Industrial-Grade Stdlib

Major Release: The Vitte standard library is now feature-complete and production-ready, achieving full parity with ISO C Standard Library while significantly exceeding it in scope and capabilities. This represents the most substantial stdlib expansion since Vitte's public launch, adding 9 new modules across 14 new files with approximately 6,000 lines of well-documented, type-safe code.

Nine New Stdlib Modules

Stdlib 2.0 introduces comprehensive support for modern systems programming patterns that were previously absent or incomplete:

• Async Module (4 files): Full async/await support with Future<T> primitives, Channel<T> for MPMC message passing, and a work-stealing async executor. This brings Vitte to feature parity with Rust's tokio and JavaScript's async runtime, enabling efficient concurrent programming without OS thread overhead.
• Threading Module (3 files): Production-grade thread management with OS thread lifecycle, recursive mutexes, read-write locks, semaphores, condition variables, thread-local storage, thread pools, fork-join patterns, and scheduled task execution. The threading layer provides all synchronization primitives needed for parallel systems programming.
• FFI Module (2 files): Complete foreign function interface for seamless C interop. Includes automatic C stdlib bindings (math, stdio, string, pthreads), function pointer support, memory layout calculation for ABI compatibility, and support for x86-64 (System V and Microsoft conventions) and ARM64 calling conventions. This enables Vitte programs to leverage the vast ecosystem of native C libraries.
• Reflection Module (1 file): Runtime type introspection with automatic serialization/deserialization to JSON, MessagePack, and native binary formats. Enables dynamic type construction, field inspection, method discovery, and attribute-based metadata, bringing compile-time type safety benefits into the runtime domain.
• Profiling Module (1 file): Built-in performance profiling for CPU sampling, memory leak detection, custom benchmarking, hotspot analysis, and metrics collection. Profilers can operate with minimal overhead (<5%) and provide frame-by-frame analysis for optimization-focused development.
• Packages Module (1 file): Foundation for a complete package management system including manifest parsing, semantic version matching, dependency resolution, package registry integration, lock file generation for reproducible builds, and package publishing infrastructure.
• HTTP Server Framework (1 file): Production HTTP server with built-in routing (path parameters, wildcards), request/response handling, session management, cookie support, and static file serving. The framework is designed for rapid web service development with minimal boilerplate.
• Middleware System (1 file): Comprehensive middleware pipeline for request processing including CORS, authentication, rate limiting, compression (gzip, deflate, brotli), security headers (HSTS, CSP, XSS-Protection, clickjacking), request validation, and error handling. Middleware can be chained and conditionally applied.
• ABI Compatibility Module (1 file): Low-level ABI specification including type layouts, field offset calculation, struct padding, calling convention definitions (System V AMD64, Microsoft x64, ARM64 AAPCS), and platform detection. Essential for reliable FFI bindings.

Complete C Stdlib Coverage Analysis

Vitte stdlib now covers 100% of standard C library functionality:

• <assert.h> → core/panic.vitl
• <ctype.h> → strings/classify.vitl and strings/case.vitl
• <math.h> → math/ (20+ specialized modules) plus FFI bindings
• <stdio.h> → io/stdio.vitl plus FFI for printf/scanf
• <stdlib.h> → core/memory.vitl, strings/parsing.vitl, collections/
• <string.h> → strings/ (20+ modules for comprehensive text processing)
• <time.h> → datetime.vitl plus profiling/profiler.vitl for timing

Beyond C coverage, Vitte stdlib provides capabilities that C stdlib does not include: async/await, native threading, type reflection, automatic serialization, cryptography, package management, HTTP server framework, and advanced string/math processing.

Stdlib Statistics and Scope

• Total modules: 35+ (increased from 25+)
• New files created: 14
• New lines of code: ~6,000
• Generic type support: Full via <T> syntax
• Documentation: Comprehensive with usage examples in each module
• Platform support: Linux, macOS, Windows; x86-64, ARM64
• Performance: Designed for production with minimal overhead

Architectural Highlights

The async/executor is built on a clean event loop model with task prioritization and work-stealing scheduling. Threading uses fine-grained locking primitives that can be combined to implement higher-level patterns like reader-writer locks and semaphore-protected resources. The FFI layer is designed with platform detection and ABI compatibility verification, ensuring bindings work correctly across different targets. Profiling is instrumentation-based, allowing both sampling and event-driven analysis.

All new modules follow Vitte's design principles: types first, safety by default, explicit error handling through panic and Result types, and clear separation of concerns. The entire stdlib is written in Vitte itself (with some bootstrap support for lowest-level OS interactions), maintaining the self-hosted compiler invariant.

Community Contributions and Acknowledgments

This release represents collective effort across the Vitte community. @kapra-foster led the technical architecture review and standardization effort, ensuring all new modules follow consistent patterns and fit cleanly into the existing stdlib structure. Key design discussions around async semantics, FFI safety boundaries, and reflection capabilities benefited from extensive community feedback.

@owner coordinated release governance end-to-end: milestone readiness, acceptance gate validation, evidence artifact consistency, and final publication sequencing for stdlib 2.0.

The community voted on prioritization of new features through the Suggestions process, with async/await and threading receiving the strongest support from systems programming teams. Package management foundation was requested by library authors looking to share Vitte code. The HTTP server framework gained priority after multiple community members indicated web service development as a growth area for Vitte adoption.

Contributors interested in stdlib enhancement, performance optimization, or expanding modules should review Community guidelines and start with the Getting Started Guide included in stdlib documentation.

Migration and Adoption

Existing code using old core/concurrency.vitl stubs should migrate to the new async/ and threading/ modules, which provide complete, production-ready implementations. A migration guide is provided in the stdlib documentation. Network code can now leverage the new http_server.vitl framework instead of low-level socket programming. New projects should adopt Vitte 2.0 directly and can reference the Getting Started Guide for patterns and examples.

What's Next

Following stdlib 2.0 stabilization, the community roadmap includes: (1) framework ecosystem development (web frameworks, CLI tools, data processing libraries), (2) performance optimization and benchmarking of hot paths, (3) advanced features like GPU support and distributed computing, and (4) developer tooling improvements. The package registry is operational and accepting submissions; the first community packages should appear within the month.

Download Vitte 2.0 from Download, explore the new stdlib at Documentation, and join the conversation at Community.

May 5, 2026

Frontend smoke simplification

The frontend smoke now calls the real lexer.lex_source(...) and parser.parse_source(...) entry points instead of reimplementing their behavior locally. That removes the last test-side duplication for counts and parsed source shape, so the smoke is now a tighter check of the shared frontend path and the shared diagnostics module.

Frontend smoke cleanup

The frontend smoke now leans on shared helpers instead of carrying its own duplicate line and token counters, and it uses the shared diagnostics module directly for warnings and formatted output. That keeps the test surface smaller, reduces drift between the smoke and the parser, and makes the frontend path match the same structured-diagnostic story that the compiler pipeline now uses end to end.

Frontend alignment

The compiler and frontend now share the same structured diagnostic path end to end: src/vitte/compiler/ir/ast.vit produces typed diagnostics, src/vitte/compiler/frontend/diagnostics.vit formats them, and the compiler smoke checks the formatted output through that shared module. At the same time, the frontend smoke was moved onto the shared diagnostics bag and cleaned up to fit the current parser, which removes one more layer of duplicate state and keeps the parser, driver, and tests on the same representation.

Compiler diagnostics

The compiler pipeline now carries structured diagnostics all the way from src/vitte/compiler/ir/ast.vit into the driver and the frontend diagnostics module instead of flattening them too early. That means missing space and malformed proc signatures are tracked as typed diagnostics, statement errors keep their line numbers, and the smoke coverage in src/vitte/compiler/tests/smoke.vit now checks the formatted output through the shared frontend formatter. The result is a cleaner split between parse-time data and presentation, which makes the compiler easier to extend without losing error fidelity.

Stdlib compression

The compression stdlib has been tightened into a coherent family of modules: src/vitte/stdlib/compression.vitl now pulls in deflate, brotli, algorithms, lz, huffman, and stats, while interface.vitl exposes the same surface with aligned health checks and self-tests. The submodules were rewritten to fit the current parser and to keep their own manifests, health summaries, and smoke paths explicit, so the compression layer is now easier to read, easier to test, and much less dependent on legacy syntax. The dedicated smoke at src/vitte/stdlib/compression/tests/smoke.vitl now exercises the whole family in one place, which gives us a cleaner stdlib baseline for the next round of work.

@roussov

@roussov notes that the compiler now has a clean Vitte-owned path; the GitHub URL https://github.com/vitte-lang/src/vitte/compiler does not resolve as written, so the practical entry point is Source.

The current direction is simple: keep the compiler readable, keep the layers separate, and keep the documentation and checks aligned with the Vitte source of truth.

The longer community note expands the same idea into concrete compiler principles for contributors who want the full picture. If you are looking for what to do next, try Community, Diagnostics, or Suggestions.

Compiler Vitte

The compiler is now tracked as a Vitte-owned surface instead of a separate host implementation.

• The driver package moved under src/vitte/compiler/driver and now carries the command catalogs, option catalogs, normalization helpers, and stage mapping in Vitte code.
• Frontend and grammar alignment moved into src/vitte/grammar/vitte.ebnf, and the parser sync reports so the compiler surface and the language surface stay in step.
• Core semantic gates now run against Vitte fixtures, including src/vitte/stdlib/core.vitl, tests/diag_snapshots/composite_type_arity.vit, and the restored negative-test corpus.
• The remaining host references were removed from docs and lint gates, which leaves the compiler and its checks expressed directly in Vitte.

What followed

• Completion specs, package layout checks, and legacy import audits were realigned so the command surface, package surface, and repo surface agree on the same Vitte paths.
• The make-target documentation was regenerated from the current make help output, so the public docs now reflect the post-migration workflow without stale targets.
• Editor highlight snapshots and diagnostics pages were refreshed to match the current grammar and the current command-line behavior.
• The release and download pages were kept in sync with the visible toolchain state, including the current vitte and vittec binary set.

May 4, 2026

• The repository is now green on the fast and strict CI paths after the Vitte-only migration, including make ci-fast, make ci-strict, make build, and make ci-completions.
• Legacy host and backend references were removed from the documentation surface, and the compiler driver notes now point to the Vitte implementation in src/vitte/compiler/driver.
• The old legacy import allowlist was cleared, and the negative-test harness was restored with Vitte fixtures such as tests/negative/top_level_statement.vit and tests/strict_ok.vit.
• Documentation guards were refreshed, including docs/MAKE_TARGETS.md and the compiler-driver migration page, so path checks now reflect the current Vitte-only tree.
• Editor highlight snapshots were realigned for the current grammar and the visible documentation pages now match the post-migration command surface.

May 2, 2026

• src/vitte/grammar/vitte.ebnf now documents the compiler-facing surface alongside the systems, application, and kernel layers.
• Top-level grammar now includes extern blocks, intrinsic, compiler, query, pass, backend, and diagnostic declarations.
• Data and procedure forms were expanded with bits declarations, operator procedures, associated trait types, additional procedure modifiers, and richer assignment operators.
• Statement and type rules were simplified around block-only procedure bodies, explicit semicolon-terminated simple statements, prefix type qualifiers, and compiler-specific primitive identifiers such as TokenId and NodeId.
• Old duplicated surface forms have been reduced, including legacy package/import declarations, shorthand attributes, and older foreign-style naming in the canonical grammar.

April 28, 2026

• Canonical grammar has taken precedence over the old surface aliases.
• The stdlib has switched to export *.
• The frontend accepts canonical forms extern, impl, union, trait, requires, where, async and await.
• Builtin expressions sizeof, alignof, typeof, nameof and offsetof are recognized by the parser.

February 18, 2026

• Release 2.1.1.
• macOS packaging, CLI v2 completions, release, and test patch internal_module_denied.

Useful benchmarks

• Documentation
• Download
• Diagnostics
• Complete Summary
• Site Map