Documentation
¶
Overview ¶
Go is a tool for managing Go source code.
Usage:
go <command> [arguments]
The commands are:
bug start a bug report build compile packages and dependencies clean remove object files and cached files doc show documentation for package or symbol env print Go environment information fix apply fixes suggested by static checkers fmt gofmt (reformat) package sources generate generate Go files by processing source get add dependencies to current module and install them install compile and install packages and dependencies list list packages or modules mod module maintenance run compile and run Go program telemetry manage telemetry data and settings test test packages tool run specified go tool version print Go version vet report likely mistakes in packages work workspace maintenance
Use "go help <command>" for more information about a command.
Additional help topics:
buildconstraint build constraints buildjson build -json encoding buildmode build modes c calling between Go and C cache build and test caching environment environment variables filetype file types goauth GOAUTH environment variable go.mod the go.mod file gopath GOPATH environment variable goproxy module proxy protocol importpath import path syntax modules modules, module versions, and more module-auth module authentication using go.sum packages package lists and patterns private configuration for downloading non-public code testflag testing flags testfunc testing functions vcs controlling version control with GOVCS
Use "go help <topic>" for more information about that topic.
Start a bug report ¶
Usage:
go bug
Bug opens the default browser and starts a new bug report. The report includes useful system information.
Compile packages and dependencies ¶
Usage:
go build [-o output] [build flags] [packages]
Build compiles the packages named by the import paths, along with their dependencies, but it does not install the results.
If the arguments to build are a list of .go files from a single directory, build treats them as a list of source files specifying a single package.
When compiling packages, build ignores files that end in '_test.go'.
When compiling a single main package, build writes the resulting executable to an output file named after the last non-major-version component of the package import path. The '.exe' suffix is added when writing a Windows executable. So 'go build example/sam' writes 'sam' or 'sam.exe'. 'go build example.com/foo/v2' writes 'foo' or 'foo.exe', not 'v2.exe'.
When compiling a package from a list of .go files, the executable is named after the first source file. 'go build ed.go rx.go' writes 'ed' or 'ed.exe'.
When compiling multiple packages or a single non-main package, build compiles the packages but discards the resulting object, serving only as a check that the packages can be built.
The -o flag forces build to write the resulting executable or object to the named output file or directory, instead of the default behavior described in the last two paragraphs. If the named output is an existing directory or ends with a slash or backslash, then any resulting executables will be written to that directory.
The build flags are shared by the build, clean, get, install, list, run, and test commands:
-C dir
Change to dir before running the command.
Any files named on the command line are interpreted after
changing directories.
If used, this flag must be the first one in the command line.
-a
force rebuilding of packages that are already up-to-date.
-n
print the commands but do not run them.
-p n
the number of programs, such as build commands or
test binaries, that can be run in parallel.
The default is GOMAXPROCS, normally the number of CPUs available.
-race
enable data race detection.
Supported only on darwin/amd64, darwin/arm64, freebsd/amd64, linux/amd64,
linux/arm64 (only for 48-bit VMA), linux/ppc64le, linux/riscv64 and
windows/amd64.
-msan
enable interoperation with memory sanitizer.
Supported only on linux/amd64, linux/arm64, linux/loong64, freebsd/amd64
and only with Clang/LLVM as the host C compiler.
PIE build mode will be used on all platforms except linux/amd64.
-asan
enable interoperation with address sanitizer.
Supported only on linux/arm64, linux/amd64, linux/loong64.
Supported on linux/amd64 or linux/arm64 and only with GCC 7 and higher
or Clang/LLVM 9 and higher.
And supported on linux/loong64 only with Clang/LLVM 16 and higher.
-cover
enable code coverage instrumentation.
-covermode set,count,atomic
set the mode for coverage analysis.
The default is "set" unless -race is enabled,
in which case it is "atomic".
The values:
set: bool: does this statement run?
count: int: how many times does this statement run?
atomic: int: count, but correct in multithreaded tests;
significantly more expensive.
Sets -cover.
-coverpkg pattern1,pattern2,pattern3
For a build that targets package 'main' (e.g. building a Go
executable), apply coverage analysis to each package whose
import path matches the patterns. The default is to apply
coverage analysis to packages in the main Go module. See
'go help packages' for a description of package patterns.
Sets -cover.
-v
print the names of packages as they are compiled.
-work
print the name of the temporary work directory and
do not delete it when exiting.
-x
print the commands.
-asmflags '[pattern=]arg list'
arguments to pass on each go tool asm invocation.
-buildmode mode
build mode to use. See 'go help buildmode' for more.
-buildvcs
Whether to stamp binaries with version control information
("true", "false", or "auto"). By default ("auto"), version control
information is stamped into a binary if the main package, the main module
containing it, and the current directory are all in the same repository.
Use -buildvcs=false to always omit version control information, or
-buildvcs=true to error out if version control information is available but
cannot be included due to a missing tool or ambiguous directory structure.
-compiler name
name of compiler to use, as in runtime.Compiler (gccgo or gc).
-gccgoflags '[pattern=]arg list'
arguments to pass on each gccgo compiler/linker invocation.
-gcflags '[pattern=]arg list'
arguments to pass on each go tool compile invocation.
-installsuffix suffix
a suffix to use in the name of the package installation directory,
in order to keep output separate from default builds.
If using the -race flag, the install suffix is automatically set to race
or, if set explicitly, has _race appended to it. Likewise for the -msan
and -asan flags. Using a -buildmode option that requires non-default compile
flags has a similar effect.
-json
Emit build output in JSON suitable for automated processing.
See 'go help buildjson' for the encoding details.
-ldflags '[pattern=]arg list'
arguments to pass on each go tool link invocation.
-linkshared
build code that will be linked against shared libraries previously
created with -buildmode=shared.
-mod mode
module download mode to use: readonly, vendor, or mod.
By default, if a vendor directory is present and the go version in go.mod
is 1.14 or higher, the go command acts as if -mod=vendor were set.
Otherwise, the go command acts as if -mod=readonly were set.
See https://go.dev/ref/mod#build-commands for details.
-modcacherw
leave newly-created directories in the module cache read-write
instead of making them read-only.
-modfile file
in module aware mode, read (and possibly write) an alternate go.mod
file instead of the one in the module root directory. A file named
"go.mod" must still be present in order to determine the module root
directory, but it is not accessed. When -modfile is specified, an
alternate go.sum file is also used: its path is derived from the
-modfile flag by trimming the ".mod" extension and appending ".sum".
-overlay file
read a JSON config file that provides an overlay for build operations.
The file is a JSON object with a single field, named 'Replace', that
maps each disk file path (a string) to its backing file path, so that
a build will run as if the disk file path exists with the contents
given by the backing file paths, or as if the disk file path does not
exist if its backing file path is empty. Support for the -overlay flag
has some limitations: importantly, cgo files included from outside the
include path must be in the same directory as the Go package they are
included from, overlays will not appear when binaries and tests are
run through go run and go test respectively, and files beneath
GOMODCACHE may not be replaced.
-pgo file
specify the file path of a profile for profile-guided optimization (PGO).
When the special name "auto" is specified, for each main package in the
build, the go command selects a file named "default.pgo" in the package's
directory if that file exists, and applies it to the (transitive)
dependencies of the main package (other packages are not affected).
Special name "off" turns off PGO. The default is "auto".
-pkgdir dir
install and load all packages from dir instead of the usual locations.
For example, when building with a non-standard configuration,
use -pkgdir to keep generated packages in a separate location.
-tags tag,list
a comma-separated list of additional build tags to consider satisfied
during the build. For more information about build tags, see
'go help buildconstraint'. (Earlier versions of Go used a
space-separated list, and that form is deprecated but still recognized.)
-trimpath
remove all file system paths from the resulting executable.
Instead of absolute file system paths, the recorded file names
will begin either a module path@version (when using modules),
or a plain import path (when using the standard library, or GOPATH).
-toolexec 'cmd args'
a program to use to invoke toolchain programs like vet and asm.
For example, instead of running asm, the go command will run
'cmd args /path/to/asm <arguments for asm>'.
The TOOLEXEC_IMPORTPATH environment variable will be set,
matching 'go list -f {{.ImportPath}}' for the package being built.
The -asmflags, -gccgoflags, -gcflags, and -ldflags flags accept a space-separated list of arguments to pass to an underlying tool during the build. To embed spaces in an element in the list, surround it with either single or double quotes. The argument list may be preceded by a package pattern and an equal sign, which restricts the use of that argument list to the building of packages matching that pattern (see 'go help packages' for a description of package patterns). Without a pattern, the argument list applies only to the packages named on the command line. The flags may be repeated with different patterns in order to specify different arguments for different sets of packages. If a package matches patterns given in multiple flags, the latest match on the command line wins. For example, 'go build -gcflags=-S fmt' prints the disassembly only for package fmt, while 'go build -gcflags=all=-S fmt' prints the disassembly for fmt and all its dependencies.
For more about specifying packages, see 'go help packages'. For more about where binaries are installed, run 'go help gopath'. For more about calling between Go and C/C++, run 'go help c'. For more about project organization, run 'go help modules'.
Note: go build adheres to certain conventions for organizing projects: it primarily supports go modules (see 'go help modules') while also supporting an alternative GOPATH mode (see 'go help gopath'). Not all projects can follow these conventions, however. Installations that have their own conventions or that use a separate software build system may choose to use lower-level invocations such as 'go tool compile' and 'go tool link' to avoid some of the overheads and design decisions of the build tool.
See also: go install, go get, go clean.
Remove object files and cached files ¶
Usage:
go clean [-i] [-r] [-cache] [-testcache] [-modcache] [-fuzzcache] [build flags] [packages]
Clean removes object files from package source directories. The go command builds most objects in a temporary directory, so go clean is mainly concerned with object files left by other tools or by manual invocations of go build.
If a package argument is given or the -i or -r flag is set, clean removes the following files from each of the source directories corresponding to the import paths:
_obj/ old object directory, left from Makefiles _test/ old test directory, left from Makefiles _testmain.go old gotest file, left from Makefiles test.out old test log, left from Makefiles build.out old test log, left from Makefiles *.[568ao] object files, left from Makefiles DIR(.exe) from go build DIR.test(.exe) from go test -c MAINFILE(.exe) from go build MAINFILE.go *.so from SWIG
In the list, DIR represents the final path element of the directory, and MAINFILE is the base name of any Go source file in the directory that is not included when building the package.
The -i flag causes clean to remove the corresponding installed archive or binary (what 'go install' would create).
The -n flag causes clean to print the remove commands it would execute, but not run them.
The -r flag causes clean to be applied recursively to all the dependencies of the packages named by the import paths.
The -x flag causes clean to print remove commands as it executes them.
The -cache flag causes clean to remove the entire go build cache.
The -testcache flag causes clean to expire all test results in the go build cache.
The -modcache flag causes clean to remove the entire module download cache, including unpacked source code of versioned dependencies.
The -fuzzcache flag causes clean to remove files stored in the Go build cache for fuzz testing. The fuzzing engine caches files that expand code coverage, so removing them may make fuzzing less effective until new inputs are found that provide the same coverage. These files are distinct from those stored in testdata directory; clean does not remove those files.
For more about build flags, see 'go help build'.
For more about specifying packages, see 'go help packages'.
Show documentation for package or symbol ¶
Usage:
go doc [doc flags] [package|[package.]symbol[.methodOrField]]
Doc prints the documentation comments associated with the item identified by its arguments (a package, const, func, type, var, method, or struct field) followed by a one-line summary of each of the first-level items "under" that item (package-level declarations for a package, methods for a type, etc.).
Doc accepts zero, one, or two arguments.
Given no arguments, that is, when run as
go doc
it prints the package documentation for the package in the current directory. If the package is a command (package main), the exported symbols of the package are elided from the presentation unless the -cmd flag is provided.
When run with one argument, the argument is treated as a Go-syntax-like representation of the item to be documented. What the argument selects depends on what is installed in GOROOT and GOPATH, as well as the form of the argument, which is schematically one of these:
go doc <pkg> go doc <sym>[.<methodOrField>] go doc [<pkg>.]<sym>[.<methodOrField>] go doc [<pkg>.][<sym>.]<methodOrField>
The first item in this list matched by the argument is the one whose documentation is printed. (See the examples below.) However, if the argument starts with a capital letter it is assumed to identify a symbol or method in the current directory.
For packages, the order of scanning is determined lexically in breadth-first order. That is, the package presented is the one that matches the search and is nearest the root and lexically first at its level of the hierarchy. The GOROOT tree is always scanned in its entirety before GOPATH.
If there is no package specified or matched, the package in the current directory is selected, so "go doc Foo" shows the documentation for symbol Foo in the current package.
The package path must be either a qualified path or a proper suffix of a path. The go tool's usual package mechanism does not apply: package path elements like . and ... are not implemented by go doc.
When run with two arguments, the first is a package path (full path or suffix), and the second is a symbol, or symbol with method or struct field:
go doc <pkg> <sym>[.<methodOrField>]
In all forms, when matching symbols, lower-case letters in the argument match either case but upper-case letters match exactly. This means that there may be multiple matches of a lower-case argument in a package if different symbols have different cases. If this occurs, documentation for all matches is printed.
Examples:
go doc Show documentation for current package. go doc -http Serve HTML documentation over HTTP for the current package. go doc Foo Show documentation for Foo in the current package. (Foo starts with a capital letter so it cannot match a package path.) go doc encoding/json Show documentation for the encoding/json package. go doc json Shorthand for encoding/json. go doc json.Number (or go doc json.number) Show documentation and method summary for json.Number. go doc json.Number.Int64 (or go doc json.number.int64) Show documentation for json.Number's Int64 method. go doc cmd/doc Show package docs for the doc command. go doc -cmd cmd/doc Show package docs and exported symbols within the doc command. go doc template.new Show documentation for html/template's New function. (html/template is lexically before text/template) go doc text/template.new # One argument Show documentation for text/template's New function. go doc text/template new # Two arguments Show documentation for text/template's New function. At least in the current tree, these invocations all print the documentation for json.Decoder's Decode method: go doc json.Decoder.Decode go doc json.decoder.decode go doc json.decode cd go/src/encoding/json; go doc decode
Flags:
-all Show all the documentation for the package. -c Respect case when matching symbols. -cmd Treat a command (package main) like a regular package. Otherwise package main's exported symbols are hidden when showing the package's top-level documentation. -ex Include executable examples. -http Serve HTML docs over HTTP. -short One-line representation for each symbol. Cannot be combined with -all. -src Show the full source code for the symbol. This will display the full Go source of its declaration and definition, such as a function definition (including the body), type declaration or enclosing const block. The output may therefore include unexported details. -u Show documentation for unexported as well as exported symbols, methods, and fields.
Print Go environment information ¶
Usage:
go env [-json] [-changed] [-u] [-w] [var ...]
Env prints Go environment information.
By default env prints information as a shell script (on Windows, a batch file). If one or more variable names is given as arguments, env prints the value of each named variable on its own line.
The -json flag prints the environment in JSON format instead of as a shell script.
The -u flag requires one or more arguments and unsets the default setting for the named environment variables, if one has been set with 'go env -w'.
The -w flag requires one or more arguments of the form NAME=VALUE and changes the default settings of the named environment variables to the given values.
The -changed flag prints only those settings whose effective value differs from the default value that would be obtained in an empty environment with no prior uses of the -w flag.
For more about environment variables, see 'go help environment'.
Apply fixes suggested by static checkers ¶
Usage:
go fix [build flags] [-fixtool prog] [fix flags] [packages]
Fix runs the Go fix tool (cmd/fix) on the named packages and applies suggested fixes.
It supports these flags:
-diff instead of applying each fix, print the patch as a unified diff; exit with a non-zero status if the diff is not empty
The -fixtool=prog flag selects a different analysis tool with alternative or additional fixers; see the documentation for go vet's -vettool flag for details.
The default fix tool is 'go tool fix' or cmd/fix. For help on its fixers and their flags, run 'go tool fix help'. For details of a specific fixer such as 'hostport', see 'go tool fix help hostport'.
For more about specifying packages, see 'go help packages'.
The build flags supported by go fix are those that control package resolution and execution, such as -C, -n, -x, -v, -tags, and -toolexec. For more about these flags, see 'go help build'.
See also: go fmt, go vet.
Gofmt (reformat) package sources ¶
Usage:
go fmt [-n] [-x] [packages]
Fmt runs the command 'gofmt -l -w' on the packages named by the import paths. It prints the names of the files that are modified.
For more about gofmt, see 'go doc cmd/gofmt'. For more about specifying packages, see 'go help packages'.
The -n flag prints commands that would be executed. The -x flag prints commands as they are executed.
The -mod flag's value sets which module download mode to use: readonly or vendor. See 'go help modules' for more.
To run gofmt with specific options, run gofmt itself.
See also: go fix, go vet.
Generate Go files by processing source ¶
Usage:
go generate [-run regexp] [-n] [-v] [-x] [build flags] [file.go... | packages]
Generate runs commands described by directives within existing files. Those commands can run any process but the intent is to create or update Go source files.
Go generate is never run automatically by go build, go test, and so on. It must be run explicitly.
Go generate scans the file for directives, which are lines of the form,
//go:generate command argument...
(note: no leading spaces and no space in "//go") where command is the generator to be run, corresponding to an executable file that can be run locally. It must either be in the shell path (gofmt), a fully qualified path (/usr/you/bin/mytool), or a command alias, described below.
Note that go generate does not parse the file, so lines that look like directives in comments or multiline strings will be treated as directives.
The arguments to the directive are space-separated tokens or double-quoted strings passed to the generator as individual arguments when it is run.
Quoted strings use Go syntax and are evaluated before execution; a quoted string appears as a single argument to the generator.
To convey to humans and machine tools that code is generated, generated source should have a line that matches the following regular expression (in Go syntax):
^// Code generated .* DO NOT EDIT\.$
This line must appear before the first non-comment, non-blank text in the file.
Go generate sets several variables when it runs the generator:
$GOARCH The execution architecture (arm, amd64, etc.) $GOOS The execution operating system (linux, windows, etc.) $GOFILE The base name of the file. $GOLINE The line number of the directive in the source file. $GOPACKAGE The name of the package of the file containing the directive. $GOROOT The GOROOT directory for the 'go' command that invoked the generator, containing the Go toolchain and standard library. $DOLLAR A dollar sign. $PATH The $PATH of the parent process, with $GOROOT/bin placed at the beginning. This causes generators that execute 'go' commands to use the same 'go' as the parent 'go generate' command.
Other than variable substitution and quoted-string evaluation, no special processing such as "globbing" is performed on the command line.
As a last step before running the command, any invocations of any environment variables with alphanumeric names, such as $GOFILE or $HOME, are expanded throughout the command line. The syntax for variable expansion is $NAME on all operating systems. Due to the order of evaluation, variables are expanded even inside quoted strings. If the variable NAME is not set, $NAME expands to the empty string.
A directive of the form,
//go:generate -command xxx args...
specifies, for the remainder of this source file only, that the string xxx represents the command identified by the arguments. This can be used to create aliases or to handle multiword generators. For example,
//go:generate -command foo go tool foo
specifies that the command "foo" represents the generator "go tool foo".
Generate processes packages in the order given on the command line, one at a time. If the command line lists .go files from a single directory, they are treated as a single package. Within a package, generate processes the source files in a package in file name order, one at a time. Within a source file, generate runs generators in the order they appear in the file, one at a time. The go generate tool also sets the build tag "generate" so that files may be examined by go generate but ignored during build.
For packages with invalid code, generate processes only source files with a valid package clause.
If any generator returns an error exit status, "go generate" skips all further processing for that package.
The generator is run in the package's source directory.
Go generate accepts two specific flags:
-run="" if non-empty, specifies a regular expression to select directives whose full original source text (excluding any trailing spaces and final newline) matches the expression. -skip="" if non-empty, specifies a regular expression to suppress directives whose full original source text (excluding any trailing spaces and final newline) matches the expression. If a directive matches both the -run and the -skip arguments, it is skipped.
It also accepts the standard build flags including -v, -n, and -x. The -v flag prints the names of packages and files as they are processed. The -n flag prints commands that would be executed. The -x flag prints commands as they are executed.
For more about build flags, see 'go help build'.
For more about specifying packages, see 'go help packages'.
Add dependencies to current module and install them ¶
Usage:
go get [-t] [-u] [-tool] [build flags] [packages]
Get resolves its command-line arguments to packages at specific module versions, updates go.mod to require those versions, and downloads source code into the module cache.
To add a dependency for a package or upgrade it to its latest version:
go get example.com/pkg
To upgrade or downgrade a package to a specific version:
go get example.com/pkg@v1.2.3
To remove a dependency on a module and downgrade modules that require it:
go get example.com/mod@none
To upgrade the minimum required Go version to the latest released Go version:
go get go@latest
To upgrade the Go toolchain to the latest patch release of the current Go toolchain:
go get toolchain@patch
See https://go.dev/ref/mod#go-get for details.
In earlier versions of Go, 'go get' was used to build and install packages. Now, 'go get' is dedicated to adjusting dependencies in go.mod. 'go install' may be used to build and install commands instead. When a version is specified, 'go install' runs in module-aware mode and ignores the go.mod file in the current directory. For example:
go install example.com/pkg@v1.2.3 go install example.com/pkg@latest
See 'go help install' or https://go.dev/ref/mod#go-install for details.
'go get' accepts the following flags.
The -t flag instructs get to consider modules needed to build tests of packages specified on the command line.
The -u flag instructs get to update modules providing dependencies of packages named on the command line to use newer minor or patch releases when available.
The -u=patch flag (not -u patch) also instructs get to update dependencies, but changes the default to select patch releases.
When the -t and -u flags are used together, get will update test dependencies as well.
The -tool flag instructs go to add a matching tool line to go.mod for each listed package. If -tool is used with @none, the line will be removed. See 'go help tool' for more information.
The -x flag prints commands as they are executed. This is useful for debugging version control commands when a module is downloaded directly from a repository.
For more about build flags, see 'go help build'.
For more about modules, see https://go.dev/ref/mod.
For more about using 'go get' to update the minimum Go version and suggested Go toolchain, see https://go.dev/doc/toolchain.
For more about specifying packages, see 'go help packages'.
See also: go build, go install, go clean, go mod.
Compile and install packages and dependencies ¶
Usage:
go install [build flags] [packages]
Install compiles and installs the packages named by the import paths.
Executables are installed in the directory named by the GOBIN environment variable, which defaults to $GOPATH/bin or $HOME/go/bin if the GOPATH environment variable is not set. Executables in $GOROOT are installed in $GOROOT/bin or $GOTOOLDIR instead of $GOBIN. Cross compiled binaries are installed in $GOOS_$GOARCH subdirectories of the above.
If the arguments have version suffixes (like @latest or @v1.0.0), "go install" builds packages in module-aware mode, ignoring the go.mod file in the current directory or any parent directory, if there is one. This is useful for installing executables without affecting the dependencies of the main module. To eliminate ambiguity about which module versions are used in the build, the arguments must satisfy the following constraints:
- Arguments must be package paths or package patterns (with "..." wildcards). They must not be standard packages (like fmt), meta-patterns (std, cmd, all), or relative or absolute file paths.
- All arguments must have the same version suffix. Different queries are not allowed, even if they refer to the same version.
- All arguments must refer to packages in the same module at the same version.
- Package path arguments must refer to main packages. Pattern arguments will only match main packages.
- No module is considered the "main" module. If the module containing packages named on the command line has a go.mod file, it must not contain directives (replace and exclude) that would cause it to be interpreted differently than if it were the main module. The module must not require a higher version of itself.
- Vendor directories are not used in any module. (Vendor directories are not included in the module zip files downloaded by 'go install'.)
If the arguments don't have version suffixes, "go install" may run in module-aware mode or GOPATH mode, depending on the GO111MODULE environment variable and the presence of a go.mod file. See 'go help modules' for details. If module-aware mode is enabled, "go install" runs in the context of the main module.
When module-aware mode is disabled, non-main packages are installed in the directory $GOPATH/pkg/$GOOS_$GOARCH. When module-aware mode is enabled, non-main packages are built and cached but not installed.
Before Go 1.20, the standard library was installed to $GOROOT/pkg/$GOOS_$GOARCH. Starting in Go 1.20, the standard library is built and cached but not installed. Setting GODEBUG=installgoroot=all restores the use of $GOROOT/pkg/$GOOS_$GOARCH.
For more about build flags, see 'go help build'.
For more about specifying packages, see 'go help packages'.
See also: go build, go get, go clean.
List packages or modules ¶
Usage:
go list [-f format] [-json] [-m] [list flags] [build flags] [packages]
List lists the named packages, one per line. The most commonly-used flags are -f and -json, which control the form of the output printed for each package. Other list flags, documented below, control more specific details.
The default output shows the package import path:
bytes encoding/json github.com/gorilla/mux golang.org/x/net/html
The -f flag specifies an alternate format for the list, using the syntax of package template. The default output is equivalent to -f '{{.ImportPath}}'. The struct being passed to the template is:
type Package struct {
Dir string // directory containing package sources
ImportPath string // import path of package in dir
ImportComment string // path in import comment on package statement
Name string // package name
Doc string // package documentation string
Target string // install path
Shlib string // the shared library that contains this package (only set when -linkshared)
Goroot bool // is this package in the Go root?
Standard bool // is this package part of the standard Go library?
Stale bool // would 'go install' do anything for this package?
StaleReason string // explanation for Stale==true
Root string // Go root or Go path dir containing this package
ConflictDir string // this directory shadows Dir in $GOPATH
BinaryOnly bool // binary-only package (no longer supported)
ForTest string // package is only for use in named test
Export string // file containing export data (when using -export)
BuildID string // build ID of the compiled package (when using -export)
Module *Module // info about package's containing module, if any (can be nil)
Match []string // command-line patterns matching this package
DepOnly bool // package is only a dependency, not explicitly listed
DefaultGODEBUG string // default GODEBUG setting, for main packages
// Source files
GoFiles []string // .go source files (excluding CgoFiles, TestGoFiles, XTestGoFiles)
CgoFiles []string // .go source files that import "C"
CompiledGoFiles []string // .go files presented to compiler (when using -compiled)
IgnoredGoFiles []string // .go source files ignored due to build constraints
IgnoredOtherFiles []string // non-.go source files ignored due to build constraints
CFiles []string // .c source files
CXXFiles []string // .cc, .cxx and .cpp source files
MFiles []string // .m source files
HFiles []string // .h, .hh, .hpp and .hxx source files
FFiles []string // .f, .F, .for and .f90 Fortran source files
SFiles []string // .s source files
SwigFiles []string // .swig files
SwigCXXFiles []string // .swigcxx files
SysoFiles []string // .syso object files to add to archive
TestGoFiles []string // _test.go files in package
XTestGoFiles []string // _test.go files outside package
// Embedded files
EmbedPatterns []string // //go:embed patterns
EmbedFiles []string // files matched by EmbedPatterns
TestEmbedPatterns []string // //go:embed patterns in TestGoFiles
TestEmbedFiles []string // files matched by TestEmbedPatterns
XTestEmbedPatterns []string // //go:embed patterns in XTestGoFiles
XTestEmbedFiles []string // files matched by XTestEmbedPatterns
// Cgo directives
CgoCFLAGS []string // cgo: flags for C compiler
CgoCPPFLAGS []string // cgo: flags for C preprocessor
CgoCXXFLAGS []string // cgo: flags for C++ compiler
CgoFFLAGS []string // cgo: flags for Fortran compiler
CgoLDFLAGS []string // cgo: flags for linker
CgoPkgConfig []string // cgo: pkg-config names
// Dependency information
Imports []string // import paths used by this package
ImportMap map[string]string // map from source import to ImportPath (identity entries omitted)
Deps []string // all (recursively) imported dependencies
TestImports []string // imports from TestGoFiles
XTestImports []string // imports from XTestGoFiles
// Error information
Incomplete bool // this package or a dependency has an error
Error *PackageError // error loading package
DepsErrors []*PackageError // errors loading dependencies
}
Packages stored in vendor directories report an ImportPath that includes the path to the vendor directory (for example, "d/vendor/p" instead of "p"), so that the ImportPath uniquely identifies a given copy of a package. The Imports, Deps, TestImports, and XTestImports lists also contain these expanded import paths. See golang.org/s/go15vendor for more about vendoring.
The error information, if any, is
type PackageError struct {
ImportStack []string // shortest path from package named on command line to this one
Pos string // position of error (if present, file:line:col)
Err string // the error itself
}
The module information is a Module struct, defined in the discussion of list -m below.
The template function "join" calls strings.Join.
The template function "context" returns the build context, defined as:
type Context struct {
GOARCH string // target architecture
GOOS string // target operating system
GOROOT string // Go root
GOPATH string // Go path
CgoEnabled bool // whether cgo can be used
UseAllFiles bool // use files regardless of //go:build lines, file names
Compiler string // compiler to assume when computing target paths
BuildTags []string // build constraints to match in //go:build lines
ToolTags []string // toolchain-specific build constraints
ReleaseTags []string // releases the current release is compatible with
InstallSuffix string // suffix to use in the name of the install dir
}
For more information about the meaning of these fields see the documentation for the go/build package's Context type.
The -json flag causes the package data to be printed in JSON format instead of using the template format. The JSON flag can optionally be provided with a set of comma-separated required field names to be output. If so, those required fields will always appear in JSON output, but others may be omitted to save work in computing the JSON struct.
The -compiled flag causes list to set CompiledGoFiles to the Go source files presented to the compiler. Typically this means that it repeats the files listed in GoFiles and then also adds the Go code generated by processing CgoFiles and SwigFiles. The Imports list contains the union of all imports from both GoFiles and CompiledGoFiles.
The -deps flag causes list to iterate over not just the named packages but also all their dependencies. It visits them in a depth-first post-order traversal, so that a package is listed only after all its dependencies. Packages not explicitly listed on the command line will have the DepOnly field set to true.
The -e flag changes the handling of erroneous packages, those that cannot be found or are malformed. By default, the list command prints an error to standard error for each erroneous package and omits the packages from consideration during the usual printing. With the -e flag, the list command never prints errors to standard error and instead processes the erroneous packages with the usual printing. Erroneous packages will have a non-empty ImportPath and a non-nil Error field; other information may or may not be missing (zeroed).
The -export flag causes list to set the Export field to the name of a file containing up-to-date export information for the given package, and the BuildID field to the build ID of the compiled package.
The -find flag causes list to identify the named packages but not resolve their dependencies: the Imports and Deps lists will be empty. With the -find flag, the -deps, -test and -export commands cannot be used.
The -test flag causes list to report not only the named packages but also their test binaries (for packages with tests), to convey to source code analysis tools exactly how test binaries are constructed. The reported import path for a test binary is the import path of the package followed by a ".test" suffix, as in "math/rand.test". When building a test, it is sometimes necessary to rebuild certain dependencies specially for that test (most commonly the tested package itself). The reported import path of a package recompiled for a particular test binary is followed by a space and the name of the test binary in brackets, as in "math/rand math/rand.test" or "regexp [sort.test]". The ForTest field is also set to the name of the package being tested ("math/rand" or "sort" in the previous examples).
The Dir, Target, Shlib, Root, ConflictDir, and Export file paths are all absolute paths.
By default, the lists GoFiles, CgoFiles, and so on hold names of files in Dir (that is, paths relative to Dir, not absolute paths). The generated files added when using the -compiled and -test flags are absolute paths referring to cached copies of generated Go source files. Although they are Go source files, the paths may not end in ".go".
The -m flag causes list to list modules instead of packages.
When listing modules, the -f flag still specifies a format template applied to a Go struct, but now a Module struct:
type Module struct {
Path string // module path
Query string // version query corresponding to this version
Version string // module version
Versions []string // available module versions
Replace *Module // replaced by this module
Time *time.Time // time version was created
Update *Module // available update (with -u)
Main bool // is this the main module?
Indirect bool // module is only indirectly needed by main module
Dir string // directory holding local copy of files, if any
GoMod string // path to go.mod file describing module, if any
GoVersion string // go version used in module
Retracted []string // retraction information, if any (with -retracted or -u)
Deprecated string // deprecation message, if any (with -u)
Error *ModuleError // error loading module
Sum string // checksum for path, version (as in go.sum)
GoModSum string // checksum for go.mod (as in go.sum)
Origin any // provenance of module
Reuse bool // reuse of old module info is safe
}
type ModuleError struct {
Err string // the error itself
}
The file GoMod refers to may be outside the module directory if the module is in the module cache or if the -modfile flag is used.
The default output is to print the module path and then information about the version and replacement if any. For example, 'go list -m all' might print:
my/main/module golang.org/x/text v0.3.0 => /tmp/text rsc.io/pdf v0.1.1
The Module struct has a String method that formats this line of output, so that the default format is equivalent to -f '{{.String}}'.
Note that when a module has been replaced, its Replace field describes the replacement module, and its Dir field is set to the replacement's source code, if present. (That is, if Replace is non-nil, then Dir is set to Replace.Dir, with no access to the replaced source code.)
The -u flag adds information about available upgrades. When the latest version of a given module is newer than the current one, list -u sets the Module's Update field to information about the newer module. list -u will also set the module's Retracted field if the current version is retracted. The Module's String method indicates an available upgrade by formatting the newer version in brackets after the current version. If a version is retracted, the string "(retracted)" will follow it. For example, 'go list -m -u all' might print:
my/main/module golang.org/x/text v0.3.0 [v0.4.0] => /tmp/text rsc.io/pdf v0.1.1 (retracted) [v0.1.2]
(For tools, 'go list -m -u -json all' may be more convenient to parse.)
The -versions flag causes list to set the Module's Versions field to a list of all known versions of that module, ordered according to semantic versioning, earliest to latest. The flag also changes the default output format to display the module path followed by the space-separated version list.
The -retracted flag causes list to report information about retracted module versions. When -retracted is used with -f or -json, the Retracted field explains why the version was retracted. The strings are taken from comments on the retract directive in the module's go.mod file. When -retracted is used with -versions, retracted versions are listed together with unretracted versions. The -retracted flag may be used with or without -m.
The arguments to list -m are interpreted as a list of modules, not packages. The main module is the module containing the current directory. The active modules are the main module and its dependencies. With no arguments, list -m shows the main module. With arguments, list -m shows the modules specified by the arguments. Any of the active modules can be specified by its module path. The special pattern "all" specifies all the active modules, first the main module and then dependencies sorted by module path. A pattern containing "..." specifies the active modules whose module paths match the pattern. A query of the form path@version specifies the result of that query, which is not limited to active modules. See 'go help modules' for more about module queries.
The template function "module" takes a single string argument that must be a module path or query and returns the specified module as a Module struct. If an error occurs, the result will be a Module struct with a non-nil Error field.
When using -m, the -reuse=old.json flag accepts the name of file containing the JSON output of a previous 'go list -m -json' invocation with the same set of modifier flags (such as -u, -retracted, and -versions). The go command may use this file to determine that a module is unchanged since the previous invocation and avoid redownloading information about it. Modules that are not redownloaded will be marked in the new output by setting the Reuse field to true. Normally the module cache provides this kind of reuse automatically; the -reuse flag can be useful on systems that do not preserve the module cache.
For more about build flags, see 'go help build'.
For more about specifying packages, see 'go help packages'.
For more about modules, see https://go.dev/ref/mod.
Module maintenance ¶
Go mod provides access to operations on modules.
Note that support for modules is built into all the go commands, not just 'go mod'. For example, day-to-day adding, removing, upgrading, and downgrading of dependencies should be done using 'go get'. See 'go help modules' for an overview of module functionality.
Usage:
go mod <command> [arguments]
The commands are:
download download modules to local cache edit edit go.mod from tools or scripts graph print module requirement graph init initialize new module in current directory tidy add missing and remove unused modules vendor make vendored copy of dependencies verify verify dependencies have expected content why explain why packages or modules are needed
Use "go help mod <command>" for more information about a command.
Download modules to local cache ¶
Usage:
go mod download [-x] [-json] [-reuse=old.json] [modules]
Download downloads the named modules, which can be module patterns selecting dependencies of the main module or module queries of the form path@version.
With no arguments, download applies to the modules needed to build and test the packages in the main module: the modules explicitly required by the main module if it is at 'go 1.17' or higher, or all transitively-required modules if at 'go 1.16' or lower.
The go command will automatically download modules as needed during ordinary execution. The "go mod download" command is useful mainly for pre-filling the local cache or to compute the answers for a Go module proxy.
By default, download writes nothing to standard output. It may print progress messages and errors to standard error.
The -json flag causes download to print a sequence of JSON objects to standard output, describing each downloaded module (or failure), corresponding to this Go struct:
type Module struct {
Path string // module path
Query string // version query corresponding to this version
Version string // module version
Error string // error loading module
Info string // absolute path to cached .info file
GoMod string // absolute path to cached .mod file
Zip string // absolute path to cached .zip file
Dir string // absolute path to cached source root directory
Sum string // checksum for path, version (as in go.sum)
GoModSum string // checksum for go.mod (as in go.sum)
Origin any // provenance of module
Reuse bool // reuse of old module info is safe
}
The -reuse flag accepts the name of file containing the JSON output of a previous 'go mod download -json' invocation. The go command may use this file to determine that a module is unchanged since the previous invocation and avoid redownloading it. Modules that are not redownloaded will be marked in the new output by setting the Reuse field to true. Normally the module cache provides this kind of reuse automatically; the -reuse flag can be useful on systems that do not preserve the module cache.
The -x flag causes download to print the commands download executes.
See https://go.dev/ref/mod#go-mod-download for more about 'go mod download'.
See https://go.dev/ref/mod#version-queries for more about version queries.
Edit go.mod from tools or scripts ¶
Usage:
go mod edit [editing flags] [-fmt|-print|-json] [go.mod]
Edit provides a command-line interface for editing go.mod, for use primarily by tools or scripts. It reads only go.mod; it does not look up information about the modules involved. By default, edit reads and writes the go.mod file of the main module, but a different target file can be specified after the editing flags.
The editing flags specify a sequence of editing operations.
The -fmt flag reformats the go.mod file without making other changes. This reformatting is also implied by any other modifications that use or rewrite the go.mod file. The only time this flag is needed is if no other flags are specified, as in 'go mod edit -fmt'.
The -module flag changes the module's path (the go.mod file's module line).
The -godebug=key=value flag adds a godebug key=value line, replacing any existing godebug lines with the given key.
The -dropgodebug=key flag drops any existing godebug lines with the given key.
The -require=path@version and -droprequire=path flags add and drop a requirement on the given module path and version. Note that -require overrides any existing requirements on path. These flags are mainly for tools that understand the module graph. Users should prefer 'go get path@version' or 'go get path@none', which make other go.mod adjustments as needed to satisfy constraints imposed by other modules.
The -go=version flag sets the expected Go language version. This flag is mainly for tools that understand Go version dependencies. It takes a version like "1.26" or "1.26.2". Using the version "none" removes the go directive. Users should prefer 'go get go@version'.
The -toolchain=name flag sets the Go toolchain to use. This flag is mainly for tools that understand Go version dependencies. It takes a toolchain name like "go1.26" or "go1.26.2". Using the name "none" removes the toolchain directive. Users should prefer 'go get toolchain@version'.
The -exclude=path@version and -dropexclude=path@version flags add and drop an exclusion for the given module path and version. Note that -exclude=path@version is a no-op if that exclusion already exists.
The -replace=old[@v]=new[@v] flag adds a replacement of the given module path and version pair. If the @v in old@v is omitted, a replacement without a version on the left side is added, which applies to all versions of the old module path. If the @v in new@v is omitted, the new path should be a local module root directory, not a module path. Note that -replace overrides any redundant replacements for old[@v], so omitting @v will drop existing replacements for specific versions.
The -dropreplace=old[@v] flag drops a replacement of the given module path and version pair. If the @v is omitted, a replacement without a version on the left side is dropped.
The -retract=version and -dropretract=version flags add and drop a retraction on the given version. The version may be a single version like "v1.2.3" or a closed interval like "[v1.1.0,v1.1.9]". Note that -retract=version is a no-op if that retraction already exists.
The -tool=path and -droptool=path flags add and drop a tool declaration for the given path.
The -ignore=path and -dropignore=path flags add and drop a ignore declaration for the given path.
The -godebug, -dropgodebug, -require, -droprequire, -exclude, -dropexclude, -replace, -dropreplace, -retract, -dropretract, -tool, -droptool, -ignore, and -dropignore editing flags may be repeated, and the changes are applied in the order given.
The -print flag prints the final go.mod in its text format instead of writing it back to go.mod.
The -json flag prints the final go.mod file in JSON format instead of writing it back to go.mod. The JSON output corresponds to these Go types:
type GoMod struct {
Module ModPath
Go string
Toolchain string
Godebug []Godebug
Require []Require
Exclude []Module
Replace []Replace
Retract []Retract
Tool []Tool
Ignore []Ignore
}
type Module struct {
Path string
Version string
}
type ModPath struct {
Path string
Deprecated string
}
type Godebug struct {
Key string
Value string
}
type Require struct {
Path string
Version string
Indirect bool
}
type Replace struct {
Old Module
New Module
}
type Retract struct {
Low string
High string
Rationale string
}
type Tool struct {
Path string
}
type Ignore struct {
Path string
}
Retract entries representing a single version (not an interval) will have the "Low" and "High" fields set to the same value.
Note that this only describes the go.mod file itself, not other modules referred to indirectly. For the full set of modules available to a build, use 'go list -m -json all'.
Edit also provides the -C, -n, and -x build flags.
See https://go.dev/ref/mod#go-mod-edit for more about 'go mod edit'.
Print module requirement graph ¶
Usage:
go mod graph [-go=version] [-x]
Graph prints the module requirement graph (with replacements applied) in text form. Each line in the output has two space-separated fields: a module and one of its requirements. Each module is identified as a string of the form path@version, except for the main module, which has no @version suffix.
The -go flag causes graph to report the module graph as loaded by the given Go version, instead of the version indicated by the 'go' directive in the go.mod file.
The -x flag causes graph to print the commands graph executes.
See https://go.dev/ref/mod#go-mod-graph for more about 'go mod graph'.
Initialize new module in current directory ¶
Usage:
go mod init [module-path]
Init initializes and writes a new go.mod file in the current directory, in effect creating a new module rooted at the current directory. The go.mod file must not already exist.
Init accepts one optional argument, the module path for the new module. If the module path argument is omitted, init will attempt to infer the module path using import comments in .go files and the current directory (if in GOPATH).
See https://go.dev/ref/mod#go-mod-init for more about 'go mod init'.
Add missing and remove unused modules ¶
Usage:
go mod tidy [-e] [-v] [-x] [-diff] [-go=version] [-compat=version]
Tidy makes sure go.mod matches the source code in the module. It adds any missing modules necessary to build the current module's packages and dependencies, and it removes unused modules that don't provide any relevant packages. It also adds any missing entries to go.sum and removes any unnecessary ones.
The -v flag causes tidy to print information about removed modules to standard error.
The -e flag causes tidy to attempt to proceed despite errors encountered while loading packages.
The -diff flag causes tidy not to modify go.mod or go.sum but instead print the necessary changes as a unified diff. It exits with a non-zero code if the diff is not empty.
The -go flag causes tidy to update the 'go' directive in the go.mod file to the given version, which may change which module dependencies are retained as explicit requirements in the go.mod file. (Go versions 1.17 and higher retain more requirements in order to support lazy module loading.)
The -compat flag preserves any additional checksums needed for the 'go' command from the indicated major Go release to successfully load the module graph, and causes tidy to error out if that version of the 'go' command would load any imported package from a different module version. By default, tidy acts as if the -compat flag were set to the version prior to the one indicated by the 'go' directive in the go.mod file.
The -x flag causes tidy to print the commands download executes.
See https://go.dev/ref/mod#go-mod-tidy for more about 'go mod tidy'.
Make vendored copy of dependencies ¶
Usage:
go mod vendor [-e] [-v] [-o outdir]
Vendor resets the main module's vendor directory to include all packages needed to build and test all the main module's packages. It does not include test code for vendored packages.
The -v flag causes vendor to print the names of vendored modules and packages to standard error.
The -e flag causes vendor to attempt to proceed despite errors encountered while loading packages.
The -o flag causes vendor to create the vendor directory at the given path instead of "vendor". The go command can only use a vendor directory named "vendor" within the module root directory, so this flag is primarily useful for other tools.
See https://go.dev/ref/mod#go-mod-vendor for more about 'go mod vendor'.
Verify dependencies have expected content ¶
Usage:
go mod verify
Verify checks that the dependencies of the current module, which are stored in a local downloaded source cache, have not been modified since being downloaded. If all the modules are unmodified, verify prints "all modules verified." Otherwise it reports which modules have been changed and causes 'go mod' to exit with a non-zero status.
See https://go.dev/ref/mod#go-mod-verify for more about 'go mod verify'.
Explain why packages or modules are needed ¶
Usage:
go mod why [-m] [-vendor] packages...
Why shows a shortest path in the import graph from the main module to each of the listed packages. If the -m flag is given, why treats the arguments as a list of modules and finds a path to any package in each of the modules.
By default, why queries the graph of packages matched by "go list all", which includes tests for reachable packages. The -vendor flag causes why to exclude tests of dependencies.
The output is a sequence of stanzas, one for each package or module name on the command line, separated by blank lines. Each stanza begins with a comment line "# package" or "# module" giving the target package or module. Subsequent lines give a path through the import graph, one package per line. If the package or module is not referenced from the main module, the stanza will display a single parenthesized note indicating that fact.
For example:
$ go mod why golang.org/x/text/language golang.org/x/text/encoding # golang.org/x/text/language rsc.io/quote rsc.io/sampler golang.org/x/text/language # golang.org/x/text/encoding (main module does not need package golang.org/x/text/encoding) $
See https://go.dev/ref/mod#go-mod-why for more about 'go mod why'.
Compile and run Go program ¶
Usage:
go run [build flags] [-exec xprog] package [arguments...]
Run compiles and runs the named main Go package. Typically the package is specified as a list of .go source files from a single directory, but it may also be an import path, file system path, or pattern matching a single known package, as in 'go run .' or 'go run my/cmd'.
If the package argument has a version suffix (like @latest or @v1.0.0), "go run" builds the program in module-aware mode, ignoring the go.mod file in the current directory or any parent directory, if there is one. This is useful for running programs without affecting the dependencies of the main module.
If the package argument doesn't have a version suffix, "go run" may run in module-aware mode or GOPATH mode, depending on the GO111MODULE environment variable and the presence of a go.mod file. See 'go help modules' for details. If module-aware mode is enabled, "go run" runs in the context of the main module.
By default, 'go run' runs the compiled binary directly: 'a.out arguments...'. If the -exec flag is given, 'go run' invokes the binary using xprog:
'xprog a.out arguments...'.
If the -exec flag is not given, GOOS or GOARCH is different from the system default, and a program named go_$GOOS_$GOARCH_exec can be found on the current search path, 'go run' invokes the binary using that program, for example 'go_js_wasm_exec a.out arguments...'. This allows execution of cross-compiled programs when a simulator or other execution method is available.
By default, 'go run' compiles the binary without generating the information used by debuggers, to reduce build time. To include debugger information in the binary, use 'go build'.
The go command places $GOROOT/bin at the beginning of $PATH in the subprocess environment, so that subprocesses that execute 'go' commands use the same 'go' as their parent.
The exit status of Run is not the exit status of the compiled binary.
For more about build flags, see 'go help build'. For more about specifying packages, see 'go help packages'.
See also: go build.
Manage telemetry data and settings ¶
Usage:
go telemetry [off|local|on]
Telemetry is used to manage Go telemetry data and settings.
Telemetry can be in one of three modes: off, local, or on.
When telemetry is in local mode, counter data is written to the local file system, but will not be uploaded to remote servers.
When telemetry is off, local counter data is neither collected nor uploaded.
When telemetry is on, telemetry data is written to the local file system and periodically sent to https://telemetry.go.dev/. Uploaded data is used to help improve the Go toolchain and related tools, and it will be published as part of a public dataset.
For more details, see https://telemetry.go.dev/privacy. This data is collected in accordance with the Google Privacy Policy (https://policies.google.com/privacy).
To view the current telemetry mode, run "go telemetry". To disable telemetry uploading, but keep local data collection, run "go telemetry local". To enable both collection and uploading, run “go telemetry on”. To disable both collection and uploading, run "go telemetry off".
The current telemetry mode is also available as the value of the non-settable "GOTELEMETRY" go env variable. The directory in the local file system that telemetry data is written to is available as the value of the non-settable "GOTELEMETRYDIR" go env variable.
See https://go.dev/doc/telemetry for more information on telemetry.
Test packages ¶
Usage:
go test [build/test flags] [packages] [build/test flags & test binary flags]
'Go test' automates testing the packages named by the import paths. It prints a summary of the test results in the format:
ok archive/tar 0.011s FAIL archive/zip 0.022s ok compress/gzip 0.033s ...
followed by detailed output for each failed package.
'Go test' recompiles each package along with any files with names matching the file pattern "*_test.go". These additional files can contain test functions, benchmark functions, fuzz tests and example functions. See 'go help testfunc' for more. Each listed package causes the execution of a separate test binary. Files whose names begin with "_" (including "_test.go") or "." are ignored.
Test files that declare a package with the suffix "_test" will be compiled as a separate package, and then linked and run with the main test binary.
The go tool will ignore a directory named "testdata", making it available to hold ancillary data needed by the tests.
As part of building a test binary, go test runs go vet on the package and its test source files to identify significant problems. If go vet finds any problems, go test reports those and does not run the test binary. Only a high-confidence subset of the default go vet checks are used. That subset is: atomic, bools, buildtag, directive, errorsas, ifaceassert, nilfunc, printf, stdversion, stringintconv, and tests. You can see the documentation for these and other vet tests via "go doc cmd/vet". To disable the running of go vet, use the -vet=off flag. To run all checks, use the -vet=all flag.
All test output and summary lines are printed to the go command's standard output, even if the test printed them to its own standard error. (The go command's standard error is reserved for printing errors building the tests.)
The go command places $GOROOT/bin at the beginning of $PATH in the test's environment, so that tests that execute 'go' commands use the same 'go' as the parent 'go test' command.
Go test runs in two different modes:
The first, called local directory mode, occurs when go test is invoked with no package arguments (for example, 'go test' or 'go test -v'). In this mode, go test compiles the package sources and tests found in the current directory and then runs the resulting test binary. In this mode, caching (discussed below) is disabled. After the package test finishes, go test prints a summary line showing the test status ('ok' or 'FAIL'), package name, and elapsed time.
The second, called package list mode, occurs when go test is invoked with explicit package arguments (for example 'go test math', 'go test ./...', and even 'go test .'). In this mode, go test compiles and tests each of the packages listed on the command line. If a package test passes, go test prints only the final 'ok' summary line. If a package test fails, go test prints the full test output. If invoked with the -bench or -v flag, go test prints the full output even for passing package tests, in order to display the requested benchmark results or verbose logging. After the package tests for all of the listed packages finish, and their output is printed, go test prints a final 'FAIL' status if any package test has failed.
In package list mode only, go test caches successful package test results to avoid unnecessary repeated running of tests. When the result of a test can be recovered from the cache, go test will redisplay the previous output instead of running the test binary again. When this happens, go test prints '(cached)' in place of the elapsed time in the summary line.
The rule for a match in the cache is that the run involves the same test binary and the flags on the command line come entirely from a restricted set of 'cacheable' test flags, defined as -benchtime, -coverprofile, -cpu, -failfast, -fullpath, -list, -outputdir, -parallel, -run, -short, -skip, -timeout and -v. If a run of go test has any test or non-test flags outside this set, the result is not cached. To disable test caching, use any test flag or argument other than the cacheable flags. The idiomatic way to disable test caching explicitly is to use -count=1. Tests that open files within the package's module or that consult environment variables only match future runs in which the files and environment variables are unchanged. A cached test result is treated as executing in no time at all, so a successful package test result will be cached and reused regardless of -timeout setting.
In addition to the build flags, the flags handled by 'go test' itself are:
-args
Pass the remainder of the command line (everything after -args)
to the test binary, uninterpreted and unchanged.
Because this flag consumes the remainder of the command line,
the package list (if present) must appear before this flag.
-c
Compile the test binary to pkg.test in the current directory but do not run it
(where pkg is the last element of the package's import path).
The file name or target directory can be changed with the -o flag.
-exec xprog
Run the test binary using xprog. The behavior is the same as
in 'go run'. See 'go help run' for details.
-json
Convert test output to JSON suitable for automated processing.
See 'go doc test2json' for the encoding details.
Also emits build output in JSON. See 'go help buildjson'.
-o file
Save a copy of the test binary to the named file.
The test still runs (unless -c is specified).
If file ends in a slash or names an existing directory,
the test is written to pkg.test in that directory.
The test binary also accepts flags that control execution of the test; these flags are also accessible by 'go test'. See 'go help testflag' for details.
For more about build flags, see 'go help build'. For more about specifying packages, see 'go help packages'.
See also: go build, go vet.
Run specified go tool ¶
Usage:
go tool [-n] command [args...]
Tool runs the go tool command identified by the arguments.
Go ships with a number of builtin tools, and additional tools may be defined in the go.mod of the current module. 'go get -tool' can be used to define additional tools in the current module's go.mod file. See 'go help get' for more information.
The command can be specified using the full package path to the tool declared with a tool directive. The default binary name of the tool, which is the last component of the package path, excluding the major version suffix, can also be used if it is unique among declared tools.
With no arguments it prints the list of known tools.
The -n flag causes tool to print the command that would be executed but not execute it.
The -modfile=file.mod build flag causes tool to use an alternate file instead of the go.mod in the module root directory.
Tool also provides the -C, -overlay, and -modcacherw build flags.
The go command places $GOROOT/bin at the beginning of $PATH in the environment of commands run via tool directives, so that they use the same 'go' as the parent 'go tool'.
For more about build flags, see 'go help build'.
For more about each builtin tool command, see 'go doc cmd/<command>'.
Print Go version ¶
Usage:
go version [-m] [-v] [-json] [file ...]
Version prints the build information for Go binary files.
Go version reports the Go version used to build each of the named files.
If no files are named on the command line, go version prints its own version information.
If a directory is named, go version walks that directory, recursively, looking for recognized Go binaries and reporting their versions. By default, go version does not report unrecognized files found during a directory scan. The -v flag causes it to report unrecognized files.
The -m flag causes go version to print each file's embedded module version information, when available. In the output, the module information consists of multiple lines following the version line, each indented by a leading tab character.
The -json flag is similar to -m but outputs the runtime/debug.BuildInfo in JSON format. If flag -json is specified without -m, go version reports an error.
See also: go doc runtime/debug.BuildInfo.
Report likely mistakes in packages ¶
Usage:
go vet [build flags] [-vettool prog] [vet flags] [packages]
Vet runs the Go vet tool (cmd/vet) on the named packages and reports diagnostics.
It supports these flags:
-c int display offending line with this many lines of context (default -1) -json emit JSON output -fix instead of printing each diagnostic, apply its first fix (if any) -diff instead of applying each fix, print the patch as a unified diff; exit with a non-zero status if the diff is not empty
The -vettool=prog flag selects a different analysis tool with alternative or additional checks. For example, the 'shadow' analyzer can be built and run using these commands:
go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow@latest go vet -vettool=$(which shadow)
Alternative vet tools should be built atop golang.org/x/tools/go/analysis/unitchecker, which handles the interaction with go vet.
The default vet tool is 'go tool vet' or cmd/vet. For help on its checkers and their flags, run 'go tool vet help'. For details of a specific checker such as 'printf', see 'go tool vet help printf'.
For more about specifying packages, see 'go help packages'.
The build flags supported by go vet are those that control package resolution and execution, such as -C, -n, -x, -v, -tags, and -toolexec. For more about these flags, see 'go help build'.
See also: go fmt, go fix.
Workspace maintenance ¶
Work provides access to operations on workspaces.
Note that support for workspaces is built into many other commands, not just 'go work'.
See 'go help modules' for information about Go's module system of which workspaces are a part.
See https://go.dev/ref/mod#workspaces for an in-depth reference on workspaces.
See https://go.dev/doc/tutorial/workspaces for an introductory tutorial on workspaces.
A workspace is specified by a go.work file that specifies a set of module directories with the "use" directive. These modules are used as root modules by the go command for builds and related operations. A workspace that does not specify modules to be used cannot be used to do builds from local modules.
go.work files are line-oriented. Each line holds a single directive, made up of a keyword followed by arguments. For example: