1 // Copyright 2011 The Go Authors. All rights reserved.
2 // Use of this source code is governed by a BSD-style
3 // license that can be found in the LICENSE file.
5 // Code generated by mkalldocs.sh; DO NOT EDIT.
6 // Edit the documentation in other files and rerun mkalldocs.sh to generate this one.
8 // Go is a tool for managing Go source code.
12 // go <command> [arguments]
16 // bug start a bug report
17 // build compile packages and dependencies
18 // clean remove object files and cached files
19 // doc show documentation for package or symbol
20 // env print Go environment information
21 // fix update packages to use new APIs
22 // fmt gofmt (reformat) package sources
23 // generate generate Go files by processing source
24 // get add dependencies to current module and install them
25 // install compile and install packages and dependencies
26 // list list packages or modules
27 // mod module maintenance
28 // run compile and run Go program
30 // tool run specified go tool
31 // version print Go version
32 // vet report likely mistakes in packages
34 // Use "go help <command>" for more information about a command.
36 // Additional help topics:
38 // buildmode build modes
39 // c calling between Go and C
40 // cache build and test caching
41 // environment environment variables
42 // filetype file types
43 // go.mod the go.mod file
44 // gopath GOPATH environment variable
45 // gopath-get legacy GOPATH go get
46 // goproxy module proxy protocol
47 // importpath import path syntax
48 // modules modules, module versions, and more
49 // module-get module-aware go get
50 // module-auth module authentication using go.sum
51 // module-private module configuration for non-public modules
52 // packages package lists and patterns
53 // testflag testing flags
54 // testfunc testing functions
56 // Use "go help <topic>" for more information about that topic.
65 // Bug opens the default browser and starts a new bug report.
66 // The report includes useful system information.
69 // Compile packages and dependencies
73 // go build [-o output] [-i] [build flags] [packages]
75 // Build compiles the packages named by the import paths,
76 // along with their dependencies, but it does not install the results.
78 // If the arguments to build are a list of .go files from a single directory,
79 // build treats them as a list of source files specifying a single package.
81 // When compiling packages, build ignores files that end in '_test.go'.
83 // When compiling a single main package, build writes
84 // the resulting executable to an output file named after
85 // the first source file ('go build ed.go rx.go' writes 'ed' or 'ed.exe')
86 // or the source code directory ('go build unix/sam' writes 'sam' or 'sam.exe').
87 // The '.exe' suffix is added when writing a Windows executable.
89 // When compiling multiple packages or a single non-main package,
90 // build compiles the packages but discards the resulting object,
91 // serving only as a check that the packages can be built.
93 // The -o flag forces build to write the resulting executable or object
94 // to the named output file or directory, instead of the default behavior described
95 // in the last two paragraphs. If the named output is a directory that exists,
96 // then any resulting executables will be written to that directory.
98 // The -i flag installs the packages that are dependencies of the target.
100 // The build flags are shared by the build, clean, get, install, list, run,
101 // and test commands:
104 // force rebuilding of packages that are already up-to-date.
106 // print the commands but do not run them.
108 // the number of programs, such as build commands or
109 // test binaries, that can be run in parallel.
110 // The default is the number of CPUs available.
112 // enable data race detection.
113 // Supported only on linux/amd64, freebsd/amd64, darwin/amd64 and windows/amd64.
115 // enable interoperation with memory sanitizer.
116 // Supported only on linux/amd64, linux/arm64
117 // and only with Clang/LLVM as the host C compiler.
119 // print the names of packages as they are compiled.
121 // print the name of the temporary work directory and
122 // do not delete it when exiting.
124 // print the commands.
126 // -asmflags '[pattern=]arg list'
127 // arguments to pass on each go tool asm invocation.
129 // build mode to use. See 'go help buildmode' for more.
131 // name of compiler to use, as in runtime.Compiler (gccgo or gc).
132 // -gccgoflags '[pattern=]arg list'
133 // arguments to pass on each gccgo compiler/linker invocation.
134 // -gcflags '[pattern=]arg list'
135 // arguments to pass on each go tool compile invocation.
136 // -installsuffix suffix
137 // a suffix to use in the name of the package installation directory,
138 // in order to keep output separate from default builds.
139 // If using the -race flag, the install suffix is automatically set to race
140 // or, if set explicitly, has _race appended to it. Likewise for the -msan
141 // flag. Using a -buildmode option that requires non-default compile flags
142 // has a similar effect.
143 // -ldflags '[pattern=]arg list'
144 // arguments to pass on each go tool link invocation.
146 // link against shared libraries previously created with
147 // -buildmode=shared.
149 // module download mode to use: readonly or vendor.
150 // See 'go help modules' for more.
152 // install and load all packages from dir instead of the usual locations.
153 // For example, when building with a non-standard configuration,
154 // use -pkgdir to keep generated packages in a separate location.
156 // a comma-separated list of build tags to consider satisfied during the
157 // build. For more information about build tags, see the description of
158 // build constraints in the documentation for the go/build package.
159 // (Earlier versions of Go used a space-separated list, and that form
160 // is deprecated but still recognized.)
162 // remove all file system paths from the resulting executable.
163 // Instead of absolute file system paths, the recorded file names
164 // will begin with either "go" (for the standard library),
165 // or a module path@version (when using modules),
166 // or a plain import path (when using GOPATH).
167 // -toolexec 'cmd args'
168 // a program to use to invoke toolchain programs like vet and asm.
169 // For example, instead of running asm, the go command will run
170 // 'cmd args /path/to/asm <arguments for asm>'.
172 // The -asmflags, -gccgoflags, -gcflags, and -ldflags flags accept a
173 // space-separated list of arguments to pass to an underlying tool
174 // during the build. To embed spaces in an element in the list, surround
175 // it with either single or double quotes. The argument list may be
176 // preceded by a package pattern and an equal sign, which restricts
177 // the use of that argument list to the building of packages matching
178 // that pattern (see 'go help packages' for a description of package
179 // patterns). Without a pattern, the argument list applies only to the
180 // packages named on the command line. The flags may be repeated
181 // with different patterns in order to specify different arguments for
182 // different sets of packages. If a package matches patterns given in
183 // multiple flags, the latest match on the command line wins.
184 // For example, 'go build -gcflags=-S fmt' prints the disassembly
185 // only for package fmt, while 'go build -gcflags=all=-S fmt'
186 // prints the disassembly for fmt and all its dependencies.
188 // For more about specifying packages, see 'go help packages'.
189 // For more about where packages and binaries are installed,
190 // run 'go help gopath'.
191 // For more about calling between Go and C/C++, run 'go help c'.
193 // Note: Build adheres to certain conventions such as those described
194 // by 'go help gopath'. Not all projects can follow these conventions,
195 // however. Installations that have their own conventions or that use
196 // a separate software build system may choose to use lower-level
197 // invocations such as 'go tool compile' and 'go tool link' to avoid
198 // some of the overheads and design decisions of the build tool.
200 // See also: go install, go get, go clean.
203 // Remove object files and cached files
207 // go clean [clean flags] [build flags] [packages]
209 // Clean removes object files from package source directories.
210 // The go command builds most objects in a temporary directory,
211 // so go clean is mainly concerned with object files left by other
212 // tools or by manual invocations of go build.
214 // If a package argument is given or the -i or -r flag is set,
215 // clean removes the following files from each of the
216 // source directories corresponding to the import paths:
218 // _obj/ old object directory, left from Makefiles
219 // _test/ old test directory, left from Makefiles
220 // _testmain.go old gotest file, left from Makefiles
221 // test.out old test log, left from Makefiles
222 // build.out old test log, left from Makefiles
223 // *.[568ao] object files, left from Makefiles
225 // DIR(.exe) from go build
226 // DIR.test(.exe) from go test -c
227 // MAINFILE(.exe) from go build MAINFILE.go
230 // In the list, DIR represents the final path element of the
231 // directory, and MAINFILE is the base name of any Go source
232 // file in the directory that is not included when building
235 // The -i flag causes clean to remove the corresponding installed
236 // archive or binary (what 'go install' would create).
238 // The -n flag causes clean to print the remove commands it would execute,
241 // The -r flag causes clean to be applied recursively to all the
242 // dependencies of the packages named by the import paths.
244 // The -x flag causes clean to print remove commands as it executes them.
246 // The -cache flag causes clean to remove the entire go build cache.
248 // The -testcache flag causes clean to expire all test results in the
251 // The -modcache flag causes clean to remove the entire module
252 // download cache, including unpacked source code of versioned
255 // For more about build flags, see 'go help build'.
257 // For more about specifying packages, see 'go help packages'.
260 // Show documentation for package or symbol
264 // go doc [-u] [-c] [package|[package.]symbol[.methodOrField]]
266 // Doc prints the documentation comments associated with the item identified by its
267 // arguments (a package, const, func, type, var, method, or struct field)
268 // followed by a one-line summary of each of the first-level items "under"
269 // that item (package-level declarations for a package, methods for a type,
272 // Doc accepts zero, one, or two arguments.
274 // Given no arguments, that is, when run as
278 // it prints the package documentation for the package in the current directory.
279 // If the package is a command (package main), the exported symbols of the package
280 // are elided from the presentation unless the -cmd flag is provided.
282 // When run with one argument, the argument is treated as a Go-syntax-like
283 // representation of the item to be documented. What the argument selects depends
284 // on what is installed in GOROOT and GOPATH, as well as the form of the argument,
285 // which is schematically one of these:
288 // go doc <sym>[.<methodOrField>]
289 // go doc [<pkg>.]<sym>[.<methodOrField>]
290 // go doc [<pkg>.][<sym>.]<methodOrField>
292 // The first item in this list matched by the argument is the one whose documentation
293 // is printed. (See the examples below.) However, if the argument starts with a capital
294 // letter it is assumed to identify a symbol or method in the current directory.
296 // For packages, the order of scanning is determined lexically in breadth-first order.
297 // That is, the package presented is the one that matches the search and is nearest
298 // the root and lexically first at its level of the hierarchy. The GOROOT tree is
299 // always scanned in its entirety before GOPATH.
301 // If there is no package specified or matched, the package in the current
302 // directory is selected, so "go doc Foo" shows the documentation for symbol Foo in
303 // the current package.
305 // The package path must be either a qualified path or a proper suffix of a
306 // path. The go tool's usual package mechanism does not apply: package path
307 // elements like . and ... are not implemented by go doc.
309 // When run with two arguments, the first must be a full package path (not just a
310 // suffix), and the second is a symbol, or symbol with method or struct field.
311 // This is similar to the syntax accepted by godoc:
313 // go doc <pkg> <sym>[.<methodOrField>]
315 // In all forms, when matching symbols, lower-case letters in the argument match
316 // either case but upper-case letters match exactly. This means that there may be
317 // multiple matches of a lower-case argument in a package if different symbols have
318 // different cases. If this occurs, documentation for all matches is printed.
322 // Show documentation for current package.
324 // Show documentation for Foo in the current package.
325 // (Foo starts with a capital letter so it cannot match
327 // go doc encoding/json
328 // Show documentation for the encoding/json package.
330 // Shorthand for encoding/json.
331 // go doc json.Number (or go doc json.number)
332 // Show documentation and method summary for json.Number.
333 // go doc json.Number.Int64 (or go doc json.number.int64)
334 // Show documentation for json.Number's Int64 method.
336 // Show package docs for the doc command.
337 // go doc -cmd cmd/doc
338 // Show package docs and exported symbols within the doc command.
339 // go doc template.new
340 // Show documentation for html/template's New function.
341 // (html/template is lexically before text/template)
342 // go doc text/template.new # One argument
343 // Show documentation for text/template's New function.
344 // go doc text/template new # Two arguments
345 // Show documentation for text/template's New function.
347 // At least in the current tree, these invocations all print the
348 // documentation for json.Decoder's Decode method:
350 // go doc json.Decoder.Decode
351 // go doc json.decoder.decode
352 // go doc json.decode
353 // cd go/src/encoding/json; go doc decode
357 // Show all the documentation for the package.
359 // Respect case when matching symbols.
361 // Treat a command (package main) like a regular package.
362 // Otherwise package main's exported symbols are hidden
363 // when showing the package's top-level documentation.
365 // Show the full source code for the symbol. This will
366 // display the full Go source of its declaration and
367 // definition, such as a function definition (including
368 // the body), type declaration or enclosing const
369 // block. The output may therefore include unexported
372 // Show documentation for unexported as well as exported
373 // symbols, methods, and fields.
376 // Print Go environment information
380 // go env [-json] [-u] [-w] [var ...]
382 // Env prints Go environment information.
384 // By default env prints information as a shell script
385 // (on Windows, a batch file). If one or more variable
386 // names is given as arguments, env prints the value of
387 // each named variable on its own line.
389 // The -json flag prints the environment in JSON format
390 // instead of as a shell script.
392 // The -u flag requires one or more arguments and unsets
393 // the default setting for the named environment variables,
394 // if one has been set with 'go env -w'.
396 // The -w flag requires one or more arguments of the
397 // form NAME=VALUE and changes the default settings
398 // of the named environment variables to the given values.
400 // For more about environment variables, see 'go help environment'.
403 // Update packages to use new APIs
409 // Fix runs the Go fix command on the packages named by the import paths.
411 // For more about fix, see 'go doc cmd/fix'.
412 // For more about specifying packages, see 'go help packages'.
414 // To run fix with specific options, run 'go tool fix'.
416 // See also: go fmt, go vet.
419 // Gofmt (reformat) package sources
423 // go fmt [-n] [-x] [packages]
425 // Fmt runs the command 'gofmt -l -w' on the packages named
426 // by the import paths. It prints the names of the files that are modified.
428 // For more about gofmt, see 'go doc cmd/gofmt'.
429 // For more about specifying packages, see 'go help packages'.
431 // The -n flag prints commands that would be executed.
432 // The -x flag prints commands as they are executed.
434 // To run gofmt with specific options, run gofmt itself.
436 // See also: go fix, go vet.
439 // Generate Go files by processing source
443 // go generate [-run regexp] [-n] [-v] [-x] [build flags] [file.go... | packages]
445 // Generate runs commands described by directives within existing
446 // files. Those commands can run any process but the intent is to
447 // create or update Go source files.
449 // Go generate is never run automatically by go build, go get, go test,
450 // and so on. It must be run explicitly.
452 // Go generate scans the file for directives, which are lines of
455 // //go:generate command argument...
457 // (note: no leading spaces and no space in "//go") where command
458 // is the generator to be run, corresponding to an executable file
459 // that can be run locally. It must either be in the shell path
460 // (gofmt), a fully qualified path (/usr/you/bin/mytool), or a
461 // command alias, described below.
463 // To convey to humans and machine tools that code is generated,
464 // generated source should have a line that matches the following
465 // regular expression (in Go syntax):
467 // ^// Code generated .* DO NOT EDIT\.$
469 // The line may appear anywhere in the file, but is typically
470 // placed near the beginning so it is easy to find.
472 // Note that go generate does not parse the file, so lines that look
473 // like directives in comments or multiline strings will be treated
476 // The arguments to the directive are space-separated tokens or
477 // double-quoted strings passed to the generator as individual
478 // arguments when it is run.
480 // Quoted strings use Go syntax and are evaluated before execution; a
481 // quoted string appears as a single argument to the generator.
483 // Go generate sets several variables when it runs the generator:
486 // The execution architecture (arm, amd64, etc.)
488 // The execution operating system (linux, windows, etc.)
490 // The base name of the file.
492 // The line number of the directive in the source file.
494 // The name of the package of the file containing the directive.
498 // Other than variable substitution and quoted-string evaluation, no
499 // special processing such as "globbing" is performed on the command
502 // As a last step before running the command, any invocations of any
503 // environment variables with alphanumeric names, such as $GOFILE or
504 // $HOME, are expanded throughout the command line. The syntax for
505 // variable expansion is $NAME on all operating systems. Due to the
506 // order of evaluation, variables are expanded even inside quoted
507 // strings. If the variable NAME is not set, $NAME expands to the
510 // A directive of the form,
512 // //go:generate -command xxx args...
514 // specifies, for the remainder of this source file only, that the
515 // string xxx represents the command identified by the arguments. This
516 // can be used to create aliases or to handle multiword generators.
519 // //go:generate -command foo go tool foo
521 // specifies that the command "foo" represents the generator
524 // Generate processes packages in the order given on the command line,
525 // one at a time. If the command line lists .go files from a single directory,
526 // they are treated as a single package. Within a package, generate processes the
527 // source files in a package in file name order, one at a time. Within
528 // a source file, generate runs generators in the order they appear
529 // in the file, one at a time. The go generate tool also sets the build
530 // tag "generate" so that files may be examined by go generate but ignored
533 // If any generator returns an error exit status, "go generate" skips
534 // all further processing for that package.
536 // The generator is run in the package's source directory.
538 // Go generate accepts one specific flag:
541 // if non-empty, specifies a regular expression to select
542 // directives whose full original source text (excluding
543 // any trailing spaces and final newline) matches the
546 // It also accepts the standard build flags including -v, -n, and -x.
547 // The -v flag prints the names of packages and files as they are
549 // The -n flag prints commands that would be executed.
550 // The -x flag prints commands as they are executed.
552 // For more about build flags, see 'go help build'.
554 // For more about specifying packages, see 'go help packages'.
557 // Add dependencies to current module and install them
561 // go get [-d] [-t] [-u] [-v] [-insecure] [build flags] [packages]
563 // Get resolves and adds dependencies to the current development module
564 // and then builds and installs them.
566 // The first step is to resolve which dependencies to add.
568 // For each named package or package pattern, get must decide which version of
569 // the corresponding module to use. By default, get looks up the latest tagged
570 // release version, such as v0.4.5 or v1.2.3. If there are no tagged release
571 // versions, get looks up the latest tagged pre-release version, such as
572 // v0.0.1-pre1. If there are no tagged versions at all, get looks up the latest
573 // known commit. If the module is not already required at a later version
574 // (for example, a pre-release newer than the latest release), get will use
575 // the version it looked up. Otherwise, get will use the currently
578 // This default version selection can be overridden by adding an @version
579 // suffix to the package argument, as in 'go get golang.org/x/text@v0.3.0'.
580 // The version may be a prefix: @v1 denotes the latest available version starting
581 // with v1. See 'go help modules' under the heading 'Module queries' for the
582 // full query syntax.
584 // For modules stored in source control repositories, the version suffix can
585 // also be a commit hash, branch identifier, or other syntax known to the
586 // source control system, as in 'go get golang.org/x/text@master'. Note that
587 // branches with names that overlap with other module query syntax cannot be
588 // selected explicitly. For example, the suffix @v2 means the latest version
589 // starting with v2, not the branch named v2.
591 // If a module under consideration is already a dependency of the current
592 // development module, then get will update the required version.
593 // Specifying a version earlier than the current required version is valid and
594 // downgrades the dependency. The version suffix @none indicates that the
595 // dependency should be removed entirely, downgrading or removing modules
596 // depending on it as needed.
598 // The version suffix @latest explicitly requests the latest minor release of the
599 // module named by the given path. The suffix @upgrade is like @latest but
600 // will not downgrade a module if it is already required at a revision or
601 // pre-release version newer than the latest released version. The suffix
602 // @patch requests the latest patch release: the latest released version
603 // with the same major and minor version numbers as the currently required
604 // version. Like @upgrade, @patch will not downgrade a module already required
605 // at a newer version. If the path is not already required, @upgrade and @patch
606 // are equivalent to @latest.
608 // Although get defaults to using the latest version of the module containing
609 // a named package, it does not use the latest version of that module's
610 // dependencies. Instead it prefers to use the specific dependency versions
611 // requested by that module. For example, if the latest A requires module
612 // B v1.2.3, while B v1.2.4 and v1.3.1 are also available, then 'go get A'
613 // will use the latest A but then use B v1.2.3, as requested by A. (If there
614 // are competing requirements for a particular module, then 'go get' resolves
615 // those requirements by taking the maximum requested version.)
617 // The -t flag instructs get to consider modules needed to build tests of
618 // packages specified on the command line.
620 // The -u flag instructs get to update modules providing dependencies
621 // of packages named on the command line to use newer minor or patch
622 // releases when available. Continuing the previous example, 'go get -u A'
623 // will use the latest A with B v1.3.1 (not B v1.2.3). If B requires module C,
624 // but C does not provide any packages needed to build packages in A
625 // (not including tests), then C will not be updated.
627 // The -u=patch flag (not -u patch) also instructs get to update dependencies,
628 // but changes the default to select patch releases.
629 // Continuing the previous example,
630 // 'go get -u=patch A@latest' will use the latest A with B v1.2.4 (not B v1.2.3),
631 // while 'go get -u=patch A' will use a patch release of A instead.
633 // When the -t and -u flags are used together, get will update
634 // test dependencies as well.
636 // In general, adding a new dependency may require upgrading
637 // existing dependencies to keep a working build, and 'go get' does
638 // this automatically. Similarly, downgrading one dependency may
639 // require downgrading other dependencies, and 'go get' does
640 // this automatically as well.
642 // The -insecure flag permits fetching from repositories and resolving
643 // custom domains using insecure schemes such as HTTP. Use with caution.
645 // The second step is to download (if needed), build, and install
646 // the named packages.
648 // If an argument names a module but not a package (because there is no
649 // Go source code in the module's root directory), then the install step
650 // is skipped for that argument, instead of causing a build failure.
651 // For example 'go get golang.org/x/perf' succeeds even though there
652 // is no code corresponding to that import path.
654 // Note that package patterns are allowed and are expanded after resolving
655 // the module versions. For example, 'go get golang.org/x/perf/cmd/...'
656 // adds the latest golang.org/x/perf and then installs the commands in that
659 // The -d flag instructs get to download the source code needed to build
660 // the named packages, including downloading necessary dependencies,
661 // but not to build and install them.
663 // With no package arguments, 'go get' applies to Go package in the
664 // current directory, if any. In particular, 'go get -u' and
665 // 'go get -u=patch' update all the dependencies of that package.
666 // With no package arguments and also without -u, 'go get' is not much more
667 // than 'go install', and 'go get -d' not much more than 'go list'.
669 // For more about modules, see 'go help modules'.
671 // For more about specifying packages, see 'go help packages'.
673 // This text describes the behavior of get using modules to manage source
674 // code and dependencies. If instead the go command is running in GOPATH
675 // mode, the details of get's flags and effects change, as does 'go help get'.
676 // See 'go help modules' and 'go help gopath-get'.
678 // See also: go build, go install, go clean, go mod.
681 // Compile and install packages and dependencies
685 // go install [-i] [build flags] [packages]
687 // Install compiles and installs the packages named by the import paths.
689 // Executables are installed in the directory named by the GOBIN environment
690 // variable, which defaults to $GOPATH/bin or $HOME/go/bin if the GOPATH
691 // environment variable is not set. Executables in $GOROOT
692 // are installed in $GOROOT/bin or $GOTOOLDIR instead of $GOBIN.
694 // When module-aware mode is disabled, other packages are installed in the
695 // directory $GOPATH/pkg/$GOOS_$GOARCH. When module-aware mode is enabled,
696 // other packages are built and cached but not installed.
698 // The -i flag installs the dependencies of the named packages as well.
700 // For more about the build flags, see 'go help build'.
701 // For more about specifying packages, see 'go help packages'.
703 // See also: go build, go get, go clean.
706 // List packages or modules
710 // go list [-f format] [-json] [-m] [list flags] [build flags] [packages]
712 // List lists the named packages, one per line.
713 // The most commonly-used flags are -f and -json, which control the form
714 // of the output printed for each package. Other list flags, documented below,
715 // control more specific details.
717 // The default output shows the package import path:
721 // github.com/gorilla/mux
722 // golang.org/x/net/html
724 // The -f flag specifies an alternate format for the list, using the
725 // syntax of package template. The default output is equivalent
726 // to -f '{{.ImportPath}}'. The struct being passed to the template is:
728 // type Package struct {
729 // Dir string // directory containing package sources
730 // ImportPath string // import path of package in dir
731 // ImportComment string // path in import comment on package statement
732 // Name string // package name
733 // Doc string // package documentation string
734 // Target string // install path
735 // Shlib string // the shared library that contains this package (only set when -linkshared)
736 // Goroot bool // is this package in the Go root?
737 // Standard bool // is this package part of the standard Go library?
738 // Stale bool // would 'go install' do anything for this package?
739 // StaleReason string // explanation for Stale==true
740 // Root string // Go root or Go path dir containing this package
741 // ConflictDir string // this directory shadows Dir in $GOPATH
742 // BinaryOnly bool // binary-only package (no longer supported)
743 // ForTest string // package is only for use in named test
744 // Export string // file containing export data (when using -export)
745 // Module *Module // info about package's containing module, if any (can be nil)
746 // Match []string // command-line patterns matching this package
747 // DepOnly bool // package is only a dependency, not explicitly listed
750 // GoFiles []string // .go source files (excluding CgoFiles, TestGoFiles, XTestGoFiles)
751 // CgoFiles []string // .go source files that import "C"
752 // CompiledGoFiles []string // .go files presented to compiler (when using -compiled)
753 // IgnoredGoFiles []string // .go source files ignored due to build constraints
754 // CFiles []string // .c source files
755 // CXXFiles []string // .cc, .cxx and .cpp source files
756 // MFiles []string // .m source files
757 // HFiles []string // .h, .hh, .hpp and .hxx source files
758 // FFiles []string // .f, .F, .for and .f90 Fortran source files
759 // SFiles []string // .s source files
760 // SwigFiles []string // .swig files
761 // SwigCXXFiles []string // .swigcxx files
762 // SysoFiles []string // .syso object files to add to archive
763 // TestGoFiles []string // _test.go files in package
764 // XTestGoFiles []string // _test.go files outside package
767 // CgoCFLAGS []string // cgo: flags for C compiler
768 // CgoCPPFLAGS []string // cgo: flags for C preprocessor
769 // CgoCXXFLAGS []string // cgo: flags for C++ compiler
770 // CgoFFLAGS []string // cgo: flags for Fortran compiler
771 // CgoLDFLAGS []string // cgo: flags for linker
772 // CgoPkgConfig []string // cgo: pkg-config names
774 // // Dependency information
775 // Imports []string // import paths used by this package
776 // ImportMap map[string]string // map from source import to ImportPath (identity entries omitted)
777 // Deps []string // all (recursively) imported dependencies
778 // TestImports []string // imports from TestGoFiles
779 // XTestImports []string // imports from XTestGoFiles
781 // // Error information
782 // Incomplete bool // this package or a dependency has an error
783 // Error *PackageError // error loading package
784 // DepsErrors []*PackageError // errors loading dependencies
787 // Packages stored in vendor directories report an ImportPath that includes the
788 // path to the vendor directory (for example, "d/vendor/p" instead of "p"),
789 // so that the ImportPath uniquely identifies a given copy of a package.
790 // The Imports, Deps, TestImports, and XTestImports lists also contain these
791 // expanded import paths. See golang.org/s/go15vendor for more about vendoring.
793 // The error information, if any, is
795 // type PackageError struct {
796 // ImportStack []string // shortest path from package named on command line to this one
797 // Pos string // position of error (if present, file:line:col)
798 // Err string // the error itself
801 // The module information is a Module struct, defined in the discussion
804 // The template function "join" calls strings.Join.
806 // The template function "context" returns the build context, defined as:
808 // type Context struct {
809 // GOARCH string // target architecture
810 // GOOS string // target operating system
811 // GOROOT string // Go root
812 // GOPATH string // Go path
813 // CgoEnabled bool // whether cgo can be used
814 // UseAllFiles bool // use files regardless of +build lines, file names
815 // Compiler string // compiler to assume when computing target paths
816 // BuildTags []string // build constraints to match in +build lines
817 // ReleaseTags []string // releases the current release is compatible with
818 // InstallSuffix string // suffix to use in the name of the install dir
821 // For more information about the meaning of these fields see the documentation
822 // for the go/build package's Context type.
824 // The -json flag causes the package data to be printed in JSON format
825 // instead of using the template format.
827 // The -compiled flag causes list to set CompiledGoFiles to the Go source
828 // files presented to the compiler. Typically this means that it repeats
829 // the files listed in GoFiles and then also adds the Go code generated
830 // by processing CgoFiles and SwigFiles. The Imports list contains the
831 // union of all imports from both GoFiles and CompiledGoFiles.
833 // The -deps flag causes list to iterate over not just the named packages
834 // but also all their dependencies. It visits them in a depth-first post-order
835 // traversal, so that a package is listed only after all its dependencies.
836 // Packages not explicitly listed on the command line will have the DepOnly
837 // field set to true.
839 // The -e flag changes the handling of erroneous packages, those that
840 // cannot be found or are malformed. By default, the list command
841 // prints an error to standard error for each erroneous package and
842 // omits the packages from consideration during the usual printing.
843 // With the -e flag, the list command never prints errors to standard
844 // error and instead processes the erroneous packages with the usual
845 // printing. Erroneous packages will have a non-empty ImportPath and
846 // a non-nil Error field; other information may or may not be missing
849 // The -export flag causes list to set the Export field to the name of a
850 // file containing up-to-date export information for the given package.
852 // The -find flag causes list to identify the named packages but not
853 // resolve their dependencies: the Imports and Deps lists will be empty.
855 // The -test flag causes list to report not only the named packages
856 // but also their test binaries (for packages with tests), to convey to
857 // source code analysis tools exactly how test binaries are constructed.
858 // The reported import path for a test binary is the import path of
859 // the package followed by a ".test" suffix, as in "math/rand.test".
860 // When building a test, it is sometimes necessary to rebuild certain
861 // dependencies specially for that test (most commonly the tested
862 // package itself). The reported import path of a package recompiled
863 // for a particular test binary is followed by a space and the name of
864 // the test binary in brackets, as in "math/rand [math/rand.test]"
865 // or "regexp [sort.test]". The ForTest field is also set to the name
866 // of the package being tested ("math/rand" or "sort" in the previous
869 // The Dir, Target, Shlib, Root, ConflictDir, and Export file paths
870 // are all absolute paths.
872 // By default, the lists GoFiles, CgoFiles, and so on hold names of files in Dir
873 // (that is, paths relative to Dir, not absolute paths).
874 // The generated files added when using the -compiled and -test flags
875 // are absolute paths referring to cached copies of generated Go source files.
876 // Although they are Go source files, the paths may not end in ".go".
878 // The -m flag causes list to list modules instead of packages.
880 // When listing modules, the -f flag still specifies a format template
881 // applied to a Go struct, but now a Module struct:
883 // type Module struct {
884 // Path string // module path
885 // Version string // module version
886 // Versions []string // available module versions (with -versions)
887 // Replace *Module // replaced by this module
888 // Time *time.Time // time version was created
889 // Update *Module // available update, if any (with -u)
890 // Main bool // is this the main module?
891 // Indirect bool // is this module only an indirect dependency of main module?
892 // Dir string // directory holding files for this module, if any
893 // GoMod string // path to go.mod file for this module, if any
894 // GoVersion string // go version used in module
895 // Error *ModuleError // error loading module
898 // type ModuleError struct {
899 // Err string // the error itself
902 // The default output is to print the module path and then
903 // information about the version and replacement if any.
904 // For example, 'go list -m all' might print:
907 // golang.org/x/text v0.3.0 => /tmp/text
910 // The Module struct has a String method that formats this
911 // line of output, so that the default format is equivalent
912 // to -f '{{.String}}'.
914 // Note that when a module has been replaced, its Replace field
915 // describes the replacement module, and its Dir field is set to
916 // the replacement's source code, if present. (That is, if Replace
917 // is non-nil, then Dir is set to Replace.Dir, with no access to
918 // the replaced source code.)
920 // The -u flag adds information about available upgrades.
921 // When the latest version of a given module is newer than
922 // the current one, list -u sets the Module's Update field
923 // to information about the newer module.
924 // The Module's String method indicates an available upgrade by
925 // formatting the newer version in brackets after the current version.
926 // For example, 'go list -m -u all' might print:
929 // golang.org/x/text v0.3.0 [v0.4.0] => /tmp/text
930 // rsc.io/pdf v0.1.1 [v0.1.2]
932 // (For tools, 'go list -m -u -json all' may be more convenient to parse.)
934 // The -versions flag causes list to set the Module's Versions field
935 // to a list of all known versions of that module, ordered according
936 // to semantic versioning, earliest to latest. The flag also changes
937 // the default output format to display the module path followed by the
938 // space-separated version list.
940 // The arguments to list -m are interpreted as a list of modules, not packages.
941 // The main module is the module containing the current directory.
942 // The active modules are the main module and its dependencies.
943 // With no arguments, list -m shows the main module.
944 // With arguments, list -m shows the modules specified by the arguments.
945 // Any of the active modules can be specified by its module path.
946 // The special pattern "all" specifies all the active modules, first the main
947 // module and then dependencies sorted by module path.
948 // A pattern containing "..." specifies the active modules whose
949 // module paths match the pattern.
950 // A query of the form path@version specifies the result of that query,
951 // which is not limited to active modules.
952 // See 'go help modules' for more about module queries.
954 // The template function "module" takes a single string argument
955 // that must be a module path or query and returns the specified
956 // module as a Module struct. If an error occurs, the result will
957 // be a Module struct with a non-nil Error field.
959 // For more about build flags, see 'go help build'.
961 // For more about specifying packages, see 'go help packages'.
963 // For more about modules, see 'go help modules'.
966 // Module maintenance
968 // Go mod provides access to operations on modules.
970 // Note that support for modules is built into all the go commands,
971 // not just 'go mod'. For example, day-to-day adding, removing, upgrading,
972 // and downgrading of dependencies should be done using 'go get'.
973 // See 'go help modules' for an overview of module functionality.
977 // go mod <command> [arguments]
981 // download download modules to local cache
982 // edit edit go.mod from tools or scripts
983 // graph print module requirement graph
984 // init initialize new module in current directory
985 // tidy add missing and remove unused modules
986 // vendor make vendored copy of dependencies
987 // verify verify dependencies have expected content
988 // why explain why packages or modules are needed
990 // Use "go help mod <command>" for more information about a command.
992 // Download modules to local cache
996 // go mod download [-json] [modules]
998 // Download downloads the named modules, which can be module patterns selecting
999 // dependencies of the main module or module queries of the form path@version.
1000 // With no arguments, download applies to all dependencies of the main module.
1002 // The go command will automatically download modules as needed during ordinary
1003 // execution. The "go mod download" command is useful mainly for pre-filling
1004 // the local cache or to compute the answers for a Go module proxy.
1006 // By default, download reports errors to standard error but is otherwise silent.
1007 // The -json flag causes download to print a sequence of JSON objects
1008 // to standard output, describing each downloaded module (or failure),
1009 // corresponding to this Go struct:
1011 // type Module struct {
1012 // Path string // module path
1013 // Version string // module version
1014 // Error string // error loading module
1015 // Info string // absolute path to cached .info file
1016 // GoMod string // absolute path to cached .mod file
1017 // Zip string // absolute path to cached .zip file
1018 // Dir string // absolute path to cached source root directory
1019 // Sum string // checksum for path, version (as in go.sum)
1020 // GoModSum string // checksum for go.mod (as in go.sum)
1021 // Latest bool // would @latest resolve to this version?
1024 // See 'go help modules' for more about module queries.
1027 // Edit go.mod from tools or scripts
1031 // go mod edit [editing flags] [go.mod]
1033 // Edit provides a command-line interface for editing go.mod,
1034 // for use primarily by tools or scripts. It reads only go.mod;
1035 // it does not look up information about the modules involved.
1036 // By default, edit reads and writes the go.mod file of the main module,
1037 // but a different target file can be specified after the editing flags.
1039 // The editing flags specify a sequence of editing operations.
1041 // The -fmt flag reformats the go.mod file without making other changes.
1042 // This reformatting is also implied by any other modifications that use or
1043 // rewrite the go.mod file. The only time this flag is needed is if no other
1044 // flags are specified, as in 'go mod edit -fmt'.
1046 // The -module flag changes the module's path (the go.mod file's module line).
1048 // The -require=path@version and -droprequire=path flags
1049 // add and drop a requirement on the given module path and version.
1050 // Note that -require overrides any existing requirements on path.
1051 // These flags are mainly for tools that understand the module graph.
1052 // Users should prefer 'go get path@version' or 'go get path@none',
1053 // which make other go.mod adjustments as needed to satisfy
1054 // constraints imposed by other modules.
1056 // The -exclude=path@version and -dropexclude=path@version flags
1057 // add and drop an exclusion for the given module path and version.
1058 // Note that -exclude=path@version is a no-op if that exclusion already exists.
1060 // The -replace=old[@v]=new[@v] and -dropreplace=old[@v] flags
1061 // add and drop a replacement of the given module path and version pair.
1062 // If the @v in old@v is omitted, the replacement applies to all versions
1063 // with the old module path. If the @v in new@v is omitted, the new path
1064 // should be a local module root directory, not a module path.
1065 // Note that -replace overrides any existing replacements for old[@v].
1067 // The -require, -droprequire, -exclude, -dropexclude, -replace,
1068 // and -dropreplace editing flags may be repeated, and the changes
1069 // are applied in the order given.
1071 // The -go=version flag sets the expected Go language version.
1073 // The -print flag prints the final go.mod in its text format instead of
1074 // writing it back to go.mod.
1076 // The -json flag prints the final go.mod file in JSON format instead of
1077 // writing it back to go.mod. The JSON output corresponds to these Go types:
1079 // type Module struct {
1084 // type GoMod struct {
1087 // Require []Require
1089 // Replace []Replace
1092 // type Require struct {
1098 // type Replace struct {
1103 // Note that this only describes the go.mod file itself, not other modules
1104 // referred to indirectly. For the full set of modules available to a build,
1105 // use 'go list -m -json all'.
1107 // For example, a tool can obtain the go.mod as a data structure by
1108 // parsing the output of 'go mod edit -json' and can then make changes
1109 // by invoking 'go mod edit' with -require, -exclude, and so on.
1112 // Print module requirement graph
1118 // Graph prints the module requirement graph (with replacements applied)
1119 // in text form. Each line in the output has two space-separated fields: a module
1120 // and one of its requirements. Each module is identified as a string of the form
1121 // path@version, except for the main module, which has no @version suffix.
1124 // Initialize new module in current directory
1128 // go mod init [module]
1130 // Init initializes and writes a new go.mod to the current directory,
1131 // in effect creating a new module rooted at the current directory.
1132 // The file go.mod must not already exist.
1133 // If possible, init will guess the module path from import comments
1134 // (see 'go help importpath') or from version control configuration.
1135 // To override this guess, supply the module path as an argument.
1138 // Add missing and remove unused modules
1144 // Tidy makes sure go.mod matches the source code in the module.
1145 // It adds any missing modules necessary to build the current module's
1146 // packages and dependencies, and it removes unused modules that
1147 // don't provide any relevant packages. It also adds any missing entries
1148 // to go.sum and removes any unnecessary ones.
1150 // The -v flag causes tidy to print information about removed modules
1151 // to standard error.
1154 // Make vendored copy of dependencies
1158 // go mod vendor [-v]
1160 // Vendor resets the main module's vendor directory to include all packages
1161 // needed to build and test all the main module's packages.
1162 // It does not include test code for vendored packages.
1164 // The -v flag causes vendor to print the names of vendored
1165 // modules and packages to standard error.
1168 // Verify dependencies have expected content
1174 // Verify checks that the dependencies of the current module,
1175 // which are stored in a local downloaded source cache, have not been
1176 // modified since being downloaded. If all the modules are unmodified,
1177 // verify prints "all modules verified." Otherwise it reports which
1178 // modules have been changed and causes 'go mod' to exit with a
1182 // Explain why packages or modules are needed
1186 // go mod why [-m] [-vendor] packages...
1188 // Why shows a shortest path in the import graph from the main module to
1189 // each of the listed packages. If the -m flag is given, why treats the
1190 // arguments as a list of modules and finds a path to any package in each
1193 // By default, why queries the graph of packages matched by "go list all",
1194 // which includes tests for reachable packages. The -vendor flag causes why
1195 // to exclude tests of dependencies.
1197 // The output is a sequence of stanzas, one for each package or module
1198 // name on the command line, separated by blank lines. Each stanza begins
1199 // with a comment line "# package" or "# module" giving the target
1200 // package or module. Subsequent lines give a path through the import
1201 // graph, one package per line. If the package or module is not
1202 // referenced from the main module, the stanza will display a single
1203 // parenthesized note indicating that fact.
1207 // $ go mod why golang.org/x/text/language golang.org/x/text/encoding
1208 // # golang.org/x/text/language
1211 // golang.org/x/text/language
1213 // # golang.org/x/text/encoding
1214 // (main module does not need package golang.org/x/text/encoding)
1218 // Compile and run Go program
1222 // go run [build flags] [-exec xprog] package [arguments...]
1224 // Run compiles and runs the named main Go package.
1225 // Typically the package is specified as a list of .go source files from a single directory,
1226 // but it may also be an import path, file system path, or pattern
1227 // matching a single known package, as in 'go run .' or 'go run my/cmd'.
1229 // By default, 'go run' runs the compiled binary directly: 'a.out arguments...'.
1230 // If the -exec flag is given, 'go run' invokes the binary using xprog:
1231 // 'xprog a.out arguments...'.
1232 // If the -exec flag is not given, GOOS or GOARCH is different from the system
1233 // default, and a program named go_$GOOS_$GOARCH_exec can be found
1234 // on the current search path, 'go run' invokes the binary using that program,
1235 // for example 'go_nacl_386_exec a.out arguments...'. This allows execution of
1236 // cross-compiled programs when a simulator or other execution method is
1239 // The exit status of Run is not the exit status of the compiled binary.
1241 // For more about build flags, see 'go help build'.
1242 // For more about specifying packages, see 'go help packages'.
1244 // See also: go build.
1251 // go test [build/test flags] [packages] [build/test flags & test binary flags]
1253 // 'Go test' automates testing the packages named by the import paths.
1254 // It prints a summary of the test results in the format:
1256 // ok archive/tar 0.011s
1257 // FAIL archive/zip 0.022s
1258 // ok compress/gzip 0.033s
1261 // followed by detailed output for each failed package.
1263 // 'Go test' recompiles each package along with any files with names matching
1264 // the file pattern "*_test.go".
1265 // These additional files can contain test functions, benchmark functions, and
1266 // example functions. See 'go help testfunc' for more.
1267 // Each listed package causes the execution of a separate test binary.
1268 // Files whose names begin with "_" (including "_test.go") or "." are ignored.
1270 // Test files that declare a package with the suffix "_test" will be compiled as a
1271 // separate package, and then linked and run with the main test binary.
1273 // The go tool will ignore a directory named "testdata", making it available
1274 // to hold ancillary data needed by the tests.
1276 // As part of building a test binary, go test runs go vet on the package
1277 // and its test source files to identify significant problems. If go vet
1278 // finds any problems, go test reports those and does not run the test
1279 // binary. Only a high-confidence subset of the default go vet checks are
1280 // used. That subset is: 'atomic', 'bool', 'buildtags', 'nilfunc', and
1281 // 'printf'. You can see the documentation for these and other vet tests
1282 // via "go doc cmd/vet". To disable the running of go vet, use the
1285 // All test output and summary lines are printed to the go command's
1286 // standard output, even if the test printed them to its own standard
1287 // error. (The go command's standard error is reserved for printing
1288 // errors building the tests.)
1290 // Go test runs in two different modes:
1292 // The first, called local directory mode, occurs when go test is
1293 // invoked with no package arguments (for example, 'go test' or 'go
1294 // test -v'). In this mode, go test compiles the package sources and
1295 // tests found in the current directory and then runs the resulting
1296 // test binary. In this mode, caching (discussed below) is disabled.
1297 // After the package test finishes, go test prints a summary line
1298 // showing the test status ('ok' or 'FAIL'), package name, and elapsed
1301 // The second, called package list mode, occurs when go test is invoked
1302 // with explicit package arguments (for example 'go test math', 'go
1303 // test ./...', and even 'go test .'). In this mode, go test compiles
1304 // and tests each of the packages listed on the command line. If a
1305 // package test passes, go test prints only the final 'ok' summary
1306 // line. If a package test fails, go test prints the full test output.
1307 // If invoked with the -bench or -v flag, go test prints the full
1308 // output even for passing package tests, in order to display the
1309 // requested benchmark results or verbose logging. After the package
1310 // tests for all of the listed packages finish, and their output is
1311 // printed, go test prints a final 'FAIL' status if any package test
1314 // In package list mode only, go test caches successful package test
1315 // results to avoid unnecessary repeated running of tests. When the
1316 // result of a test can be recovered from the cache, go test will
1317 // redisplay the previous output instead of running the test binary
1318 // again. When this happens, go test prints '(cached)' in place of the
1319 // elapsed time in the summary line.
1321 // The rule for a match in the cache is that the run involves the same
1322 // test binary and the flags on the command line come entirely from a
1323 // restricted set of 'cacheable' test flags, defined as -cpu, -list,
1324 // -parallel, -run, -short, and -v. If a run of go test has any test
1325 // or non-test flags outside this set, the result is not cached. To
1326 // disable test caching, use any test flag or argument other than the
1327 // cacheable flags. The idiomatic way to disable test caching explicitly
1328 // is to use -count=1. Tests that open files within the package's source
1329 // root (usually $GOPATH) or that consult environment variables only
1330 // match future runs in which the files and environment variables are unchanged.
1331 // A cached test result is treated as executing in no time at all,
1332 // so a successful package test result will be cached and reused
1333 // regardless of -timeout setting.
1335 // In addition to the build flags, the flags handled by 'go test' itself are:
1338 // Pass the remainder of the command line (everything after -args)
1339 // to the test binary, uninterpreted and unchanged.
1340 // Because this flag consumes the remainder of the command line,
1341 // the package list (if present) must appear before this flag.
1344 // Compile the test binary to pkg.test but do not run it
1345 // (where pkg is the last element of the package's import path).
1346 // The file name can be changed with the -o flag.
1349 // Run the test binary using xprog. The behavior is the same as
1350 // in 'go run'. See 'go help run' for details.
1353 // Install packages that are dependencies of the test.
1354 // Do not run the test.
1357 // Convert test output to JSON suitable for automated processing.
1358 // See 'go doc test2json' for the encoding details.
1361 // Compile the test binary to the named file.
1362 // The test still runs (unless -c or -i is specified).
1364 // The test binary also accepts flags that control execution of the test; these
1365 // flags are also accessible by 'go test'. See 'go help testflag' for details.
1367 // For more about build flags, see 'go help build'.
1368 // For more about specifying packages, see 'go help packages'.
1370 // See also: go build, go vet.
1373 // Run specified go tool
1377 // go tool [-n] command [args...]
1379 // Tool runs the go tool command identified by the arguments.
1380 // With no arguments it prints the list of known tools.
1382 // The -n flag causes tool to print the command that would be
1383 // executed but not execute it.
1385 // For more about each tool command, see 'go doc cmd/<command>'.
1392 // go version [-m] [-v] [file ...]
1394 // Version prints the build information for Go executables.
1396 // Go version reports the Go version used to build each of the named
1397 // executable files.
1399 // If no files are named on the command line, go version prints its own
1400 // version information.
1402 // If a directory is named, go version walks that directory, recursively,
1403 // looking for recognized Go binaries and reporting their versions.
1404 // By default, go version does not report unrecognized files found
1405 // during a directory scan. The -v flag causes it to report unrecognized files.
1407 // The -m flag causes go version to print each executable's embedded
1408 // module version information, when available. In the output, the module
1409 // information consists of multiple lines following the version line, each
1410 // indented by a leading tab character.
1412 // See also: go doc runtime/debug.BuildInfo.
1415 // Report likely mistakes in packages
1419 // go vet [-n] [-x] [-vettool prog] [build flags] [vet flags] [packages]
1421 // Vet runs the Go vet command on the packages named by the import paths.
1423 // For more about vet and its flags, see 'go doc cmd/vet'.
1424 // For more about specifying packages, see 'go help packages'.
1425 // For a list of checkers and their flags, see 'go tool vet help'.
1426 // For details of a specific checker such as 'printf', see 'go tool vet help printf'.
1428 // The -n flag prints commands that would be executed.
1429 // The -x flag prints commands as they are executed.
1431 // The -vettool=prog flag selects a different analysis tool with alternative
1432 // or additional checks.
1433 // For example, the 'shadow' analyzer can be built and run using these commands:
1435 // go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow
1436 // go vet -vettool=$(which shadow)
1438 // The build flags supported by go vet are those that control package resolution
1439 // and execution, such as -n, -x, -v, -tags, and -toolexec.
1440 // For more about these flags, see 'go help build'.
1442 // See also: go fmt, go fix.
1447 // The 'go build' and 'go install' commands take a -buildmode argument which
1448 // indicates which kind of object file is to be built. Currently supported values
1451 // -buildmode=archive
1452 // Build the listed non-main packages into .a files. Packages named
1453 // main are ignored.
1455 // -buildmode=c-archive
1456 // Build the listed main package, plus all packages it imports,
1457 // into a C archive file. The only callable symbols will be those
1458 // functions exported using a cgo //export comment. Requires
1459 // exactly one main package to be listed.
1461 // -buildmode=c-shared
1462 // Build the listed main package, plus all packages it imports,
1463 // into a C shared library. The only callable symbols will
1464 // be those functions exported using a cgo //export comment.
1465 // Requires exactly one main package to be listed.
1467 // -buildmode=default
1468 // Listed main packages are built into executables and listed
1469 // non-main packages are built into .a files (the default
1472 // -buildmode=shared
1473 // Combine all the listed non-main packages into a single shared
1474 // library that will be used when building with the -linkshared
1475 // option. Packages named main are ignored.
1478 // Build the listed main packages and everything they import into
1479 // executables. Packages not named main are ignored.
1482 // Build the listed main packages and everything they import into
1483 // position independent executables (PIE). Packages not named
1484 // main are ignored.
1486 // -buildmode=plugin
1487 // Build the listed main packages, plus all packages that they
1488 // import, into a Go plugin. Packages not named main are ignored.
1490 // On AIX, when linking a C program that uses a Go archive built with
1491 // -buildmode=c-archive, you must pass -Wl,-bnoobjreorder to the C compiler.
1494 // Calling between Go and C
1496 // There are two different ways to call between Go and C/C++ code.
1498 // The first is the cgo tool, which is part of the Go distribution. For
1499 // information on how to use it see the cgo documentation (go doc cmd/cgo).
1501 // The second is the SWIG program, which is a general tool for
1502 // interfacing between languages. For information on SWIG see
1503 // http://swig.org/. When running go build, any file with a .swig
1504 // extension will be passed to SWIG. Any file with a .swigcxx extension
1505 // will be passed to SWIG with the -c++ option.
1507 // When either cgo or SWIG is used, go build will pass any .c, .m, .s,
1508 // or .S files to the C compiler, and any .cc, .cpp, .cxx files to the C++
1509 // compiler. The CC or CXX environment variables may be set to determine
1510 // the C or C++ compiler, respectively, to use.
1513 // Build and test caching
1515 // The go command caches build outputs for reuse in future builds.
1516 // The default location for cache data is a subdirectory named go-build
1517 // in the standard user cache directory for the current operating system.
1518 // Setting the GOCACHE environment variable overrides this default,
1519 // and running 'go env GOCACHE' prints the current cache directory.
1521 // The go command periodically deletes cached data that has not been
1522 // used recently. Running 'go clean -cache' deletes all cached data.
1524 // The build cache correctly accounts for changes to Go source files,
1525 // compilers, compiler options, and so on: cleaning the cache explicitly
1526 // should not be necessary in typical use. However, the build cache
1527 // does not detect changes to C libraries imported with cgo.
1528 // If you have made changes to the C libraries on your system, you
1529 // will need to clean the cache explicitly or else use the -a build flag
1530 // (see 'go help build') to force rebuilding of packages that
1531 // depend on the updated C libraries.
1533 // The go command also caches successful package test results.
1534 // See 'go help test' for details. Running 'go clean -testcache' removes
1535 // all cached test results (but not cached build results).
1537 // The GODEBUG environment variable can enable printing of debugging
1538 // information about the state of the cache:
1540 // GODEBUG=gocacheverify=1 causes the go command to bypass the
1541 // use of any cache entries and instead rebuild everything and check
1542 // that the results match existing cache entries.
1544 // GODEBUG=gocachehash=1 causes the go command to print the inputs
1545 // for all of the content hashes it uses to construct cache lookup keys.
1546 // The output is voluminous but can be useful for debugging the cache.
1548 // GODEBUG=gocachetest=1 causes the go command to print details of its
1549 // decisions about whether to reuse a cached test result.
1552 // Environment variables
1554 // The go command and the tools it invokes consult environment variables
1555 // for configuration. If an environment variable is unset, the go command
1556 // uses a sensible default setting. To see the effective setting of the
1557 // variable <NAME>, run 'go env <NAME>'. To change the default setting,
1558 // run 'go env -w <NAME>=<VALUE>'. Defaults changed using 'go env -w'
1559 // are recorded in a Go environment configuration file stored in the
1560 // per-user configuration directory, as reported by os.UserConfigDir.
1561 // The location of the configuration file can be changed by setting
1562 // the environment variable GOENV, and 'go env GOENV' prints the
1563 // effective location, but 'go env -w' cannot change the default location.
1564 // See 'go help env' for details.
1566 // General-purpose environment variables:
1569 // The gccgo command to run for 'go build -compiler=gccgo'.
1571 // The architecture, or processor, for which to compile code.
1572 // Examples are amd64, 386, arm, ppc64.
1574 // The directory where 'go install' will install a command.
1576 // The directory where the go command will store cached
1577 // information for reuse in future builds.
1579 // Enable various debugging facilities. See 'go doc runtime'
1582 // The location of the Go environment configuration file.
1583 // Cannot be set using 'go env -w'.
1585 // A space-separated list of -flag=value settings to apply
1586 // to go commands by default, when the given flag is known by
1587 // the current command. Each entry must be a standalone flag.
1588 // Because the entries are space-separated, flag values must
1589 // not contain spaces. Flags listed on the command line
1590 // are applied after this list and therefore override it.
1592 // The operating system for which to compile code.
1593 // Examples are linux, darwin, windows, netbsd.
1595 // For more details see: 'go help gopath'.
1597 // URL of Go module proxy. See 'go help modules'.
1598 // GOPRIVATE, GONOPROXY, GONOSUMDB
1599 // Comma-separated list of glob patterns (in the syntax of Go's path.Match)
1600 // of module path prefixes that should always be fetched directly
1601 // or that should not be compared against the checksum database.
1602 // See 'go help module-private'.
1604 // The root of the go tree.
1606 // The name of checksum database to use and optionally its public key and
1607 // URL. See 'go help module-auth'.
1609 // The directory where the go command will write
1610 // temporary source files, packages, and binaries.
1612 // Environment variables for use with cgo:
1615 // The command to use to manipulate library archives when
1616 // building with the gccgo compiler.
1617 // The default is 'ar'.
1619 // The command to use to compile C code.
1621 // Whether the cgo command is supported. Either 0 or 1.
1623 // Flags that cgo will pass to the compiler when compiling
1626 // A regular expression specifying additional flags to allow
1627 // to appear in #cgo CFLAGS source code directives.
1628 // Does not apply to the CGO_CFLAGS environment variable.
1629 // CGO_CFLAGS_DISALLOW
1630 // A regular expression specifying flags that must be disallowed
1631 // from appearing in #cgo CFLAGS source code directives.
1632 // Does not apply to the CGO_CFLAGS environment variable.
1633 // CGO_CPPFLAGS, CGO_CPPFLAGS_ALLOW, CGO_CPPFLAGS_DISALLOW
1634 // Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW,
1635 // but for the C preprocessor.
1636 // CGO_CXXFLAGS, CGO_CXXFLAGS_ALLOW, CGO_CXXFLAGS_DISALLOW
1637 // Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW,
1638 // but for the C++ compiler.
1639 // CGO_FFLAGS, CGO_FFLAGS_ALLOW, CGO_FFLAGS_DISALLOW
1640 // Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW,
1641 // but for the Fortran compiler.
1642 // CGO_LDFLAGS, CGO_LDFLAGS_ALLOW, CGO_LDFLAGS_DISALLOW
1643 // Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW,
1644 // but for the linker.
1646 // The command to use to compile C++ code.
1648 // The command to use to compile Fortran code.
1650 // Path to pkg-config tool.
1652 // Architecture-specific environment variables:
1655 // For GOARCH=arm, the ARM architecture for which to compile.
1656 // Valid values are 5, 6, 7.
1658 // For GOARCH=386, the floating point instruction set.
1659 // Valid values are 387, sse2.
1661 // For GOARCH=mips{,le}, whether to use floating point instructions.
1662 // Valid values are hardfloat (default), softfloat.
1664 // For GOARCH=mips64{,le}, whether to use floating point instructions.
1665 // Valid values are hardfloat (default), softfloat.
1667 // For GOARCH=wasm, comma-separated list of experimental WebAssembly features to use.
1668 // Valid values are satconv, signext.
1670 // Special-purpose environment variables:
1673 // If set, where to find gccgo tools, such as cgo.
1674 // The default is based on how gccgo was configured.
1676 // The root of the installed Go tree, when it is
1677 // installed in a location other than where it is built.
1678 // File names in stack traces are rewritten from GOROOT to
1680 // GO_EXTLINK_ENABLED
1681 // Whether the linker should use external linking mode
1682 // when using -linkmode=auto with code that uses cgo.
1683 // Set to 0 to disable external linking mode, 1 to enable it.
1684 // GIT_ALLOW_PROTOCOL
1685 // Defined by Git. A colon-separated list of schemes that are allowed
1686 // to be used with git fetch/clone. If set, any scheme not explicitly
1687 // mentioned will be considered insecure by 'go get'.
1688 // Because the variable is defined by Git, the default value cannot
1689 // be set using 'go env -w'.
1691 // Additional information available from 'go env' but not read from the environment:
1694 // The executable file name suffix (".exe" on Windows, "" on other systems).
1696 // A space-separated list of arguments supplied to the CC command.
1698 // The architecture (GOARCH) of the Go toolchain binaries.
1700 // The operating system (GOOS) of the Go toolchain binaries.
1702 // The absolute path to the go.mod of the main module,
1703 // or the empty string if not using modules.
1705 // The directory where the go tools (compile, cover, doc, etc...) are installed.
1710 // The go command examines the contents of a restricted set of files
1711 // in each directory. It identifies which files to examine based on
1712 // the extension of the file name. These extensions are:
1718 // If the package uses cgo or SWIG, these will be compiled with the
1719 // OS-native compiler (typically gcc); otherwise they will
1720 // trigger an error.
1721 // .cc, .cpp, .cxx, .hh, .hpp, .hxx
1722 // C++ source files. Only useful with cgo or SWIG, and always
1723 // compiled with the OS-native compiler.
1725 // Objective-C source files. Only useful with cgo, and always
1726 // compiled with the OS-native compiler.
1728 // Assembler source files.
1729 // If the package uses cgo or SWIG, these will be assembled with the
1730 // OS-native assembler (typically gcc (sic)); otherwise they
1731 // will be assembled with the Go assembler.
1733 // SWIG definition files.
1735 // System object files.
1737 // Files of each of these types except .syso may contain build
1738 // constraints, but the go command stops scanning for build constraints
1739 // at the first item in the file that is not a blank line or //-style
1740 // line comment. See the go/build package documentation for
1746 // A module version is defined by a tree of source files, with a go.mod
1747 // file in its root. When the go command is run, it looks in the current
1748 // directory and then successive parent directories to find the go.mod
1749 // marking the root of the main (current) module.
1751 // The go.mod file itself is line-oriented, with // comments but
1752 // no /* */ comments. Each line holds a single directive, made up of a
1753 // verb followed by arguments. For example:
1757 // require other/thing v1.0.2
1758 // require new/thing/v2 v2.3.4
1759 // exclude old/thing v1.2.3
1760 // replace bad/thing v1.4.5 => good/thing v1.4.5
1763 // module, to define the module path;
1764 // go, to set the expected language version;
1765 // require, to require a particular module at a given version or later;
1766 // exclude, to exclude a particular module version from use; and
1767 // replace, to replace a module version with a different module version.
1768 // Exclude and replace apply only in the main module's go.mod and are ignored
1769 // in dependencies. See https://research.swtch.com/vgo-mvs for details.
1771 // The leading verb can be factored out of adjacent lines to create a block,
1772 // like in Go imports:
1779 // The go.mod file is designed both to be edited directly and to be
1780 // easily updated by tools. The 'go mod edit' command can be used to
1781 // parse and edit the go.mod file from programs and tools.
1782 // See 'go help mod edit'.
1784 // The go command automatically updates go.mod each time it uses the
1785 // module graph, to make sure go.mod always accurately reflects reality
1786 // and is properly formatted. For example, consider this go.mod file:
1800 // The update rewrites non-canonical version identifiers to semver form,
1801 // so A's v1 becomes v1.0.0 and E's dev becomes the pseudo-version for the
1802 // latest commit on the dev branch, perhaps v0.0.0-20180523231146-b3f5c0f6e5f1.
1804 // The update modifies requirements to respect exclusions, so the
1805 // requirement on the excluded D v1.2.3 is updated to use the next
1806 // available version of D, perhaps D v1.2.4 or D v1.3.0.
1808 // The update removes redundant or misleading requirements.
1809 // For example, if A v1.0.0 itself requires B v1.2.0 and C v1.0.0,
1810 // then go.mod's requirement of B v1.0.0 is misleading (superseded by
1811 // A's need for v1.2.0), and its requirement of C v1.0.0 is redundant
1812 // (implied by A's need for the same version), so both will be removed.
1813 // If module M contains packages that directly import packages from B or
1814 // C, then the requirements will be kept but updated to the actual
1815 // versions being used.
1817 // Finally, the update reformats the go.mod in a canonical formatting, so
1818 // that future mechanical changes will result in minimal diffs.
1820 // Because the module graph defines the meaning of import statements, any
1821 // commands that load packages also use and therefore update go.mod,
1822 // including go build, go get, go install, go list, go test, go mod graph,
1823 // go mod tidy, and go mod why.
1825 // The expected language version, set by the go directive, determines
1826 // which language features are available when compiling the module.
1827 // Language features available in that version will be available for use.
1828 // Language features removed in earlier versions, or added in later versions,
1829 // will not be available. Note that the language version does not affect
1830 // build tags, which are determined by the Go release being used.
1833 // GOPATH environment variable
1835 // The Go path is used to resolve import statements.
1836 // It is implemented by and documented in the go/build package.
1838 // The GOPATH environment variable lists places to look for Go code.
1839 // On Unix, the value is a colon-separated string.
1840 // On Windows, the value is a semicolon-separated string.
1841 // On Plan 9, the value is a list.
1843 // If the environment variable is unset, GOPATH defaults
1844 // to a subdirectory named "go" in the user's home directory
1845 // ($HOME/go on Unix, %USERPROFILE%\go on Windows),
1846 // unless that directory holds a Go distribution.
1847 // Run "go env GOPATH" to see the current GOPATH.
1849 // See https://golang.org/wiki/SettingGOPATH to set a custom GOPATH.
1851 // Each directory listed in GOPATH must have a prescribed structure:
1853 // The src directory holds source code. The path below src
1854 // determines the import path or executable name.
1856 // The pkg directory holds installed package objects.
1857 // As in the Go tree, each target operating system and
1858 // architecture pair has its own subdirectory of pkg
1859 // (pkg/GOOS_GOARCH).
1861 // If DIR is a directory listed in the GOPATH, a package with
1862 // source in DIR/src/foo/bar can be imported as "foo/bar" and
1863 // has its compiled form installed to "DIR/pkg/GOOS_GOARCH/foo/bar.a".
1865 // The bin directory holds compiled commands.
1866 // Each command is named for its source directory, but only
1867 // the final element, not the entire path. That is, the
1868 // command with source in DIR/src/foo/quux is installed into
1869 // DIR/bin/quux, not DIR/bin/foo/quux. The "foo/" prefix is stripped
1870 // so that you can add DIR/bin to your PATH to get at the
1871 // installed commands. If the GOBIN environment variable is
1872 // set, commands are installed to the directory it names instead
1873 // of DIR/bin. GOBIN must be an absolute path.
1875 // Here's an example directory layout:
1877 // GOPATH=/home/user/go
1882 // bar/ (go code in package bar)
1884 // quux/ (go code in package main)
1887 // quux (installed command)
1891 // bar.a (installed package object)
1893 // Go searches each directory listed in GOPATH to find source code,
1894 // but new packages are always downloaded into the first directory
1897 // See https://golang.org/doc/code.html for an example.
1899 // GOPATH and Modules
1901 // When using modules, GOPATH is no longer used for resolving imports.
1902 // However, it is still used to store downloaded source code (in GOPATH/pkg/mod)
1903 // and compiled commands (in GOPATH/bin).
1905 // Internal Directories
1907 // Code in or below a directory named "internal" is importable only
1908 // by code in the directory tree rooted at the parent of "internal".
1909 // Here's an extended version of the directory layout above:
1914 // bang/ (go code in package bang)
1916 // foo/ (go code in package foo)
1918 // bar/ (go code in package bar)
1921 // baz/ (go code in package baz)
1923 // quux/ (go code in package main)
1927 // The code in z.go is imported as "foo/internal/baz", but that
1928 // import statement can only appear in source files in the subtree
1929 // rooted at foo. The source files foo/f.go, foo/bar/x.go, and
1930 // foo/quux/y.go can all import "foo/internal/baz", but the source file
1931 // crash/bang/b.go cannot.
1933 // See https://golang.org/s/go14internal for details.
1935 // Vendor Directories
1937 // Go 1.6 includes support for using local copies of external dependencies
1938 // to satisfy imports of those dependencies, often referred to as vendoring.
1940 // Code below a directory named "vendor" is importable only
1941 // by code in the directory tree rooted at the parent of "vendor",
1942 // and only using an import path that omits the prefix up to and
1943 // including the vendor element.
1945 // Here's the example from the previous section,
1946 // but with the "internal" directory renamed to "vendor"
1947 // and a new foo/vendor/crash/bang directory added:
1952 // bang/ (go code in package bang)
1954 // foo/ (go code in package foo)
1956 // bar/ (go code in package bar)
1960 // bang/ (go code in package bang)
1962 // baz/ (go code in package baz)
1964 // quux/ (go code in package main)
1967 // The same visibility rules apply as for internal, but the code
1968 // in z.go is imported as "baz", not as "foo/vendor/baz".
1970 // Code in vendor directories deeper in the source tree shadows
1971 // code in higher directories. Within the subtree rooted at foo, an import
1972 // of "crash/bang" resolves to "foo/vendor/crash/bang", not the
1973 // top-level "crash/bang".
1975 // Code in vendor directories is not subject to import path
1976 // checking (see 'go help importpath').
1978 // When 'go get' checks out or updates a git repository, it now also
1979 // updates submodules.
1981 // Vendor directories do not affect the placement of new repositories
1982 // being checked out for the first time by 'go get': those are always
1983 // placed in the main GOPATH, never in a vendor subtree.
1985 // See https://golang.org/s/go15vendor for details.
1988 // Legacy GOPATH go get
1990 // The 'go get' command changes behavior depending on whether the
1991 // go command is running in module-aware mode or legacy GOPATH mode.
1992 // This help text, accessible as 'go help gopath-get' even in module-aware mode,
1993 // describes 'go get' as it operates in legacy GOPATH mode.
1995 // Usage: go get [-d] [-f] [-t] [-u] [-v] [-fix] [-insecure] [build flags] [packages]
1997 // Get downloads the packages named by the import paths, along with their
1998 // dependencies. It then installs the named packages, like 'go install'.
2000 // The -d flag instructs get to stop after downloading the packages; that is,
2001 // it instructs get not to install the packages.
2003 // The -f flag, valid only when -u is set, forces get -u not to verify that
2004 // each package has been checked out from the source control repository
2005 // implied by its import path. This can be useful if the source is a local fork
2008 // The -fix flag instructs get to run the fix tool on the downloaded packages
2009 // before resolving dependencies or building the code.
2011 // The -insecure flag permits fetching from repositories and resolving
2012 // custom domains using insecure schemes such as HTTP. Use with caution.
2014 // The -t flag instructs get to also download the packages required to build
2015 // the tests for the specified packages.
2017 // The -u flag instructs get to use the network to update the named packages
2018 // and their dependencies. By default, get uses the network to check out
2019 // missing packages but does not use it to look for updates to existing packages.
2021 // The -v flag enables verbose progress and debug output.
2023 // Get also accepts build flags to control the installation. See 'go help build'.
2025 // When checking out a new package, get creates the target directory
2026 // GOPATH/src/<import-path>. If the GOPATH contains multiple entries,
2027 // get uses the first one. For more details see: 'go help gopath'.
2029 // When checking out or updating a package, get looks for a branch or tag
2030 // that matches the locally installed version of Go. The most important
2031 // rule is that if the local installation is running version "go1", get
2032 // searches for a branch or tag named "go1". If no such version exists
2033 // it retrieves the default branch of the package.
2035 // When go get checks out or updates a Git repository,
2036 // it also updates any git submodules referenced by the repository.
2038 // Get never checks out or updates code stored in vendor directories.
2040 // For more about specifying packages, see 'go help packages'.
2042 // For more about how 'go get' finds source code to
2043 // download, see 'go help importpath'.
2045 // This text describes the behavior of get when using GOPATH
2046 // to manage source code and dependencies.
2047 // If instead the go command is running in module-aware mode,
2048 // the details of get's flags and effects change, as does 'go help get'.
2049 // See 'go help modules' and 'go help module-get'.
2051 // See also: go build, go install, go clean.
2054 // Module proxy protocol
2056 // A Go module proxy is any web server that can respond to GET requests for
2057 // URLs of a specified form. The requests have no query parameters, so even
2058 // a site serving from a fixed file system (including a file:/// URL)
2059 // can be a module proxy.
2061 // The GET requests sent to a Go module proxy are:
2063 // GET $GOPROXY/<module>/@v/list returns a list of all known versions of the
2064 // given module, one per line.
2066 // GET $GOPROXY/<module>/@v/<version>.info returns JSON-formatted metadata
2067 // about that version of the given module.
2069 // GET $GOPROXY/<module>/@v/<version>.mod returns the go.mod file
2070 // for that version of the given module.
2072 // GET $GOPROXY/<module>/@v/<version>.zip returns the zip archive
2073 // for that version of the given module.
2075 // To avoid problems when serving from case-sensitive file systems,
2076 // the <module> and <version> elements are case-encoded, replacing every
2077 // uppercase letter with an exclamation mark followed by the corresponding
2078 // lower-case letter: github.com/Azure encodes as github.com/!azure.
2080 // The JSON-formatted metadata about a given module corresponds to
2081 // this Go data structure, which may be expanded in the future:
2083 // type Info struct {
2084 // Version string // version string
2085 // Time time.Time // commit time
2088 // The zip archive for a specific version of a given module is a
2089 // standard zip file that contains the file tree corresponding
2090 // to the module's source code and related files. The archive uses
2091 // slash-separated paths, and every file path in the archive must
2092 // begin with <module>@<version>/, where the module and version are
2093 // substituted directly, not case-encoded. The root of the module
2094 // file tree corresponds to the <module>@<version>/ prefix in the
2097 // Even when downloading directly from version control systems,
2098 // the go command synthesizes explicit info, mod, and zip files
2099 // and stores them in its local cache, $GOPATH/pkg/mod/cache/download,
2100 // the same as if it had downloaded them directly from a proxy.
2101 // The cache layout is the same as the proxy URL space, so
2102 // serving $GOPATH/pkg/mod/cache/download at (or copying it to)
2103 // https://example.com/proxy would let other users access those
2104 // cached module versions with GOPROXY=https://example.com/proxy.
2107 // Import path syntax
2109 // An import path (see 'go help packages') denotes a package stored in the local
2110 // file system. In general, an import path denotes either a standard package (such
2111 // as "unicode/utf8") or a package found in one of the work spaces (For more
2112 // details see: 'go help gopath').
2114 // Relative import paths
2116 // An import path beginning with ./ or ../ is called a relative path.
2117 // The toolchain supports relative import paths as a shortcut in two ways.
2119 // First, a relative path can be used as a shorthand on the command line.
2120 // If you are working in the directory containing the code imported as
2121 // "unicode" and want to run the tests for "unicode/utf8", you can type
2122 // "go test ./utf8" instead of needing to specify the full path.
2123 // Similarly, in the reverse situation, "go test .." will test "unicode" from
2124 // the "unicode/utf8" directory. Relative patterns are also allowed, like
2125 // "go test ./..." to test all subdirectories. See 'go help packages' for details
2126 // on the pattern syntax.
2128 // Second, if you are compiling a Go program not in a work space,
2129 // you can use a relative path in an import statement in that program
2130 // to refer to nearby code also not in a work space.
2131 // This makes it easy to experiment with small multipackage programs
2132 // outside of the usual work spaces, but such programs cannot be
2133 // installed with "go install" (there is no work space in which to install them),
2134 // so they are rebuilt from scratch each time they are built.
2135 // To avoid ambiguity, Go programs cannot use relative import paths
2136 // within a work space.
2138 // Remote import paths
2140 // Certain import paths also
2141 // describe how to obtain the source code for the package using
2142 // a revision control system.
2144 // A few common code hosting sites have special syntax:
2146 // Bitbucket (Git, Mercurial)
2148 // import "bitbucket.org/user/project"
2149 // import "bitbucket.org/user/project/sub/directory"
2153 // import "github.com/user/project"
2154 // import "github.com/user/project/sub/directory"
2156 // Launchpad (Bazaar)
2158 // import "launchpad.net/project"
2159 // import "launchpad.net/project/series"
2160 // import "launchpad.net/project/series/sub/directory"
2162 // import "launchpad.net/~user/project/branch"
2163 // import "launchpad.net/~user/project/branch/sub/directory"
2165 // IBM DevOps Services (Git)
2167 // import "hub.jazz.net/git/user/project"
2168 // import "hub.jazz.net/git/user/project/sub/directory"
2170 // For code hosted on other servers, import paths may either be qualified
2171 // with the version control type, or the go tool can dynamically fetch
2172 // the import path over https/http and discover where the code resides
2173 // from a <meta> tag in the HTML.
2175 // To declare the code location, an import path of the form
2177 // repository.vcs/path
2179 // specifies the given repository, with or without the .vcs suffix,
2180 // using the named version control system, and then the path inside
2181 // that repository. The supported version control systems are:
2191 // import "example.org/user/foo.hg"
2193 // denotes the root directory of the Mercurial repository at
2194 // example.org/user/foo or foo.hg, and
2196 // import "example.org/repo.git/foo/bar"
2198 // denotes the foo/bar directory of the Git repository at
2199 // example.org/repo or repo.git.
2201 // When a version control system supports multiple protocols,
2202 // each is tried in turn when downloading. For example, a Git
2203 // download tries https://, then git+ssh://.
2205 // By default, downloads are restricted to known secure protocols
2206 // (e.g. https, ssh). To override this setting for Git downloads, the
2207 // GIT_ALLOW_PROTOCOL environment variable can be set (For more details see:
2208 // 'go help environment').
2210 // If the import path is not a known code hosting site and also lacks a
2211 // version control qualifier, the go tool attempts to fetch the import
2212 // over https/http and looks for a <meta> tag in the document's HTML
2215 // The meta tag has the form:
2217 // <meta name="go-import" content="import-prefix vcs repo-root">
2219 // The import-prefix is the import path corresponding to the repository
2220 // root. It must be a prefix or an exact match of the package being
2221 // fetched with "go get". If it's not an exact match, another http
2222 // request is made at the prefix to verify the <meta> tags match.
2224 // The meta tag should appear as early in the file as possible.
2225 // In particular, it should appear before any raw JavaScript or CSS,
2226 // to avoid confusing the go command's restricted parser.
2228 // The vcs is one of "bzr", "fossil", "git", "hg", "svn".
2230 // The repo-root is the root of the version control system
2231 // containing a scheme and not containing a .vcs qualifier.
2235 // import "example.org/pkg/foo"
2237 // will result in the following requests:
2239 // https://example.org/pkg/foo?go-get=1 (preferred)
2240 // http://example.org/pkg/foo?go-get=1 (fallback, only with -insecure)
2242 // If that page contains the meta tag
2244 // <meta name="go-import" content="example.org git https://code.org/r/p/exproj">
2246 // the go tool will verify that https://example.org/?go-get=1 contains the
2247 // same meta tag and then git clone https://code.org/r/p/exproj into
2248 // GOPATH/src/example.org.
2250 // When using GOPATH, downloaded packages are written to the first directory
2251 // listed in the GOPATH environment variable.
2252 // (See 'go help gopath-get' and 'go help gopath'.)
2254 // When using modules, downloaded packages are stored in the module cache.
2255 // (See 'go help module-get' and 'go help goproxy'.)
2257 // When using modules, an additional variant of the go-import meta tag is
2258 // recognized and is preferred over those listing version control systems.
2259 // That variant uses "mod" as the vcs in the content value, as in:
2261 // <meta name="go-import" content="example.org mod https://code.org/moduleproxy">
2263 // This tag means to fetch modules with paths beginning with example.org
2264 // from the module proxy available at the URL https://code.org/moduleproxy.
2265 // See 'go help goproxy' for details about the proxy protocol.
2267 // Import path checking
2269 // When the custom import path feature described above redirects to a
2270 // known code hosting site, each of the resulting packages has two possible
2271 // import paths, using the custom domain or the known hosting site.
2273 // A package statement is said to have an "import comment" if it is immediately
2274 // followed (before the next newline) by a comment of one of these two forms:
2276 // package math // import "path"
2277 // package math /* import "path" */
2279 // The go command will refuse to install a package with an import comment
2280 // unless it is being referred to by that import path. In this way, import comments
2281 // let package authors make sure the custom import path is used and not a
2282 // direct path to the underlying code hosting site.
2284 // Import path checking is disabled for code found within vendor trees.
2285 // This makes it possible to copy code into alternate locations in vendor trees
2286 // without needing to update import comments.
2288 // Import path checking is also disabled when using modules.
2289 // Import path comments are obsoleted by the go.mod file's module statement.
2291 // See https://golang.org/s/go14customimport for details.
2294 // Modules, module versions, and more
2296 // A module is a collection of related Go packages.
2297 // Modules are the unit of source code interchange and versioning.
2298 // The go command has direct support for working with modules,
2299 // including recording and resolving dependencies on other modules.
2300 // Modules replace the old GOPATH-based approach to specifying
2301 // which source files are used in a given build.
2305 // Go 1.13 includes support for Go modules. Module-aware mode is active by default
2306 // whenever a go.mod file is found in, or in a parent of, the current directory.
2308 // The quickest way to take advantage of module support is to check out your
2309 // repository, create a go.mod file (described in the next section) there, and run
2310 // go commands from within that file tree.
2312 // For more fine-grained control, Go 1.13 continues to respect
2313 // a temporary environment variable, GO111MODULE, which can be set to one
2314 // of three string values: off, on, or auto (the default).
2315 // If GO111MODULE=on, then the go command requires the use of modules,
2316 // never consulting GOPATH. We refer to this as the command
2317 // being module-aware or running in "module-aware mode".
2318 // If GO111MODULE=off, then the go command never uses
2319 // module support. Instead it looks in vendor directories and GOPATH
2320 // to find dependencies; we now refer to this as "GOPATH mode."
2321 // If GO111MODULE=auto or is unset, then the go command enables or disables
2322 // module support based on the current directory.
2323 // Module support is enabled only when the current directory contains a
2324 // go.mod file or is below a directory containing a go.mod file.
2326 // In module-aware mode, GOPATH no longer defines the meaning of imports
2327 // during a build, but it still stores downloaded dependencies (in GOPATH/pkg/mod)
2328 // and installed commands (in GOPATH/bin, unless GOBIN is set).
2330 // Defining a module
2332 // A module is defined by a tree of Go source files with a go.mod file
2333 // in the tree's root directory. The directory containing the go.mod file
2334 // is called the module root. Typically the module root will also correspond
2335 // to a source code repository root (but in general it need not).
2336 // The module is the set of all Go packages in the module root and its
2337 // subdirectories, but excluding subtrees with their own go.mod files.
2339 // The "module path" is the import path prefix corresponding to the module root.
2340 // The go.mod file defines the module path and lists the specific versions
2341 // of other modules that should be used when resolving imports during a build,
2342 // by giving their module paths and versions.
2344 // For example, this go.mod declares that the directory containing it is the root
2345 // of the module with path example.com/m, and it also declares that the module
2346 // depends on specific versions of golang.org/x/text and gopkg.in/yaml.v2:
2348 // module example.com/m
2351 // golang.org/x/text v0.3.0
2352 // gopkg.in/yaml.v2 v2.1.0
2355 // The go.mod file can also specify replacements and excluded versions
2356 // that only apply when building the module directly; they are ignored
2357 // when the module is incorporated into a larger build.
2358 // For more about the go.mod file, see 'go help go.mod'.
2360 // To start a new module, simply create a go.mod file in the root of the
2361 // module's directory tree, containing only a module statement.
2362 // The 'go mod init' command can be used to do this:
2364 // go mod init example.com/m
2366 // In a project already using an existing dependency management tool like
2367 // godep, glide, or dep, 'go mod init' will also add require statements
2368 // matching the existing configuration.
2370 // Once the go.mod file exists, no additional steps are required:
2371 // go commands like 'go build', 'go test', or even 'go list' will automatically
2372 // add new dependencies as needed to satisfy imports.
2374 // The main module and the build list
2376 // The "main module" is the module containing the directory where the go command
2377 // is run. The go command finds the module root by looking for a go.mod in the
2378 // current directory, or else the current directory's parent directory,
2379 // or else the parent's parent directory, and so on.
2381 // The main module's go.mod file defines the precise set of packages available
2382 // for use by the go command, through require, replace, and exclude statements.
2383 // Dependency modules, found by following require statements, also contribute
2384 // to the definition of that set of packages, but only through their go.mod
2385 // files' require statements: any replace and exclude statements in dependency
2386 // modules are ignored. The replace and exclude statements therefore allow the
2387 // main module complete control over its own build, without also being subject
2388 // to complete control by dependencies.
2390 // The set of modules providing packages to builds is called the "build list".
2391 // The build list initially contains only the main module. Then the go command
2392 // adds to the list the exact module versions required by modules already
2393 // on the list, recursively, until there is nothing left to add to the list.
2394 // If multiple versions of a particular module are added to the list,
2395 // then at the end only the latest version (according to semantic version
2396 // ordering) is kept for use in the build.
2398 // The 'go list' command provides information about the main module
2399 // and the build list. For example:
2401 // go list -m # print path of main module
2402 // go list -m -f={{.Dir}} # print root directory of main module
2403 // go list -m all # print build list
2405 // Maintaining module requirements
2407 // The go.mod file is meant to be readable and editable by both
2408 // programmers and tools. The go command itself automatically updates the go.mod file
2409 // to maintain a standard formatting and the accuracy of require statements.
2411 // Any go command that finds an unfamiliar import will look up the module
2412 // containing that import and add the latest version of that module
2413 // to go.mod automatically. In most cases, therefore, it suffices to
2414 // add an import to source code and run 'go build', 'go test', or even 'go list':
2415 // as part of analyzing the package, the go command will discover
2416 // and resolve the import and update the go.mod file.
2418 // Any go command can determine that a module requirement is
2419 // missing and must be added, even when considering only a single
2420 // package from the module. On the other hand, determining that a module requirement
2421 // is no longer necessary and can be deleted requires a full view of
2422 // all packages in the module, across all possible build configurations
2423 // (architectures, operating systems, build tags, and so on).
2424 // The 'go mod tidy' command builds that view and then
2425 // adds any missing module requirements and removes unnecessary ones.
2427 // As part of maintaining the require statements in go.mod, the go command
2428 // tracks which ones provide packages imported directly by the current module
2429 // and which ones provide packages only used indirectly by other module
2430 // dependencies. Requirements needed only for indirect uses are marked with a
2431 // "// indirect" comment in the go.mod file. Indirect requirements are
2432 // automatically removed from the go.mod file once they are implied by other
2433 // direct requirements. Indirect requirements only arise when using modules
2434 // that fail to state some of their own dependencies or when explicitly
2435 // upgrading a module's dependencies ahead of its own stated requirements.
2437 // Because of this automatic maintenance, the information in go.mod is an
2438 // up-to-date, readable description of the build.
2440 // The 'go get' command updates go.mod to change the module versions used in a
2441 // build. An upgrade of one module may imply upgrading others, and similarly a
2442 // downgrade of one module may imply downgrading others. The 'go get' command
2443 // makes these implied changes as well. If go.mod is edited directly, commands
2444 // like 'go build' or 'go list' will assume that an upgrade is intended and
2445 // automatically make any implied upgrades and update go.mod to reflect them.
2447 // The 'go mod' command provides other functionality for use in maintaining
2448 // and understanding modules and go.mod files. See 'go help mod'.
2450 // The -mod build flag provides additional control over updating and use of go.mod.
2452 // If invoked with -mod=readonly, the go command is disallowed from the implicit
2453 // automatic updating of go.mod described above. Instead, it fails when any changes
2454 // to go.mod are needed. This setting is most useful to check that go.mod does
2455 // not need updates, such as in a continuous integration and testing system.
2456 // The "go get" command remains permitted to update go.mod even with -mod=readonly,
2457 // and the "go mod" commands do not take the -mod flag (or any other build flags).
2459 // If invoked with -mod=vendor, the go command assumes that the vendor
2460 // directory holds the correct copies of dependencies and ignores
2461 // the dependency descriptions in go.mod.
2465 // The go.mod file and the go command more generally use semantic versions as
2466 // the standard form for describing module versions, so that versions can be
2467 // compared to determine which should be considered earlier or later than another.
2468 // A module version like v1.2.3 is introduced by tagging a revision in the
2469 // underlying source repository. Untagged revisions can be referred to
2470 // using a "pseudo-version" like v0.0.0-yyyymmddhhmmss-abcdefabcdef,
2471 // where the time is the commit time in UTC and the final suffix is the prefix
2472 // of the commit hash. The time portion ensures that two pseudo-versions can
2473 // be compared to determine which happened later, the commit hash identifes
2474 // the underlying commit, and the prefix (v0.0.0- in this example) is derived from
2475 // the most recent tagged version in the commit graph before this commit.
2477 // There are three pseudo-version forms:
2479 // vX.0.0-yyyymmddhhmmss-abcdefabcdef is used when there is no earlier
2480 // versioned commit with an appropriate major version before the target commit.
2481 // (This was originally the only form, so some older go.mod files use this form
2482 // even for commits that do follow tags.)
2484 // vX.Y.Z-pre.0.yyyymmddhhmmss-abcdefabcdef is used when the most
2485 // recent versioned commit before the target commit is vX.Y.Z-pre.
2487 // vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdefabcdef is used when the most
2488 // recent versioned commit before the target commit is vX.Y.Z.
2490 // Pseudo-versions never need to be typed by hand: the go command will accept
2491 // the plain commit hash and translate it into a pseudo-version (or a tagged
2492 // version if available) automatically. This conversion is an example of a
2497 // The go command accepts a "module query" in place of a module version
2498 // both on the command line and in the main module's go.mod file.
2499 // (After evaluating a query found in the main module's go.mod file,
2500 // the go command updates the file to replace the query with its result.)
2502 // A fully-specified semantic version, such as "v1.2.3",
2503 // evaluates to that specific version.
2505 // A semantic version prefix, such as "v1" or "v1.2",
2506 // evaluates to the latest available tagged version with that prefix.
2508 // A semantic version comparison, such as "<v1.2.3" or ">=v1.5.6",
2509 // evaluates to the available tagged version nearest to the comparison target
2510 // (the latest version for < and <=, the earliest version for > and >=).
2512 // The string "latest" matches the latest available tagged version,
2513 // or else the underlying source repository's latest untagged revision.
2515 // The string "upgrade" is like "latest", but if the module is
2516 // currently required at a later version than the version "latest"
2517 // would select (for example, a newer pre-release version), "upgrade"
2518 // will select the later version instead.
2520 // The string "patch" matches the latest available tagged version
2521 // of a module with the same major and minor version numbers as the
2522 // currently required version. If no version is currently required,
2523 // "patch" is equivalent to "latest".
2525 // A revision identifier for the underlying source repository, such as
2526 // a commit hash prefix, revision tag, or branch name, selects that
2527 // specific code revision. If the revision is also tagged with a
2528 // semantic version, the query evaluates to that semantic version.
2529 // Otherwise the query evaluates to a pseudo-version for the commit.
2530 // Note that branches and tags with names that are matched by other
2531 // query syntax cannot be selected this way. For example, the query
2532 // "v2" means the latest version starting with "v2", not the branch
2535 // All queries prefer release versions to pre-release versions.
2536 // For example, "<v1.2.3" will prefer to return "v1.2.2"
2537 // instead of "v1.2.3-pre1", even though "v1.2.3-pre1" is nearer
2538 // to the comparison target.
2540 // Module versions disallowed by exclude statements in the
2541 // main module's go.mod are considered unavailable and cannot
2542 // be returned by queries.
2544 // For example, these commands are all valid:
2546 // go get github.com/gorilla/mux@latest # same (@latest is default for 'go get')
2547 // go get github.com/gorilla/mux@v1.6.2 # records v1.6.2
2548 // go get github.com/gorilla/mux@e3702bed2 # records v1.6.2
2549 // go get github.com/gorilla/mux@c856192 # records v0.0.0-20180517173623-c85619274f5d
2550 // go get github.com/gorilla/mux@master # records current meaning of master
2552 // Module compatibility and semantic versioning
2554 // The go command requires that modules use semantic versions and expects that
2555 // the versions accurately describe compatibility: it assumes that v1.5.4 is a
2556 // backwards-compatible replacement for v1.5.3, v1.4.0, and even v1.0.0.
2557 // More generally the go command expects that packages follow the
2558 // "import compatibility rule", which says:
2560 // "If an old package and a new package have the same import path,
2561 // the new package must be backwards compatible with the old package."
2563 // Because the go command assumes the import compatibility rule,
2564 // a module definition can only set the minimum required version of one
2565 // of its dependencies: it cannot set a maximum or exclude selected versions.
2566 // Still, the import compatibility rule is not a guarantee: it may be that
2567 // v1.5.4 is buggy and not a backwards-compatible replacement for v1.5.3.
2568 // Because of this, the go command never updates from an older version
2569 // to a newer version of a module unasked.
2571 // In semantic versioning, changing the major version number indicates a lack
2572 // of backwards compatibility with earlier versions. To preserve import
2573 // compatibility, the go command requires that modules with major version v2
2574 // or later use a module path with that major version as the final element.
2575 // For example, version v2.0.0 of example.com/m must instead use module path
2576 // example.com/m/v2, and packages in that module would use that path as
2577 // their import path prefix, as in example.com/m/v2/sub/pkg. Including the
2578 // major version number in the module path and import paths in this way is
2579 // called "semantic import versioning". Pseudo-versions for modules with major
2580 // version v2 and later begin with that major version instead of v0, as in
2581 // v2.0.0-20180326061214-4fc5987536ef.
2583 // As a special case, module paths beginning with gopkg.in/ continue to use the
2584 // conventions established on that system: the major version is always present,
2585 // and it is preceded by a dot instead of a slash: gopkg.in/yaml.v1
2586 // and gopkg.in/yaml.v2, not gopkg.in/yaml and gopkg.in/yaml/v2.
2588 // The go command treats modules with different module paths as unrelated:
2589 // it makes no connection between example.com/m and example.com/m/v2.
2590 // Modules with different major versions can be used together in a build
2591 // and are kept separate by the fact that their packages use different
2594 // In semantic versioning, major version v0 is for initial development,
2595 // indicating no expectations of stability or backwards compatibility.
2596 // Major version v0 does not appear in the module path, because those
2597 // versions are preparation for v1.0.0, and v1 does not appear in the
2598 // module path either.
2600 // Code written before the semantic import versioning convention
2601 // was introduced may use major versions v2 and later to describe
2602 // the same set of unversioned import paths as used in v0 and v1.
2603 // To accommodate such code, if a source code repository has a
2604 // v2.0.0 or later tag for a file tree with no go.mod, the version is
2605 // considered to be part of the v1 module's available versions
2606 // and is given an +incompatible suffix when converted to a module
2607 // version, as in v2.0.0+incompatible. The +incompatible tag is also
2608 // applied to pseudo-versions derived from such versions, as in
2609 // v2.0.1-0.yyyymmddhhmmss-abcdefabcdef+incompatible.
2611 // In general, having a dependency in the build list (as reported by 'go list -m all')
2612 // on a v0 version, pre-release version, pseudo-version, or +incompatible version
2613 // is an indication that problems are more likely when upgrading that
2614 // dependency, since there is no expectation of compatibility for those.
2616 // See https://research.swtch.com/vgo-import for more information about
2617 // semantic import versioning, and see https://semver.org/ for more about
2618 // semantic versioning.
2620 // Module code layout
2622 // For now, see https://research.swtch.com/vgo-module for information
2623 // about how source code in version control systems is mapped to
2624 // module file trees.
2626 // Module downloading and verification
2628 // The go command can fetch modules from a proxy or connect to source control
2629 // servers directly, according to the setting of the GOPROXY environment
2630 // variable (see 'go help env'). The default setting for GOPROXY is
2631 // "https://proxy.golang.org,direct", which means to try the
2632 // Go module mirror run by Google and fall back to a direct connection
2633 // if the proxy reports that it does not have the module (HTTP error 404 or 410).
2634 // See https://proxy.golang.org/privacy for the service's privacy policy.
2635 // If GOPROXY is set to the string "direct", downloads use a direct connection
2636 // to source control servers. Setting GOPROXY to "off" disallows downloading
2637 // modules from any source. Otherwise, GOPROXY is expected to be a comma-separated
2638 // list of the URLs of module proxies, in which case the go command will fetch
2639 // modules from those proxies. For each request, the go command tries each proxy
2640 // in sequence, only moving to the next if the current proxy returns a 404 or 410
2641 // HTTP response. The string "direct" may appear in the proxy list,
2642 // to cause a direct connection to be attempted at that point in the search.
2643 // Any proxies listed after "direct" are never consulted.
2645 // The GOPRIVATE and GONOPROXY environment variables allow bypassing
2646 // the proxy for selected modules. See 'go help module-private' for details.
2648 // No matter the source of the modules, the go command checks downloads against
2649 // known checksums, to detect unexpected changes in the content of any specific
2650 // module version from one day to the next. This check first consults the current
2651 // module's go.sum file but falls back to the Go checksum database, controlled by
2652 // the GOSUMDB and GONOSUMDB environment variables. See 'go help module-auth'
2655 // See 'go help goproxy' for details about the proxy protocol and also
2656 // the format of the cached downloaded packages.
2658 // Modules and vendoring
2660 // When using modules, the go command completely ignores vendor directories.
2662 // By default, the go command satisfies dependencies by downloading modules
2663 // from their sources and using those downloaded copies (after verification,
2664 // as described in the previous section). To allow interoperation with older
2665 // versions of Go, or to ensure that all files used for a build are stored
2666 // together in a single file tree, 'go mod vendor' creates a directory named
2667 // vendor in the root directory of the main module and stores there all the
2668 // packages from dependency modules that are needed to support builds and
2669 // tests of packages in the main module.
2671 // To build using the main module's top-level vendor directory to satisfy
2672 // dependencies (disabling use of the usual network sources and local
2673 // caches), use 'go build -mod=vendor'. Note that only the main module's
2674 // top-level vendor directory is used; vendor directories in other locations
2675 // are still ignored.
2678 // Module authentication using go.sum
2680 // The go command tries to authenticate every downloaded module,
2681 // checking that the bits downloaded for a specific module version today
2682 // match bits downloaded yesterday. This ensures repeatable builds
2683 // and detects introduction of unexpected changes, malicious or not.
2685 // In each module's root, alongside go.mod, the go command maintains
2686 // a file named go.sum containing the cryptographic checksums of the
2687 // module's dependencies.
2689 // The form of each line in go.sum is three fields:
2691 // <module> <version>[/go.mod] <hash>
2693 // Each known module version results in two lines in the go.sum file.
2694 // The first line gives the hash of the module version's file tree.
2695 // The second line appends "/go.mod" to the version and gives the hash
2696 // of only the module version's (possibly synthesized) go.mod file.
2697 // The go.mod-only hash allows downloading and authenticating a
2698 // module version's go.mod file, which is needed to compute the
2699 // dependency graph, without also downloading all the module's source code.
2701 // The hash begins with an algorithm prefix of the form "h<N>:".
2702 // The only defined algorithm prefix is "h1:", which uses SHA-256.
2704 // Module authentication failures
2706 // The go command maintains a cache of downloaded packages and computes
2707 // and records the cryptographic checksum of each package at download time.
2708 // In normal operation, the go command checks the main module's go.sum file
2709 // against these precomputed checksums instead of recomputing them on
2710 // each command invocation. The 'go mod verify' command checks that
2711 // the cached copies of module downloads still match both their recorded
2712 // checksums and the entries in go.sum.
2714 // In day-to-day development, the checksum of a given module version
2715 // should never change. Each time a dependency is used by a given main
2716 // module, the go command checks its local cached copy, freshly
2717 // downloaded or not, against the main module's go.sum. If the checksums
2718 // don't match, the go command reports the mismatch as a security error
2719 // and refuses to run the build. When this happens, proceed with caution:
2720 // code changing unexpectedly means today's build will not match
2721 // yesterday's, and the unexpected change may not be beneficial.
2723 // If the go command reports a mismatch in go.sum, the downloaded code
2724 // for the reported module version does not match the one used in a
2725 // previous build of the main module. It is important at that point
2726 // to find out what the right checksum should be, to decide whether
2727 // go.sum is wrong or the downloaded code is wrong. Usually go.sum is right:
2728 // you want to use the same code you used yesterday.
2730 // If a downloaded module is not yet included in go.sum and it is a publicly
2731 // available module, the go command consults the Go checksum database to fetch
2732 // the expected go.sum lines. If the downloaded code does not match those
2733 // lines, the go command reports the mismatch and exits. Note that the
2734 // database is not consulted for module versions already listed in go.sum.
2736 // If a go.sum mismatch is reported, it is always worth investigating why
2737 // the code downloaded today differs from what was downloaded yesterday.
2739 // The GOSUMDB environment variable identifies the name of checksum database
2740 // to use and optionally its public key and URL, as in:
2742 // GOSUMDB="sum.golang.org"
2743 // GOSUMDB="sum.golang.org+<publickey>"
2744 // GOSUMDB="sum.golang.org+<publickey> https://sum.golang.org"
2746 // The go command knows the public key of sum.golang.org, and also that the name
2747 // sum.golang.google.cn (available inside mainland China) connects to the
2748 // sum.golang.org checksum database; use of any other database requires giving
2749 // the public key explicitly.
2750 // The URL defaults to "https://" followed by the database name.
2752 // GOSUMDB defaults to "sum.golang.org", the Go checksum database run by Google.
2753 // See https://sum.golang.org/privacy for the service's privacy policy.
2755 // If GOSUMDB is set to "off", or if "go get" is invoked with the -insecure flag,
2756 // the checksum database is not consulted, and all unrecognized modules are
2757 // accepted, at the cost of giving up the security guarantee of verified repeatable
2758 // downloads for all modules. A better way to bypass the checksum database
2759 // for specific modules is to use the GOPRIVATE or GONOSUMDB environment
2760 // variables. See 'go help module-private' for details.
2762 // The 'go env -w' command (see 'go help env') can be used to set these variables
2763 // for future go command invocations.
2766 // Module configuration for non-public modules
2768 // The go command defaults to downloading modules from the public Go module
2769 // mirror at proxy.golang.org. It also defaults to validating downloaded modules,
2770 // regardless of source, against the public Go checksum database at sum.golang.org.
2771 // These defaults work well for publicly available source code.
2773 // The GOPRIVATE environment variable controls which modules the go command
2774 // considers to be private (not available publicly) and should therefore not use the
2775 // proxy or checksum database. The variable is a comma-separated list of
2776 // glob patterns (in the syntax of Go's path.Match) of module path prefixes.
2779 // GOPRIVATE=*.corp.example.com,rsc.io/private
2781 // causes the go command to treat as private any module with a path prefix
2782 // matching either pattern, including git.corp.example.com/xyzzy, rsc.io/private,
2783 // and rsc.io/private/quux.
2785 // The GOPRIVATE environment variable may be used by other tools as well to
2786 // identify non-public modules. For example, an editor could use GOPRIVATE
2787 // to decide whether to hyperlink a package import to a godoc.org page.
2789 // For fine-grained control over module download and validation, the GONOPROXY
2790 // and GONOSUMDB environment variables accept the same kind of glob list
2791 // and override GOPRIVATE for the specific decision of whether to use the proxy
2792 // and checksum database, respectively.
2794 // For example, if a company ran a module proxy serving private modules,
2795 // users would configure go using:
2797 // GOPRIVATE=*.corp.example.com
2798 // GOPROXY=proxy.example.com
2801 // This would tell the go command and other tools that modules beginning with
2802 // a corp.example.com subdomain are private but that the company proxy should
2803 // be used for downloading both public and private modules, because
2804 // GONOPROXY has been set to a pattern that won't match any modules,
2805 // overriding GOPRIVATE.
2807 // The 'go env -w' command (see 'go help env') can be used to set these variables
2808 // for future go command invocations.
2811 // Package lists and patterns
2813 // Many commands apply to a set of packages:
2815 // go action [packages]
2817 // Usually, [packages] is a list of import paths.
2819 // An import path that is a rooted path or that begins with
2820 // a . or .. element is interpreted as a file system path and
2821 // denotes the package in that directory.
2823 // Otherwise, the import path P denotes the package found in
2824 // the directory DIR/src/P for some DIR listed in the GOPATH
2825 // environment variable (For more details see: 'go help gopath').
2827 // If no import paths are given, the action applies to the
2828 // package in the current directory.
2830 // There are four reserved names for paths that should not be used
2831 // for packages to be built with the go tool:
2833 // - "main" denotes the top-level package in a stand-alone executable.
2835 // - "all" expands to all packages found in all the GOPATH
2836 // trees. For example, 'go list all' lists all the packages on the local
2837 // system. When using modules, "all" expands to all packages in
2838 // the main module and their dependencies, including dependencies
2839 // needed by tests of any of those.
2841 // - "std" is like all but expands to just the packages in the standard
2844 // - "cmd" expands to the Go repository's commands and their
2845 // internal libraries.
2847 // Import paths beginning with "cmd/" only match source code in
2848 // the Go repository.
2850 // An import path is a pattern if it includes one or more "..." wildcards,
2851 // each of which can match any string, including the empty string and
2852 // strings containing slashes. Such a pattern expands to all package
2853 // directories found in the GOPATH trees with names matching the
2856 // To make common patterns more convenient, there are two special cases.
2857 // First, /... at the end of the pattern can match an empty string,
2858 // so that net/... matches both net and packages in its subdirectories, like net/http.
2859 // Second, any slash-separated pattern element containing a wildcard never
2860 // participates in a match of the "vendor" element in the path of a vendored
2861 // package, so that ./... does not match packages in subdirectories of
2862 // ./vendor or ./mycode/vendor, but ./vendor/... and ./mycode/vendor/... do.
2863 // Note, however, that a directory named vendor that itself contains code
2864 // is not a vendored package: cmd/vendor would be a command named vendor,
2865 // and the pattern cmd/... matches it.
2866 // See golang.org/s/go15vendor for more about vendoring.
2868 // An import path can also name a package to be downloaded from
2869 // a remote repository. Run 'go help importpath' for details.
2871 // Every package in a program must have a unique import path.
2872 // By convention, this is arranged by starting each path with a
2873 // unique prefix that belongs to you. For example, paths used
2874 // internally at Google all begin with 'google', and paths
2875 // denoting remote repositories begin with the path to the code,
2876 // such as 'github.com/user/repo'.
2878 // Packages in a program need not have unique package names,
2879 // but there are two reserved package names with special meaning.
2880 // The name main indicates a command, not a library.
2881 // Commands are built into binaries and cannot be imported.
2882 // The name documentation indicates documentation for
2883 // a non-Go program in the directory. Files in package documentation
2884 // are ignored by the go command.
2886 // As a special case, if the package list is a list of .go files from a
2887 // single directory, the command is applied to a single synthesized
2888 // package made up of exactly those files, ignoring any build constraints
2889 // in those files and ignoring any other files in the directory.
2891 // Directory and file names that begin with "." or "_" are ignored
2892 // by the go tool, as are directories named "testdata".
2897 // The 'go test' command takes both flags that apply to 'go test' itself
2898 // and flags that apply to the resulting test binary.
2900 // Several of the flags control profiling and write an execution profile
2901 // suitable for "go tool pprof"; run "go tool pprof -h" for more
2902 // information. The --alloc_space, --alloc_objects, and --show_bytes
2903 // options of pprof control how the information is presented.
2905 // The following flags are recognized by the 'go test' command and
2906 // control the execution of any test:
2909 // Run only those benchmarks matching a regular expression.
2910 // By default, no benchmarks are run.
2911 // To run all benchmarks, use '-bench .' or '-bench=.'.
2912 // The regular expression is split by unbracketed slash (/)
2913 // characters into a sequence of regular expressions, and each
2914 // part of a benchmark's identifier must match the corresponding
2915 // element in the sequence, if any. Possible parents of matches
2916 // are run with b.N=1 to identify sub-benchmarks. For example,
2917 // given -bench=X/Y, top-level benchmarks matching X are run
2918 // with b.N=1 to find any sub-benchmarks matching Y, which are
2919 // then run in full.
2922 // Run enough iterations of each benchmark to take t, specified
2923 // as a time.Duration (for example, -benchtime 1h30s).
2924 // The default is 1 second (1s).
2925 // The special syntax Nx means to run the benchmark N times
2926 // (for example, -benchtime 100x).
2929 // Run each test and benchmark n times (default 1).
2930 // If -cpu is set, run n times for each GOMAXPROCS value.
2931 // Examples are always run once.
2934 // Enable coverage analysis.
2935 // Note that because coverage works by annotating the source
2936 // code before compilation, compilation and test failures with
2937 // coverage enabled may report line numbers that don't correspond
2938 // to the original sources.
2940 // -covermode set,count,atomic
2941 // Set the mode for coverage analysis for the package[s]
2942 // being tested. The default is "set" unless -race is enabled,
2943 // in which case it is "atomic".
2945 // set: bool: does this statement run?
2946 // count: int: how many times does this statement run?
2947 // atomic: int: count, but correct in multithreaded tests;
2948 // significantly more expensive.
2951 // -coverpkg pattern1,pattern2,pattern3
2952 // Apply coverage analysis in each test to packages matching the patterns.
2953 // The default is for each test to analyze only the package being tested.
2954 // See 'go help packages' for a description of package patterns.
2958 // Specify a list of GOMAXPROCS values for which the tests or
2959 // benchmarks should be executed. The default is the current value
2963 // Do not start new tests after the first test failure.
2966 // List tests, benchmarks, or examples matching the regular expression.
2967 // No tests, benchmarks or examples will be run. This will only
2968 // list top-level tests. No subtest or subbenchmarks will be shown.
2971 // Allow parallel execution of test functions that call t.Parallel.
2972 // The value of this flag is the maximum number of tests to run
2973 // simultaneously; by default, it is set to the value of GOMAXPROCS.
2974 // Note that -parallel only applies within a single test binary.
2975 // The 'go test' command may run tests for different packages
2976 // in parallel as well, according to the setting of the -p flag
2977 // (see 'go help build').
2980 // Run only those tests and examples matching the regular expression.
2981 // For tests, the regular expression is split by unbracketed slash (/)
2982 // characters into a sequence of regular expressions, and each part
2983 // of a test's identifier must match the corresponding element in
2984 // the sequence, if any. Note that possible parents of matches are
2985 // run too, so that -run=X/Y matches and runs and reports the result
2986 // of all tests matching X, even those without sub-tests matching Y,
2987 // because it must run them to look for those sub-tests.
2990 // Tell long-running tests to shorten their run time.
2991 // It is off by default but set during all.bash so that installing
2992 // the Go tree can run a sanity check but not spend time running
2993 // exhaustive tests.
2996 // If a test binary runs longer than duration d, panic.
2997 // If d is 0, the timeout is disabled.
2998 // The default is 10 minutes (10m).
3001 // Verbose output: log all tests as they are run. Also print all
3002 // text from Log and Logf calls even if the test succeeds.
3005 // Configure the invocation of "go vet" during "go test"
3006 // to use the comma-separated list of vet checks.
3007 // If list is empty, "go test" runs "go vet" with a curated list of
3008 // checks believed to be always worth addressing.
3009 // If list is "off", "go test" does not run "go vet" at all.
3011 // The following flags are also recognized by 'go test' and can be used to
3012 // profile the tests during execution:
3015 // Print memory allocation statistics for benchmarks.
3017 // -blockprofile block.out
3018 // Write a goroutine blocking profile to the specified file
3019 // when all tests are complete.
3020 // Writes test binary as -c would.
3022 // -blockprofilerate n
3023 // Control the detail provided in goroutine blocking profiles by
3024 // calling runtime.SetBlockProfileRate with n.
3025 // See 'go doc runtime.SetBlockProfileRate'.
3026 // The profiler aims to sample, on average, one blocking event every
3027 // n nanoseconds the program spends blocked. By default,
3028 // if -test.blockprofile is set without this flag, all blocking events
3029 // are recorded, equivalent to -test.blockprofilerate=1.
3031 // -coverprofile cover.out
3032 // Write a coverage profile to the file after all tests have passed.
3035 // -cpuprofile cpu.out
3036 // Write a CPU profile to the specified file before exiting.
3037 // Writes test binary as -c would.
3039 // -memprofile mem.out
3040 // Write an allocation profile to the file after all tests have passed.
3041 // Writes test binary as -c would.
3043 // -memprofilerate n
3044 // Enable more precise (and expensive) memory allocation profiles by
3045 // setting runtime.MemProfileRate. See 'go doc runtime.MemProfileRate'.
3046 // To profile all memory allocations, use -test.memprofilerate=1.
3048 // -mutexprofile mutex.out
3049 // Write a mutex contention profile to the specified file
3050 // when all tests are complete.
3051 // Writes test binary as -c would.
3053 // -mutexprofilefraction n
3054 // Sample 1 in n stack traces of goroutines holding a
3057 // -outputdir directory
3058 // Place output files from profiling in the specified directory,
3059 // by default the directory in which "go test" is running.
3062 // Write an execution trace to the specified file before exiting.
3064 // Each of these flags is also recognized with an optional 'test.' prefix,
3065 // as in -test.v. When invoking the generated test binary (the result of
3066 // 'go test -c') directly, however, the prefix is mandatory.
3068 // The 'go test' command rewrites or removes recognized flags,
3069 // as appropriate, both before and after the optional package list,
3070 // before invoking the test binary.
3072 // For instance, the command
3074 // go test -v -myflag testdata -cpuprofile=prof.out -x
3076 // will compile the test binary and then run it as
3078 // pkg.test -test.v -myflag testdata -test.cpuprofile=prof.out
3080 // (The -x flag is removed because it applies only to the go command's
3081 // execution, not to the test itself.)
3083 // The test flags that generate profiles (other than for coverage) also
3084 // leave the test binary in pkg.test for use when analyzing the profiles.
3086 // When 'go test' runs a test binary, it does so from within the
3087 // corresponding package's source code directory. Depending on the test,
3088 // it may be necessary to do the same when invoking a generated test
3091 // The command-line package list, if present, must appear before any
3092 // flag not known to the go test command. Continuing the example above,
3093 // the package list would have to appear before -myflag, but could appear
3094 // on either side of -v.
3096 // When 'go test' runs in package list mode, 'go test' caches successful
3097 // package test results to avoid unnecessary repeated running of tests. To
3098 // disable test caching, use any test flag or argument other than the
3099 // cacheable flags. The idiomatic way to disable test caching explicitly
3100 // is to use -count=1.
3102 // To keep an argument for a test binary from being interpreted as a
3103 // known flag or a package name, use -args (see 'go help test') which
3104 // passes the remainder of the command line through to the test binary
3105 // uninterpreted and unaltered.
3107 // For instance, the command
3109 // go test -v -args -x -v
3111 // will compile the test binary and then run it as
3113 // pkg.test -test.v -x -v
3117 // go test -args math
3119 // will compile the test binary and then run it as
3123 // In the first example, the -x and the second -v are passed through to the
3124 // test binary unchanged and with no effect on the go command itself.
3125 // In the second example, the argument math is passed through to the test
3126 // binary, instead of being interpreted as the package list.
3129 // Testing functions
3131 // The 'go test' command expects to find test, benchmark, and example functions
3132 // in the "*_test.go" files corresponding to the package under test.
3134 // A test function is one named TestXxx (where Xxx does not start with a
3135 // lower case letter) and should have the signature,
3137 // func TestXxx(t *testing.T) { ... }
3139 // A benchmark function is one named BenchmarkXxx and should have the signature,
3141 // func BenchmarkXxx(b *testing.B) { ... }
3143 // An example function is similar to a test function but, instead of using
3144 // *testing.T to report success or failure, prints output to os.Stdout.
3145 // If the last comment in the function starts with "Output:" then the output
3146 // is compared exactly against the comment (see examples below). If the last
3147 // comment begins with "Unordered output:" then the output is compared to the
3148 // comment, however the order of the lines is ignored. An example with no such
3149 // comment is compiled but not executed. An example with no text after
3150 // "Output:" is compiled, executed, and expected to produce no output.
3152 // Godoc displays the body of ExampleXxx to demonstrate the use
3153 // of the function, constant, or variable Xxx. An example of a method M with
3154 // receiver type T or *T is named ExampleT_M. There may be multiple examples
3155 // for a given function, constant, or variable, distinguished by a trailing _xxx,
3156 // where xxx is a suffix not beginning with an upper case letter.
3158 // Here is an example of an example:
3160 // func ExamplePrintln() {
3161 // Println("The output of\nthis example.")
3162 // // Output: The output of
3166 // Here is another example where the ordering of the output is ignored:
3168 // func ExamplePerm() {
3169 // for _, value := range Perm(4) {
3170 // fmt.Println(value)
3173 // // Unordered output: 4
3180 // The entire test file is presented as the example when it contains a single
3181 // example function, at least one other function, type, variable, or constant
3182 // declaration, and no test or benchmark functions.
3184 // See the documentation of the testing package for more information.