Tooling

This page covers the tools and automation that the Go project itself uses to keep the codebase healthy. They are distinct from the user-facing toolchain (compiler, linker, etc.); those are documented in Components.

go generate

Many files in the repo are generated. Look for the // Code generated by ... DO NOT EDIT. header. The most common generators:

• SSA rewrite tables. src/cmd/compile/internal/ssa/_gen/*.rules are the source of truth; go generate (run from _gen/) produces rewriteARM64.go, rewritegeneric.go, etc. Several megabytes of generated code.
• SSA op tables. _gen/*Ops.go and _gen/main.go produce opGen.go.
• Per-architecture instruction sets. src/cmd/internal/obj/<arch>/anames.go, inst_gen.go, goops_gen.go are generated from in-tree tables.
• cmd/go/alldocs.go is the concatenated help text for the go command, generated from the per-subcommand doc.go files.
• internal/cpu/cpu_*.go has generated tables of CPU feature names per architecture.
• Encodings under crypto/internal/... include generated tables for elliptic curves and ciphers.

Run all generators in a tree:

go generate ./...

This is rarely needed end-to-end but is the right answer when reviewers say "regenerate the tables."

cmd/api

src/cmd/api/ enforces Go's API compatibility promise. Every public symbol of every standard library package is listed in api/go1.txt, api/go1.1.txt, ..., api/go1.27.txt (the latter is for the in-development version). The api tool compares the current API to those manifests and rejects unannounced changes.

When a CL adds a new public API, the same CL must update api/next/<issue>.txt with the new entries. Run:

go test cmd/api

This is one of the steps cmd/dist test runs.

cmd/vet (and go vet)

src/cmd/vet/ is the standard library's vet-suite wrapper. The actual analyses live under src/cmd/vet/... and use the analysis framework from golang.org/x/tools/go/analysis (vendored).

The Go project runs go vet against std cmd as part of cmd/dist test. New CLs must not introduce new vet findings.

A handful of analyses (e.g., printf, lostcancel, nilness, unsafeptr) are bundled into the standard go vet invocation. Custom analyses — for example, cmd/vet/internal/... — are also run by the trybots.

There is also a more aggressive in-tree static analyzer in src/cmd/compile/internal/staticinit and friends, but that's a compiler concern, not a vet one.

gofmt and friends

• cmd/gofmt — the formatter. The project depends on it being byte-identical across releases for stable code.
• cmd/gofix — old AST rewriter for migrating between Go versions. Mostly historical now.
• cmd/fix — the modern go fix wrapper, including the new //go:fix directive support.

gofmt is part of every CL's pre-commit hook (git codereview hooks).

Build coordinator: cmd/dist

src/cmd/dist/ is more than the build orchestrator from Architecture. It also:

• Lists tests (cmd/dist test -list).
• Generates per-architecture build files.
• Validates the host toolchain.
• Runs cross-compilation matrix tests.
• Triggers cmd/api.

cmd/dist test is the single canonical entrypoint for "run everything." ./run.bash is just a one-line wrapper around it.

Telemetry

The Go toolchain has opt-in telemetry counters. Implementation in src/cmd/internal/telemetry/ and src/cmd/internal/counter/. Users opt in via go telemetry on. Counters track tool usage and crash reports without sending source code or user data.

Counter names appear throughout the toolchain code, e.g.:

counter.New("go/errors:gopath-entry-relative")

Aggregate, anonymized telemetry summaries are published at https://telemetry.go.dev/.

Continuous integration: trybots and longtests

CI for this repo runs on https://build.golang.org/ and is operated as LUCI at https://ci.chromium.org/p/golang/. The infrastructure code lives in golang.org/x/build (separate repo). Per-CL trybots run a substantial subset of cmd/dist test across dozens of builders.

The build dashboard tracks the status of each builder over time. Periodic regression bots ("longtests") run nightly with extended configurations (race, asan, msan, slow architectures).

Fuzzing

src/internal/fuzz/ is the engine behind go test -fuzz. CI fuzzing runs against parts of the standard library and reports crashing inputs into testdata/fuzz/<FuzzFunc>/. New regressions usually show up here as additional crash files alongside the seed corpus.

Project-wide continuous fuzzing is also performed by OSS-Fuzz, with project entries that build the Go standard library packages and run them.

Code review automation

The Gerrit instance at go-review.googlesource.com runs:

• git codereview server-side checks: Change-Id presence, no merge commits, gofmt clean.
• TryBot triggers (when Run-TryBot+1).
• gerrit-bot automated reviewers for some directories.
• The "L" labels (Hold, Submit Queue) used by maintainers.

GitHub mirror: a small bot replies to PRs with a redirect to Gerrit and closes them.

Where to read next

• Testing — actual usage of the trybot harness from a contributor's seat.
• Components → Compiler — what go generate regenerates inside the compiler.
• Components → Go command — what the go tool itself runs at build time.