Modules, Build and Toolchain

A replace directive in go.mod redirects a module path to something else: either a different module at a stated version, or a directory on disk. The build then compiles that code instead of the version the proxy would serve.

go mod tidy makes the require block match the code: it adds a requirement for every module your packages import, drops requirements nothing imports any more, maintains the indirect markers, and syncs go.sum. Run it after changing imports.

Go treats each major version as a separate module. From v2 on, the module line in go.mod and every import of its packages must end in /v2, so v1 and v2 can live in one build.

go get -u ./... upgrades every module behind the packages your module imports, directly or transitively, to its newest minor or patch release. go get -u=patch caps each move at the newest patch of the minor already selected.

The build uses v1.2.0. Go's minimal version selection takes the highest version some go.mod in the graph actually requires, never the newest one published. A new release stays invisible to the build until a require line names it.

It is a build constraint. The file is compiled only when the target operating system is Linux, and is skipped entirely otherwise. The line must sit above the package clause, with a blank line after it.

go build compiles a main package and writes the executable into the current directory. go run builds it to a temporary file, runs it, then deletes the binary. go install writes the executable into GOBIN, which defaults to GOPATH/bin.

The go command caches compiled package output keyed by a hash of every input. Unchanged code hashes the same, so the second build reuses the stored result instead of recompiling. Running go env GOCACHE prints the directory that holds it.

A //go:generate line is just a comment; no build step reads it. Only the go generate command scans for these lines and runs each named command in the package directory. go build and go test never run them, so the generated output must be committed.

gofmt reprints a Go file in one canonical layout: tabs for indentation, blanks for alignment, fixed spacing and brace placement, and import specs sorted inside each existing block. It exposes no style settings, so formatting stops being a review topic.

Set GOOS and GOARCH for that one build: GOOS=linux GOARCH=arm64 go build ./cmd/tool. The Go toolchain compiles for every target it supports on its own, so there is no separate cross-compiler, VM or target SDK to install.

It tells the Go linker to set the package-level string variable named version in package main to 1.4.0 when the binary is linked, so the compiled program can report that version without it being hard-coded in the source.

CGO_ENABLED=0 disables cgo, so no C code is compiled in and the standard library uses its pure-Go net and os/user code. The result is a self-contained static binary that needs no C library on the host.

The binary was linked with cgo enabled, so it is dynamically linked and names a glibc dynamic loader such as /lib64/ld-linux-x86-64.so.2. That path does not exist on a musl host, so exec fails and reports the missing interpreter.

The go tool reads the platform out of the filename: a file ending in _linux.go is compiled only when GOOS=linux. Building for Windows drops it from the package entirely, so every symbol it declared becomes undefined.

go/parser.ParseFile returns an *ast.File, the syntax tree of one source file, plus an error. Node positions are bare integers; the token.FileSet holds each file's name and line table, so those integers decode to file, line and column.

An analysis.Analyzer is a struct: Name, Doc, Requires and a Run function. Run is called once per package and calls pass.Reportf with a source position for each finding. A non-nil error from Run means the analyzer itself failed.

pass.TypesInfo is the package's *types.Info: it maps each identifier to the declaration it resolves to and each expression to its type. That is how a check recognises context.TODO whatever the import is aliased to, and ignores an unrelated TODO.

ast.Walk drives an ast.Visitor whose Visit returns a visitor for the children, or nil to skip them. ast.Inspect wraps that in a func(ast.Node) bool where false skips children. Both call you again with a nil node when a subtree ends.

Treat silence as a failure until proven otherwise. Prove the matcher on an analysistest fixture with want comments, then work up the chain: analyzer linked into the shipped binary, packages actually analysed, files not hidden by build constraints, results not served from cache.

The go line names the minimum Go release the module needs and the language version its files compile under. It is a floor, not the exact compiler you run: any newer Go release builds the module fine, and still applies the older language version.

Because GOTOOLCHAIN defaults to auto: the go line in go.mod is a minimum, not a maximum, so the go command downloads a newer Go toolchain as a module and re-executes your build with it instead of failing.

GODEBUG carries comma-separated name=value settings, such as panicnil=1, that switch particular runtime and standard-library behaviours back to an older Go release's semantics. A Go binary reads them when it starts, so no rebuild is needed.

Go 1 promises that source building and running correctly under one Go 1.x release keeps building and running under later ones. It binds the language specification and the documented standard-library API, so upgrading is normally just a recompile.

Yes, one shared i. Per-iteration loop variables arrived in Go 1.22 and are gated on the module's go line, not on the installed release. A go 1.21 line keeps Go 1.21 semantics, so all three goroutines close over the same variable.