Vitte Community

Welcome Documentation Sitemap Download Source Community News Diagnostics Suggestions

Code of Conduct

• Be precise, respectful, and technical in review and issue threads.
• Critique code and assumptions, never people.
• Attach reproducible evidence when reporting regressions.

How to Contribute

1. Open an issue with context, expected behavior, and impact.
2. Propose a minimal patch linked to tests or docs evidence.
3. Run documentation and compiler gates before asking for review.

Public Roadmap

• Documentation priorities (compiler surface + stdlib coverage).
• Release timeline (patches, milestones, adoption updates).
• Implementation tracks (driver, grammar, diagnostics, backend).

Example community flow

# Example contribution path
1. Read the docs on the feature in doc.html
2. Inspect the source in source.html
3. Check diagnostics if you reproduce a failure
4. Share a minimal issue and patch in community

This page is a hub for signals, not a replacement for the feature docs or implementation details.

Useful messages

Quick sort

• News : announcements and releases.
• Community : help, contributions, docs.
• Support : diagnostics and assistance.
• Dev : source and patches.

Thread rules

• One post, one topic.
• A minimal example is better than a long, fuzzy block.
• When it is an error, start with vitte explain.

@owner

@owner is the project owner for release governance and technical arbitration.

Owner scope

• Final decision on release readiness and milestone closure.
• Validation of evidence-backed checklist updates (no unchecked claims).
• Arbitration when architecture, ABI, or stdlib contracts conflict.
• Approval of breaking changes impacting compiler/stdlib public surface.

How to escalate to @owner

• Use a concise issue summary: context, risk, proposed action, expected impact.
• Attach concrete artifacts (logs, reports, matrix links, reproduction path).
• Mark severity explicitly: critical, major, or minor.

Owner-first contribution contract

• No checklist item is marked complete without repository evidence.
• Automation gates are preferred over manual status updates.
• Runtime and ABI claims must be backed by target-specific fixtures/reports.

@roussov on the latest compiler modifications

@roussov wrote this long-form community note to explain the latest compiler modifications in plain architectural terms. If you only want the short release summary, see News. If you want the full implementation story, this note is the right place to start.

The most important change is not a new command, not a visual refresh, and not a larger file count. The real change is that the compiler now carries explicit structure where it previously carried placeholders. For a long time, the frontend could recognize a lot of syntax, but the pipeline still reduced that work to a handful of counters and a root string. That is useful for smoke validation, but it is not enough for a compiler that wants to explain itself, test itself, and evolve without accidental coupling between layers. The latest work starts fixing that problem directly.

The frontend now builds a real AST module for the supported subset. That statement matters because it changes what every later stage can assume. Instead of receiving a string such as "program" and hoping that the parser really saw something coherent, downstream code can now inspect concrete items, statements, patterns, annotations, and expressions. In practice, that means constants, procedures, static_assert, local bindings, assignments, returns, simple calls, literal expressions, binary expressions, and borrow expressions all survive parsing as structured objects instead of being collapsed into counts. This is the beginning of a compiler surface that can be named and reasoned about.

The parser is still intentionally bounded. It does not try to materialize the entire language at once, and that is the correct decision. A fake “complete” AST would only create more architectural debt. What the latest pass does instead is much healthier: it defines a stable slice of the language, gives that slice a real tree representation, and then teaches the rest of the pipeline to consume that representation honestly. That creates a foundation which can grow by extension rather than by replacement.

The next major result is that HIR is no longer ceremonial. Before the pass, HIR lowering effectively said “the frontend was valid, therefore there is one node.” That is not a semantic layer; it is a placeholder. The latest modifications define explicit HIR items, statements, and expressions that mirror the supported AST subset while moving the compiler one step closer to semantic structure. HIR now carries item kind, statement kind, lowered expression form, mutable binding state, names, targets, and validity. That is still a minimal HIR, but it is real enough to support analysis contracts and structural tests.

MIR has been moved in the same direction. It now models functions, blocks, statements, operands, and terminator intent rather than returning synthetic counts with no inspectable payload. The new MIR is not yet a full control-flow graph for the whole language, but it is finally a representation that can host one. That distinction matters. A compiler becomes easier to maintain the moment “lowering produced MIR” means “we can inspect blocks and statements” rather than “we incremented a metric.”

From a community point of view, this is the kind of change that improves almost everything else indirectly. Diagnostics become easier to anchor because they can point to real syntax and real lowered forms. Reviews become sharper because comments can be attached to named structures instead of vague phases. New contributors can follow a feature from parser output to HIR to MIR without reconstructing the pipeline mentally from counters and string flags. Documentation becomes more trustworthy because the implementation is closer to the conceptual model described on the site.

The analysis story changed as well. Borrow checking, constant evaluation, and the current minimal type checking path now sit closer to the structures produced by the compiler. Borrow checking gained an HIR-facing entry point, constant evaluation gained an AST-facing entry point, and the type checking path now at least speaks through HIR instead of operating only as a frontend guard. None of these passes should be considered “finished,” but they now point in the right direction: analyses should attach to compiler data structures, not stay permanently tied to raw source text once structured layers exist.

This is especially important for contributors who care about discipline between layers. A language project tends to rot when parsing, semantic checking, lowering, diagnostics, and release messaging each invent their own idea of what the source means. The latest work reduces that risk. The compiler now has a better chance of maintaining one source-facing model, one lowered semantic model, and one middle-level execution model, each with a clear job. That separation is what allows the project to scale without becoming unreadable.

Another useful side effect is test quality. Structural tests now exist for the AST, HIR, and MIR subset that was introduced. That is not glamorous work, but it is exactly the kind of work that makes future changes safer. It is one thing to say the parser “handles” a constant declaration or a simple procedure body. It is another thing to assert that the frontend produces three items, that the second item is a static assertion, that HIR lowering preserves the procedure body shape, and that MIR lowering emits a return statement in the expected place. Those are the kinds of checks that turn architecture into something the repository can defend automatically.

There is also a wider message here about how Vitte should grow. The right path is not to claim that every language feature is fully supported just because the lexer recognizes the keyword and the parser can skip over the shape. The right path is to define a subset, represent it explicitly, test it structurally, wire analysis against it, and then widen the subset step by step. That is slower in appearance but much faster in the long run, because every new feature extends an existing contract instead of fighting hidden placeholder logic.

For maintainers, the practical benefit is clarity of ownership. The frontend can now be discussed in terms of AST construction. The HIR layer can be discussed in terms of semantic normalization. The MIR layer can be discussed in terms of execution-friendly lowering. Analysis can be discussed in terms of which structured layer it consumes and why. Those are healthier conversations than arguing over whether a string flag or a text heuristic should remain in place for one more release.

For reviewers, the benefit is precision. A review comment can now say “this AST node should preserve the annotation,” “this HIR statement should keep the mutable binding bit,” or “this MIR lowering should emit a real assert statement,” and that comment points to a named object. That is a real improvement in project ergonomics, not just in compiler internals.

For users watching from the outside, the practical meaning is that the compiler is becoming easier to trust. Trust does not come from volume. It comes from visible transitions. If the parser says it recognized something, the AST should show it. If the AST claims a procedure body exists, HIR should lower it. If HIR lowers it, MIR should expose the resulting execution shape. If analyses claim to understand it, tests should prove that the shape is stable enough to inspect. That is the path this pass puts the project on.

So the latest modifications are not just another incremental cleanup. They are a shift from symbolic structure to actual structure. The frontend now returns an object. The middle-end now lowers objects. The analysis pipeline now consumes those objects more directly. The tests now assert those objects exist in the expected form. That is the kind of compiler progress that compounds, because once the layers are honest, every later feature has a better place to land.

If you are contributing to Vitte, the recommendation is straightforward. Work with the layers that now exist, strengthen their contracts, and extend the supported subset without reintroducing text-only shortcuts where structured data is already available. Keep the parser explicit, keep the AST inspectable, keep HIR semantic, keep MIR operational, and keep every analysis attached to the narrowest correct layer. That is how the compiler becomes easier to explain, easier to review, and easier to evolve.

@goginx

@goginx pushed the next meaningful compiler cleanup further down the pipeline. The latest changes are not about adding more surface area for its own sake; they are about making the frontend and analysis path harder to fake and easier to inspect.

@goginx community note (May 23, 2026): this cycle prioritizes compiler observability and resilience: `metrics`, `health`, advanced diagnostics, parser recovery quality, LSP stability checks, and local-change incremental invalidation reporting.

Community update from @goginx (May 22, 2026): we now have a native panic-boundary ABI path, runtime C payload auto-wiring in linker artifacts, and a larger target alias matrix to keep Vitte usable on old machine families without silently pretending support. The rule remains strict: if a target is accepted, it must resolve through an explicit `TargetConfig` contract and pass through a traceable compiler pipeline stage chain.

Latest @goginx community note (May 20, 2026): the strict compiler path is now enforceable end-to-end with compiler-max-gate-strict and selfhost-hard-strict, while driver entry locking and transitive reachability audits make regressions visible immediately. The working rule for contributors is simple: no placeholder behavior without an explicit diagnostic and no silent fallback in strict mode.

The lexer is one of the clearest examples. It no longer behaves like a loose stream that silently classifies almost everything as a token and leaves later stages to guess what went wrong. It now emits explicit lexical diagnostics and separates invalid tokens, floats, chars, integers, strings, identifiers, keywords, and symbols into real categories. That gives the compiler a better first contract: before parsing even begins, the frontend can now say what it saw and where it failed.

The parser also became more disciplined. Expressions are no longer assembled only through string slicing and post-hoc reconstruction. A token-driven precedence parser now handles calls and binary operators in a stable order, which means the AST represents what the parser actually understood instead of approximating expression structure after the fact. That is the kind of improvement that does not always look dramatic in a diff, but it changes how much trust later passes can place in the tree.

This pass also widens the structured subset in the right place. if and while now exist as explicit statements in the AST and in HIR, instead of disappearing before the compiler has had a chance to lower or analyze them honestly. The MIR path is still early and still flattens this subset for simplicity, but the important architectural step is already there: control flow is now preserved as named compiler data before MIR decides how operational that shape should become.

That change matters because every compiler layer becomes easier to reason about once it receives real objects rather than inferred intent. A parser that returns a structured conditional lets the HIR layer normalize it. A HIR layer that still knows a loop is a loop gives later analyses a real place to attach loop-aware logic. Even if the final lowering is still incomplete, the system stops throwing away meaning too early.

The analysis direction is better as well. Borrow checking no longer has to depend only on a synthetic text script rebuilt from lowered statements; its HIR-facing path now walks HIR statements directly. Constant evaluation also gained an AST-native path, so constant items and static_assert are interpreted from syntax tree nodes instead of being reparsed as raw source in the main structured route. Neither pass should be treated as “finished,” but they now point at the correct layer boundaries instead of reinforcing the old text-only shortcuts.

This is the real value of the latest modifications: they reduce the gap between what the compiler says it knows and what it actually preserves. The lexer now reports lexical structure more honestly. The parser now builds expression structure more honestly. The AST and HIR now retain simple control-flow structure more honestly. Borrow checking and constant evaluation now consume compiler data more honestly. That makes the whole repository easier to review, because fewer layers have to reconstruct information that should already have been carried forward.

For contributors, that improves the contract immediately. If you want to work on parsing, you can now trace operator precedence and statement shape through named nodes. If you want to work on HIR, you can see where conditionals and loops enter the lowered world. If you want to work on analysis, you have a better chance of hooking onto structured inputs rather than defending another line-based heuristic. That is the kind of cleanup that compounds, because once structure survives one more stage, every later pass has a better foundation.

In practical terms, the compiler did not just gain more code this round. It gained stronger boundaries. The frontend is stricter. The parser is less ad hoc. The AST carries more useful meaning. HIR receives more of that meaning intact. The analyses are less dependent on reconstructed text. That is what real compiler progress looks like: not just more features, but fewer lies between layers.

For contributors, that is a good contract. If you want to improve parsing, you should be able to read the parser chapter and the grammar files without hunting through a foreign implementation. If you want to change a diagnostic, you should see the rule that produces it and the place where it belongs in the compiler flow. If you want to adjust the command line, you should compare the driver, the completion snapshots, and the release notes. That kind of alignment is what makes a compiler feel real rather than ceremonial.

The larger rule is simple: keep the compiler readable enough that a newcomer can trace one feature from syntax to output. Keep the source of truth in Vitte whenever possible. Keep the docs in step with the code, not behind it. Keep the terminology stable so that community discussions can refer to the same objects as the implementation. A compiler becomes easier to evolve when it is written as a set of honest, checkable transitions instead of a monolith with hidden edges.

So if you are following the Vitte compiler from the outside, start with the source view and then move inward: the driver, the grammar, the tests, the IR, the backend, and the diagnostics. If you are following it from the inside, do the reverse and make sure each layer still says the same thing. That is the kind of discipline that lets a project grow without losing its shape, and it is the reason the compiler can now be discussed as a first-class Vitte artifact rather than a borrowed implementation detail.

In short, the compiler should remain easy to explain, easy to inspect, and easy to evolve. That is the kind of message the community can build on, and it is the kind of structure that keeps the work useful as the language grows.

Compiler principles

• One layer, one responsibility. The parser should not guess about backend policy, and the backend should not carry syntax concerns.
• One rule, one place. If a constraint exists, it should be written once in the grammar, once in the driver, or once in the diagnostics, not scattered across all three.
• One example, one expectation. A documented example should compile for a reason that can be named, not because the pipeline happens to accept it by accident.
• One message, one action. Diagnostics should tell the user what failed, where it failed, and what to try next.
• One source of truth. When Vitte owns the compiler code, the docs, tests, and release pages can stay synchronized without translation work.

This is also why the compiler discussion belongs in public. The community should not need to infer structure from fragments. It should be able to read the project as a sequence of contracts: syntax contracts, semantic contracts, lowering contracts, backend contracts, and release contracts. Once those contracts are visible, contributors can work in parallel without stepping on each other, because the shape of the system is already written down.

If you only want the short version, see News. If you want to inspect the implementation path, stay on Source and move outward from there.