VOID Language

Check source.
Build native. Power an editor.

The same compiler front end now drives source-only validation, native builds, ranged diagnostics, debug mapping, and semantic language-server features for active editor documents.

The current development flow.

VOID Language is still being prepared for public release, but the compiler workflow itself is established. The commands below describe the working toolchain rather than a hypothetical future interface.

Create or open a VOID project

Use a normal .voidproj project, a project directory, or supported projectless Program.void input.

Validate without building

voidc check runs project resolution, lexing, parsing, specialization/lowering, and semantic analysis, then stops before generated C or native compilation.

Read precise diagnostics

Lexer, parser, semantic, and check failures carry end-exclusive source ranges so errors point at the exact offending token or source region.

Build, run, or publish

Executable projects lower VOID to C and invoke the system compiler/linker. Debug builds retain symbols; publish output remains optimized/stripped. Library projects use the same front end but emit a native static archive instead of requiring Main.

Debug against VOID source

Generated C contains standard #line mappings, so native debug information refers back to original .void filenames and lines.

Start the language server when needed

voidc lsp provides live ranged diagnostics, hover, signature help, semantic completion, go-to-definition, references, document symbols, and workspace symbols over standard LSP/JSON-RPC.

Edit across files without stale state

Open project files are analyzed together from their current in-memory text. Dependent diagnostics and semantic queries refresh when another unsaved file changes, and closing a document falls back to its on-disk source.

Link native dependencies when needed

Unsafe projects can declare native libraries and project-relative search paths, keeping native dependencies beside the project.

Build reusable libraries when needed

A project using "output": "library" produces lib<ProjectName>.a. Public static methods marked with [Export("symbol")] become stable native entry points, and VOID or C consumers link the archive through normal native-library settings.

Front-end-only validation
./bin/voidc check MyGame

VOID project resolved
...
checked: MyGame
Native development flow
./bin/voidc build MyGame
./bin/voidc run MyGame
./bin/voidc publish MyGame

# Compiler-side language server
./bin/voidc lsp
No hidden build: voidc check does not generate C, create build output directories, or invoke the native C compiler. It uses the same compiler front end as a real build, which keeps CI/editor validation aligned with actual language semantics.