Upgrading V to latest version

If V is already installed on a machine, it can be upgraded to its latest version by using the V's built-in self-updater. To do so, run the command v up. This also refreshes the bundled TCC binaries used for fast C compilation. It asks the TCC repository which revision the bundle's branch is at; when that has not changed, the TCC checkout is not fetched or rewritten, and v up reports that TCC is already up to date. On Linux, an older compatible TCC bundle stays in place while its upstream revision is unchanged and it still passes the host compatibility check. Repeated updates preserve its file metadata. When no commit of an unchanged branch suits the host, V keeps using the system compiler without checking the branch again; run make fresh_tcc to check it again, for example after upgrading the system. On macOS, TCC builds use its runtime thread fence directly, including when preprocessed C identifies ARM64 with __arm64__ alone.

After a successful update that changes the V checkout or TCC, or rebuilds the compiler, v up runs v wipe-cache to clear module, object, temporary, and compiled tool caches. When nothing changes, the caches are preserved. If the TCC revision cannot be determined, the caches are cleared conservatively. Subsequent builds recreate the caches they need. Previously recorded build configurations and test selectors are not replayed. A failed cache cleanup makes v up fail. On Windows, the cached updater exits before its launcher wipes the caches, so the running executable does not block cleanup. Cleanup failures are returned by the launcher.

make also warms the default test configuration's builtin module bundle, including strings, strconv, hash and bits. Compatible test builds reuse these objects when the program introduces new error types, retaining builtin error dispatch ID dependencies. Dispatch hash collisions retain the full error-type dependency. Without a bundled collector, the warmup uses -gc none; an explicit -gc setting takes precedence. A missing object for another module rebuilds that module while retaining compatible cached modules. Ignored local names remain stable when cached headers replace source files, so reparsed modules can reuse identical C objects. Compiler flags, source changes and dependency changes still invalidate the affected objects.

Relative cache paths are resolved against the directory where v up was invoked. When VCACHE is unset, this includes the .cache directory under the first VMODULES entry, or ~/.vmodules/.cache by default. Cleanup stops and returns a nonzero status if a cache folder cannot be removed or recreated. The separate module cache refresh utility documents its inventory and replay APIs.

v up reports the agent skills that the new revision left behind, since a new revision may ship updated copies of them. It writes nothing: the skills belong to the user, and updating the compiler is not consent to overwrite them. Pass -skills to refresh the ones that were not edited locally, or run v skills update --global to choose which ones.

The report is about the skills installed for the whole machine, so v skills update needs --global to act on them; on its own it defaults to the project directory, which is a different installation. Skills with local changes, and skills installed before V recorded what it installed, are reported either way and left alone; see v skills update below.