The default compiler

On every native platform, the top-level v executable contains the default compiler whose source lives in vlib/v. Every direct C build, including compiler self-builds, is compiled in-process. The CLI remains in cmd/v; test is handled by the default compiler, and external tools are compiled with it first.

The standard bootstrap does not build the sibling v1_fallback executable (v1_fallback.exe on Windows). When V needs the compatibility compiler and the sibling is missing, it reports that it is running make v1. That target reuses or downloads the complete 0.5.2 release under the user cache. If no release binary can run, oldv clones the 0.5.2 V sources and matching vc snapshot and builds the fallback there. You can run make v1 explicitly to prepare it ahead of time. Automatic provisioning keeps its launcher metadata in the user cache, so an older read-only sibling installation can remain untouched. -old-compiler launches the fallback explicitly, and ordinary user builds and external tools retry through it after a compiler or C compilation failure. Explicit -new-compiler builds remain strict default-compiler operations. -new-compiler remains accepted for command-line compatibility and otherwise selects the same embedded driver.

The installer supplements the cached fallback vlib with modules whose public paths moved after 0.5.2. Fallback roots missing these compatibility modules are not used. If a fallback command exits unsuccessfully, V notes where the default compiler stopped and how to show its suppressed diagnostics. For a command that may have run user code, the note preserves the child's status without mislabeling it as a compiler failure. Re-run the command with -new-compiler to see the default-compiler diagnostics without a fallback retry.