github.com/bir3/gocompiler@v0.9.2202/src/cmd/gocmd/alldocs.go (about)

     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.
     4  
     5  // Code generated by 'go test cmd/go -v -run=^TestDocsUpToDate$ -fixdocs'; DO NOT EDIT.
     6  // Edit the documentation in other files and then execute 'go generate cmd/go' to generate this one.
     7  
     8  // Go is a tool for managing Go source code.
     9  //
    10  // Usage:
    11  //
    12  //	go <command> [arguments]
    13  //
    14  // The commands are:
    15  //
    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  //	work        workspace maintenance
    29  //	run         compile and run Go program
    30  //	test        test packages
    31  //	tool        run specified go tool
    32  //	version     print Go version
    33  //	vet         report likely mistakes in packages
    34  //
    35  // Use "go help <command>" for more information about a command.
    36  //
    37  // Additional help topics:
    38  //
    39  //	buildconstraint build constraints
    40  //	buildmode       build modes
    41  //	c               calling between Go and C
    42  //	cache           build and test caching
    43  //	environment     environment variables
    44  //	filetype        file types
    45  //	go.mod          the go.mod file
    46  //	gopath          GOPATH environment variable
    47  //	goproxy         module proxy protocol
    48  //	importpath      import path syntax
    49  //	modules         modules, module versions, and more
    50  //	module-auth     module authentication using go.sum
    51  //	packages        package lists and patterns
    52  //	private         configuration for downloading non-public code
    53  //	testflag        testing flags
    54  //	testfunc        testing functions
    55  //	vcs             controlling version control with GOVCS
    56  //
    57  // Use "go help <topic>" for more information about that topic.
    58  //
    59  // # Start a bug report
    60  //
    61  // Usage:
    62  //
    63  //	go bug
    64  //
    65  // Bug opens the default browser and starts a new bug report.
    66  // The report includes useful system information.
    67  //
    68  // # Compile packages and dependencies
    69  //
    70  // Usage:
    71  //
    72  //	go build [-o output] [build flags] [packages]
    73  //
    74  // Build compiles the packages named by the import paths,
    75  // along with their dependencies, but it does not install the results.
    76  //
    77  // If the arguments to build are a list of .go files from a single directory,
    78  // build treats them as a list of source files specifying a single package.
    79  //
    80  // When compiling packages, build ignores files that end in '_test.go'.
    81  //
    82  // When compiling a single main package, build writes the resulting
    83  // executable to an output file named after the last non-major-version
    84  // component of the package import path. The '.exe' suffix is added
    85  // when writing a Windows executable.
    86  // So 'go build example/sam' writes 'sam' or 'sam.exe'.
    87  // 'go build example.com/foo/v2' writes 'foo' or 'foo.exe', not 'v2.exe'.
    88  //
    89  // When compiling a package from a list of .go files, the executable
    90  // is named after the first source file.
    91  // 'go build ed.go rx.go' writes 'ed' or 'ed.exe'.
    92  //
    93  // When compiling multiple packages or a single non-main package,
    94  // build compiles the packages but discards the resulting object,
    95  // serving only as a check that the packages can be built.
    96  //
    97  // The -o flag forces build to write the resulting executable or object
    98  // to the named output file or directory, instead of the default behavior described
    99  // in the last two paragraphs. If the named output is an existing directory or
   100  // ends with a slash or backslash, then any resulting executables
   101  // will be written to that directory.
   102  //
   103  // The build flags are shared by the build, clean, get, install, list, run,
   104  // and test commands:
   105  //
   106  //	-C dir
   107  //		Change to dir before running the command.
   108  //		Any files named on the command line are interpreted after
   109  //		changing directories.
   110  //		If used, this flag must be the first one in the command line.
   111  //	-a
   112  //		force rebuilding of packages that are already up-to-date.
   113  //	-n
   114  //		print the commands but do not run them.
   115  //	-p n
   116  //		the number of programs, such as build commands or
   117  //		test binaries, that can be run in parallel.
   118  //		The default is GOMAXPROCS, normally the number of CPUs available.
   119  //	-race
   120  //		enable data race detection.
   121  //		Supported only on linux/amd64, freebsd/amd64, darwin/amd64, darwin/arm64, windows/amd64,
   122  //		linux/ppc64le and linux/arm64 (only for 48-bit VMA).
   123  //	-msan
   124  //		enable interoperation with memory sanitizer.
   125  //		Supported only on linux/amd64, linux/arm64, linux/loong64, freebsd/amd64
   126  //		and only with Clang/LLVM as the host C compiler.
   127  //		PIE build mode will be used on all platforms except linux/amd64.
   128  //	-asan
   129  //		enable interoperation with address sanitizer.
   130  //		Supported only on linux/arm64, linux/amd64, linux/loong64.
   131  //		Supported on linux/amd64 or linux/arm64 and only with GCC 7 and higher
   132  //		or Clang/LLVM 9 and higher.
   133  //		And supported on linux/loong64 only with Clang/LLVM 16 and higher.
   134  //	-cover
   135  //		enable code coverage instrumentation.
   136  //	-covermode set,count,atomic
   137  //		set the mode for coverage analysis.
   138  //		The default is "set" unless -race is enabled,
   139  //		in which case it is "atomic".
   140  //		The values:
   141  //		set: bool: does this statement run?
   142  //		count: int: how many times does this statement run?
   143  //		atomic: int: count, but correct in multithreaded tests;
   144  //			significantly more expensive.
   145  //		Sets -cover.
   146  //	-coverpkg pattern1,pattern2,pattern3
   147  //		For a build that targets package 'main' (e.g. building a Go
   148  //		executable), apply coverage analysis to each package matching
   149  //		the patterns. The default is to apply coverage analysis to
   150  //		packages in the main Go module. See 'go help packages' for a
   151  //		description of package patterns.  Sets -cover.
   152  //	-v
   153  //		print the names of packages as they are compiled.
   154  //	-work
   155  //		print the name of the temporary work directory and
   156  //		do not delete it when exiting.
   157  //	-x
   158  //		print the commands.
   159  //	-asmflags '[pattern=]arg list'
   160  //		arguments to pass on each go tool asm invocation.
   161  //	-buildmode mode
   162  //		build mode to use. See 'go help buildmode' for more.
   163  //	-buildvcs
   164  //		Whether to stamp binaries with version control information
   165  //		("true", "false", or "auto"). By default ("auto"), version control
   166  //		information is stamped into a binary if the main package, the main module
   167  //		containing it, and the current directory are all in the same repository.
   168  //		Use -buildvcs=false to always omit version control information, or
   169  //		-buildvcs=true to error out if version control information is available but
   170  //		cannot be included due to a missing tool or ambiguous directory structure.
   171  //	-compiler name
   172  //		name of compiler to use, as in runtime.Compiler (gccgo or gc).
   173  //	-gccgoflags '[pattern=]arg list'
   174  //		arguments to pass on each gccgo compiler/linker invocation.
   175  //	-gcflags '[pattern=]arg list'
   176  //		arguments to pass on each go tool compile invocation.
   177  //	-installsuffix suffix
   178  //		a suffix to use in the name of the package installation directory,
   179  //		in order to keep output separate from default builds.
   180  //		If using the -race flag, the install suffix is automatically set to race
   181  //		or, if set explicitly, has _race appended to it. Likewise for the -msan
   182  //		and -asan flags. Using a -buildmode option that requires non-default compile
   183  //		flags has a similar effect.
   184  //	-ldflags '[pattern=]arg list'
   185  //		arguments to pass on each go tool link invocation.
   186  //	-linkshared
   187  //		build code that will be linked against shared libraries previously
   188  //		created with -buildmode=shared.
   189  //	-mod mode
   190  //		module download mode to use: readonly, vendor, or mod.
   191  //		By default, if a vendor directory is present and the go version in go.mod
   192  //		is 1.14 or higher, the go command acts as if -mod=vendor were set.
   193  //		Otherwise, the go command acts as if -mod=readonly were set.
   194  //		See https://golang.org/ref/mod#build-commands for details.
   195  //	-modcacherw
   196  //		leave newly-created directories in the module cache read-write
   197  //		instead of making them read-only.
   198  //	-modfile file
   199  //		in module aware mode, read (and possibly write) an alternate go.mod
   200  //		file instead of the one in the module root directory. A file named
   201  //		"go.mod" must still be present in order to determine the module root
   202  //		directory, but it is not accessed. When -modfile is specified, an
   203  //		alternate go.sum file is also used: its path is derived from the
   204  //		-modfile flag by trimming the ".mod" extension and appending ".sum".
   205  //	-overlay file
   206  //		read a JSON config file that provides an overlay for build operations.
   207  //		The file is a JSON struct with a single field, named 'Replace', that
   208  //		maps each disk file path (a string) to its backing file path, so that
   209  //		a build will run as if the disk file path exists with the contents
   210  //		given by the backing file paths, or as if the disk file path does not
   211  //		exist if its backing file path is empty. Support for the -overlay flag
   212  //		has some limitations: importantly, cgo files included from outside the
   213  //		include path must be in the same directory as the Go package they are
   214  //		included from, and overlays will not appear when binaries and tests are
   215  //		run through go run and go test respectively.
   216  //	-pgo file
   217  //		specify the file path of a profile for profile-guided optimization (PGO).
   218  //		When the special name "auto" is specified, for each main package in the
   219  //		build, the go command selects a file named "default.pgo" in the package's
   220  //		directory if that file exists, and applies it to the (transitive)
   221  //		dependencies of the main package (other packages are not affected).
   222  //		Special name "off" turns off PGO. The default is "auto".
   223  //	-pkgdir dir
   224  //		install and load all packages from dir instead of the usual locations.
   225  //		For example, when building with a non-standard configuration,
   226  //		use -pkgdir to keep generated packages in a separate location.
   227  //	-tags tag,list
   228  //		a comma-separated list of additional build tags to consider satisfied
   229  //		during the build. For more information about build tags, see
   230  //		'go help buildconstraint'. (Earlier versions of Go used a
   231  //		space-separated list, and that form is deprecated but still recognized.)
   232  //	-trimpath
   233  //		remove all file system paths from the resulting executable.
   234  //		Instead of absolute file system paths, the recorded file names
   235  //		will begin either a module path@version (when using modules),
   236  //		or a plain import path (when using the standard library, or GOPATH).
   237  //	-toolexec 'cmd args'
   238  //		a program to use to invoke toolchain programs like vet and asm.
   239  //		For example, instead of running asm, the go command will run
   240  //		'cmd args /path/to/asm <arguments for asm>'.
   241  //		The TOOLEXEC_IMPORTPATH environment variable will be set,
   242  //		matching 'go list -f {{.ImportPath}}' for the package being built.
   243  //
   244  // The -asmflags, -gccgoflags, -gcflags, and -ldflags flags accept a
   245  // space-separated list of arguments to pass to an underlying tool
   246  // during the build. To embed spaces in an element in the list, surround
   247  // it with either single or double quotes. The argument list may be
   248  // preceded by a package pattern and an equal sign, which restricts
   249  // the use of that argument list to the building of packages matching
   250  // that pattern (see 'go help packages' for a description of package
   251  // patterns). Without a pattern, the argument list applies only to the
   252  // packages named on the command line. The flags may be repeated
   253  // with different patterns in order to specify different arguments for
   254  // different sets of packages. If a package matches patterns given in
   255  // multiple flags, the latest match on the command line wins.
   256  // For example, 'go build -gcflags=-S fmt' prints the disassembly
   257  // only for package fmt, while 'go build -gcflags=all=-S fmt'
   258  // prints the disassembly for fmt and all its dependencies.
   259  //
   260  // For more about specifying packages, see 'go help packages'.
   261  // For more about where packages and binaries are installed,
   262  // run 'go help gopath'.
   263  // For more about calling between Go and C/C++, run 'go help c'.
   264  //
   265  // Note: Build adheres to certain conventions such as those described
   266  // by 'go help gopath'. Not all projects can follow these conventions,
   267  // however. Installations that have their own conventions or that use
   268  // a separate software build system may choose to use lower-level
   269  // invocations such as 'go tool compile' and 'go tool link' to avoid
   270  // some of the overheads and design decisions of the build tool.
   271  //
   272  // See also: go install, go get, go clean.
   273  //
   274  // # Remove object files and cached files
   275  //
   276  // Usage:
   277  //
   278  //	go clean [clean flags] [build flags] [packages]
   279  //
   280  // Clean removes object files from package source directories.
   281  // The go command builds most objects in a temporary directory,
   282  // so go clean is mainly concerned with object files left by other
   283  // tools or by manual invocations of go build.
   284  //
   285  // If a package argument is given or the -i or -r flag is set,
   286  // clean removes the following files from each of the
   287  // source directories corresponding to the import paths:
   288  //
   289  //	_obj/            old object directory, left from Makefiles
   290  //	_test/           old test directory, left from Makefiles
   291  //	_testmain.go     old gotest file, left from Makefiles
   292  //	test.out         old test log, left from Makefiles
   293  //	build.out        old test log, left from Makefiles
   294  //	*.[568ao]        object files, left from Makefiles
   295  //
   296  //	DIR(.exe)        from go build
   297  //	DIR.test(.exe)   from go test -c
   298  //	MAINFILE(.exe)   from go build MAINFILE.go
   299  //	*.so             from SWIG
   300  //
   301  // In the list, DIR represents the final path element of the
   302  // directory, and MAINFILE is the base name of any Go source
   303  // file in the directory that is not included when building
   304  // the package.
   305  //
   306  // The -i flag causes clean to remove the corresponding installed
   307  // archive or binary (what 'go install' would create).
   308  //
   309  // The -n flag causes clean to print the remove commands it would execute,
   310  // but not run them.
   311  //
   312  // The -r flag causes clean to be applied recursively to all the
   313  // dependencies of the packages named by the import paths.
   314  //
   315  // The -x flag causes clean to print remove commands as it executes them.
   316  //
   317  // The -cache flag causes clean to remove the entire go build cache.
   318  //
   319  // The -testcache flag causes clean to expire all test results in the
   320  // go build cache.
   321  //
   322  // The -modcache flag causes clean to remove the entire module
   323  // download cache, including unpacked source code of versioned
   324  // dependencies.
   325  //
   326  // The -fuzzcache flag causes clean to remove files stored in the Go build
   327  // cache for fuzz testing. The fuzzing engine caches files that expand
   328  // code coverage, so removing them may make fuzzing less effective until
   329  // new inputs are found that provide the same coverage. These files are
   330  // distinct from those stored in testdata directory; clean does not remove
   331  // those files.
   332  //
   333  // For more about build flags, see 'go help build'.
   334  //
   335  // For more about specifying packages, see 'go help packages'.
   336  //
   337  // # Show documentation for package or symbol
   338  //
   339  // Usage:
   340  //
   341  //	go doc [doc flags] [package|[package.]symbol[.methodOrField]]
   342  //
   343  // Doc prints the documentation comments associated with the item identified by its
   344  // arguments (a package, const, func, type, var, method, or struct field)
   345  // followed by a one-line summary of each of the first-level items "under"
   346  // that item (package-level declarations for a package, methods for a type,
   347  // etc.).
   348  //
   349  // Doc accepts zero, one, or two arguments.
   350  //
   351  // Given no arguments, that is, when run as
   352  //
   353  //	go doc
   354  //
   355  // it prints the package documentation for the package in the current directory.
   356  // If the package is a command (package gocmd), the exported symbols of the package
   357  // are elided from the presentation unless the -cmd flag is provided.
   358  //
   359  // When run with one argument, the argument is treated as a Go-syntax-like
   360  // representation of the item to be documented. What the argument selects depends
   361  // on what is installed in GOROOT and GOPATH, as well as the form of the argument,
   362  // which is schematically one of these:
   363  //
   364  //	go doc <pkg>
   365  //	go doc <sym>[.<methodOrField>]
   366  //	go doc [<pkg>.]<sym>[.<methodOrField>]
   367  //	go doc [<pkg>.][<sym>.]<methodOrField>
   368  //
   369  // The first item in this list matched by the argument is the one whose documentation
   370  // is printed. (See the examples below.) However, if the argument starts with a capital
   371  // letter it is assumed to identify a symbol or method in the current directory.
   372  //
   373  // For packages, the order of scanning is determined lexically in breadth-first order.
   374  // That is, the package presented is the one that matches the search and is nearest
   375  // the root and lexically first at its level of the hierarchy. The GOROOT tree is
   376  // always scanned in its entirety before GOPATH.
   377  //
   378  // If there is no package specified or matched, the package in the current
   379  // directory is selected, so "go doc Foo" shows the documentation for symbol Foo in
   380  // the current package.
   381  //
   382  // The package path must be either a qualified path or a proper suffix of a
   383  // path. The go tool's usual package mechanism does not apply: package path
   384  // elements like . and ... are not implemented by go doc.
   385  //
   386  // When run with two arguments, the first is a package path (full path or suffix),
   387  // and the second is a symbol, or symbol with method or struct field:
   388  //
   389  //	go doc <pkg> <sym>[.<methodOrField>]
   390  //
   391  // In all forms, when matching symbols, lower-case letters in the argument match
   392  // either case but upper-case letters match exactly. This means that there may be
   393  // multiple matches of a lower-case argument in a package if different symbols have
   394  // different cases. If this occurs, documentation for all matches is printed.
   395  //
   396  // Examples:
   397  //
   398  //	go doc
   399  //		Show documentation for current package.
   400  //	go doc Foo
   401  //		Show documentation for Foo in the current package.
   402  //		(Foo starts with a capital letter so it cannot match
   403  //		a package path.)
   404  //	go doc encoding/json
   405  //		Show documentation for the encoding/json package.
   406  //	go doc json
   407  //		Shorthand for encoding/json.
   408  //	go doc json.Number (or go doc json.number)
   409  //		Show documentation and method summary for json.Number.
   410  //	go doc json.Number.Int64 (or go doc json.number.int64)
   411  //		Show documentation for json.Number's Int64 method.
   412  //	go doc cmd/doc
   413  //		Show package docs for the doc command.
   414  //	go doc -cmd cmd/doc
   415  //		Show package docs and exported symbols within the doc command.
   416  //	go doc template.new
   417  //		Show documentation for html/template's New function.
   418  //		(html/template is lexically before text/template)
   419  //	go doc text/template.new # One argument
   420  //		Show documentation for text/template's New function.
   421  //	go doc text/template new # Two arguments
   422  //		Show documentation for text/template's New function.
   423  //
   424  //	At least in the current tree, these invocations all print the
   425  //	documentation for json.Decoder's Decode method:
   426  //
   427  //	go doc json.Decoder.Decode
   428  //	go doc json.decoder.decode
   429  //	go doc json.decode
   430  //	cd go/src/encoding/json; go doc decode
   431  //
   432  // Flags:
   433  //
   434  //	-all
   435  //		Show all the documentation for the package.
   436  //	-c
   437  //		Respect case when matching symbols.
   438  //	-cmd
   439  //		Treat a command (package gocmd) like a regular package.
   440  //		Otherwise package gocmd's exported symbols are hidden
   441  //		when showing the package's top-level documentation.
   442  //	-short
   443  //		One-line representation for each symbol.
   444  //	-src
   445  //		Show the full source code for the symbol. This will
   446  //		display the full Go source of its declaration and
   447  //		definition, such as a function definition (including
   448  //		the body), type declaration or enclosing const
   449  //		block. The output may therefore include unexported
   450  //		details.
   451  //	-u
   452  //		Show documentation for unexported as well as exported
   453  //		symbols, methods, and fields.
   454  //
   455  // # Print Go environment information
   456  //
   457  // Usage:
   458  //
   459  //	go env [-json] [-u] [-w] [var ...]
   460  //
   461  // Env prints Go environment information.
   462  //
   463  // By default env prints information as a shell script
   464  // (on Windows, a batch file). If one or more variable
   465  // names is given as arguments, env prints the value of
   466  // each named variable on its own line.
   467  //
   468  // The -json flag prints the environment in JSON format
   469  // instead of as a shell script.
   470  //
   471  // The -u flag requires one or more arguments and unsets
   472  // the default setting for the named environment variables,
   473  // if one has been set with 'go env -w'.
   474  //
   475  // The -w flag requires one or more arguments of the
   476  // form NAME=VALUE and changes the default settings
   477  // of the named environment variables to the given values.
   478  //
   479  // For more about environment variables, see 'go help environment'.
   480  //
   481  // # Update packages to use new APIs
   482  //
   483  // Usage:
   484  //
   485  //	go fix [-fix list] [packages]
   486  //
   487  // Fix runs the Go fix command on the packages named by the import paths.
   488  //
   489  // The -fix flag sets a comma-separated list of fixes to run.
   490  // The default is all known fixes.
   491  // (Its value is passed to 'go tool fix -r'.)
   492  //
   493  // For more about fix, see 'go doc cmd/fix'.
   494  // For more about specifying packages, see 'go help packages'.
   495  //
   496  // To run fix with other options, run 'go tool fix'.
   497  //
   498  // See also: go fmt, go vet.
   499  //
   500  // # Gofmt (reformat) package sources
   501  //
   502  // Usage:
   503  //
   504  //	go fmt [-n] [-x] [packages]
   505  //
   506  // Fmt runs the command 'gofmt -l -w' on the packages named
   507  // by the import paths. It prints the names of the files that are modified.
   508  //
   509  // For more about gofmt, see 'go doc cmd/gofmt'.
   510  // For more about specifying packages, see 'go help packages'.
   511  //
   512  // The -n flag prints commands that would be executed.
   513  // The -x flag prints commands as they are executed.
   514  //
   515  // The -mod flag's value sets which module download mode
   516  // to use: readonly or vendor. See 'go help modules' for more.
   517  //
   518  // To run gofmt with specific options, run gofmt itself.
   519  //
   520  // See also: go fix, go vet.
   521  //
   522  // # Generate Go files by processing source
   523  //
   524  // Usage:
   525  //
   526  //	go generate [-run regexp] [-n] [-v] [-x] [build flags] [file.go... | packages]
   527  //
   528  // Generate runs commands described by directives within existing
   529  // files. Those commands can run any process but the intent is to
   530  // create or update Go source files.
   531  //
   532  // Go generate is never run automatically by go build, go test,
   533  // and so on. It must be run explicitly.
   534  //
   535  // Go generate scans the file for directives, which are lines of
   536  // the form,
   537  //
   538  //	//go:generate command argument...
   539  //
   540  // (note: no leading spaces and no space in "//go") where command
   541  // is the generator to be run, corresponding to an executable file
   542  // that can be run locally. It must either be in the shell path
   543  // (gofmt), a fully qualified path (/usr/you/bin/mytool), or a
   544  // command alias, described below.
   545  //
   546  // Note that go generate does not parse the file, so lines that look
   547  // like directives in comments or multiline strings will be treated
   548  // as directives.
   549  //
   550  // The arguments to the directive are space-separated tokens or
   551  // double-quoted strings passed to the generator as individual
   552  // arguments when it is run.
   553  //
   554  // Quoted strings use Go syntax and are evaluated before execution; a
   555  // quoted string appears as a single argument to the generator.
   556  //
   557  // To convey to humans and machine tools that code is generated,
   558  // generated source should have a line that matches the following
   559  // regular expression (in Go syntax):
   560  //
   561  //	^// Code generated .* DO NOT EDIT\.$
   562  //
   563  // This line must appear before the first non-comment, non-blank
   564  // text in the file.
   565  //
   566  // Go generate sets several variables when it runs the generator:
   567  //
   568  //	$GOARCH
   569  //		The execution architecture (arm, amd64, etc.)
   570  //	$GOOS
   571  //		The execution operating system (linux, windows, etc.)
   572  //	$GOFILE
   573  //		The base name of the file.
   574  //	$GOLINE
   575  //		The line number of the directive in the source file.
   576  //	$GOPACKAGE
   577  //		The name of the package of the file containing the directive.
   578  //	$GOROOT
   579  //		The GOROOT directory for the 'go' command that invoked the
   580  //		generator, containing the Go toolchain and standard library.
   581  //	$DOLLAR
   582  //		A dollar sign.
   583  //	$PATH
   584  //		The $PATH of the parent process, with $GOROOT/bin
   585  //		placed at the beginning. This causes generators
   586  //		that execute 'go' commands to use the same 'go'
   587  //		as the parent 'go generate' command.
   588  //
   589  // Other than variable substitution and quoted-string evaluation, no
   590  // special processing such as "globbing" is performed on the command
   591  // line.
   592  //
   593  // As a last step before running the command, any invocations of any
   594  // environment variables with alphanumeric names, such as $GOFILE or
   595  // $HOME, are expanded throughout the command line. The syntax for
   596  // variable expansion is $NAME on all operating systems. Due to the
   597  // order of evaluation, variables are expanded even inside quoted
   598  // strings. If the variable NAME is not set, $NAME expands to the
   599  // empty string.
   600  //
   601  // A directive of the form,
   602  //
   603  //	//go:generate -command xxx args...
   604  //
   605  // specifies, for the remainder of this source file only, that the
   606  // string xxx represents the command identified by the arguments. This
   607  // can be used to create aliases or to handle multiword generators.
   608  // For example,
   609  //
   610  //	//go:generate -command foo go tool foo
   611  //
   612  // specifies that the command "foo" represents the generator
   613  // "go tool foo".
   614  //
   615  // Generate processes packages in the order given on the command line,
   616  // one at a time. If the command line lists .go files from a single directory,
   617  // they are treated as a single package. Within a package, generate processes the
   618  // source files in a package in file name order, one at a time. Within
   619  // a source file, generate runs generators in the order they appear
   620  // in the file, one at a time. The go generate tool also sets the build
   621  // tag "generate" so that files may be examined by go generate but ignored
   622  // during build.
   623  //
   624  // For packages with invalid code, generate processes only source files with a
   625  // valid package clause.
   626  //
   627  // If any generator returns an error exit status, "go generate" skips
   628  // all further processing for that package.
   629  //
   630  // The generator is run in the package's source directory.
   631  //
   632  // Go generate accepts two specific flags:
   633  //
   634  //	-run=""
   635  //		if non-empty, specifies a regular expression to select
   636  //		directives whose full original source text (excluding
   637  //		any trailing spaces and final newline) matches the
   638  //		expression.
   639  //
   640  //	-skip=""
   641  //		if non-empty, specifies a regular expression to suppress
   642  //		directives whose full original source text (excluding
   643  //		any trailing spaces and final newline) matches the
   644  //		expression. If a directive matches both the -run and
   645  //		the -skip arguments, it is skipped.
   646  //
   647  // It also accepts the standard build flags including -v, -n, and -x.
   648  // The -v flag prints the names of packages and files as they are
   649  // processed.
   650  // The -n flag prints commands that would be executed.
   651  // The -x flag prints commands as they are executed.
   652  //
   653  // For more about build flags, see 'go help build'.
   654  //
   655  // For more about specifying packages, see 'go help packages'.
   656  //
   657  // # Add dependencies to current module and install them
   658  //
   659  // Usage:
   660  //
   661  //	go get [-t] [-u] [-v] [build flags] [packages]
   662  //
   663  // Get resolves its command-line arguments to packages at specific module versions,
   664  // updates go.mod to require those versions, and downloads source code into the
   665  // module cache.
   666  //
   667  // To add a dependency for a package or upgrade it to its latest version:
   668  //
   669  //	go get example.com/pkg
   670  //
   671  // To upgrade or downgrade a package to a specific version:
   672  //
   673  //	go get example.com/pkg@v1.2.3
   674  //
   675  // To remove a dependency on a module and downgrade modules that require it:
   676  //
   677  //	go get example.com/mod@none
   678  //
   679  // To upgrade the minimum required Go version to the latest released Go version:
   680  //
   681  //	go get go@latest
   682  //
   683  // To upgrade the Go toolchain to the latest patch release of the current Go toolchain:
   684  //
   685  //	go get toolchain@patch
   686  //
   687  // See https://golang.org/ref/mod#go-get for details.
   688  //
   689  // In earlier versions of Go, 'go get' was used to build and install packages.
   690  // Now, 'go get' is dedicated to adjusting dependencies in go.mod. 'go install'
   691  // may be used to build and install commands instead. When a version is specified,
   692  // 'go install' runs in module-aware mode and ignores the go.mod file in the
   693  // current directory. For example:
   694  //
   695  //	go install example.com/pkg@v1.2.3
   696  //	go install example.com/pkg@latest
   697  //
   698  // See 'go help install' or https://golang.org/ref/mod#go-install for details.
   699  //
   700  // 'go get' accepts the following flags.
   701  //
   702  // The -t flag instructs get to consider modules needed to build tests of
   703  // packages specified on the command line.
   704  //
   705  // The -u flag instructs get to update modules providing dependencies
   706  // of packages named on the command line to use newer minor or patch
   707  // releases when available.
   708  //
   709  // The -u=patch flag (not -u patch) also instructs get to update dependencies,
   710  // but changes the default to select patch releases.
   711  //
   712  // When the -t and -u flags are used together, get will update
   713  // test dependencies as well.
   714  //
   715  // The -x flag prints commands as they are executed. This is useful for
   716  // debugging version control commands when a module is downloaded directly
   717  // from a repository.
   718  //
   719  // For more about modules, see https://golang.org/ref/mod.
   720  //
   721  // For more about using 'go get' to update the minimum Go version and
   722  // suggested Go toolchain, see https://go.dev/doc/toolchain.
   723  //
   724  // For more about specifying packages, see 'go help packages'.
   725  //
   726  // This text describes the behavior of get using modules to manage source
   727  // code and dependencies. If instead the go command is running in GOPATH
   728  // mode, the details of get's flags and effects change, as does 'go help get'.
   729  // See 'go help gopath-get'.
   730  //
   731  // See also: go build, go install, go clean, go mod.
   732  //
   733  // # Compile and install packages and dependencies
   734  //
   735  // Usage:
   736  //
   737  //	go install [build flags] [packages]
   738  //
   739  // Install compiles and installs the packages named by the import paths.
   740  //
   741  // Executables are installed in the directory named by the GOBIN environment
   742  // variable, which defaults to $GOPATH/bin or $HOME/go/bin if the GOPATH
   743  // environment variable is not set. Executables in $GOROOT
   744  // are installed in $GOROOT/bin or $GOTOOLDIR instead of $GOBIN.
   745  //
   746  // If the arguments have version suffixes (like @latest or @v1.0.0), "go install"
   747  // builds packages in module-aware mode, ignoring the go.mod file in the current
   748  // directory or any parent directory, if there is one. This is useful for
   749  // installing executables without affecting the dependencies of the main module.
   750  // To eliminate ambiguity about which module versions are used in the build, the
   751  // arguments must satisfy the following constraints:
   752  //
   753  // - Arguments must be package paths or package patterns (with "..." wildcards).
   754  // They must not be standard packages (like fmt), meta-patterns (std, cmd,
   755  // all), or relative or absolute file paths.
   756  //
   757  // - All arguments must have the same version suffix. Different queries are not
   758  // allowed, even if they refer to the same version.
   759  //
   760  // - All arguments must refer to packages in the same module at the same version.
   761  //
   762  // - Package path arguments must refer to main packages. Pattern arguments
   763  // will only match main packages.
   764  //
   765  // - No module is considered the "main" module. If the module containing
   766  // packages named on the command line has a go.mod file, it must not contain
   767  // directives (replace and exclude) that would cause it to be interpreted
   768  // differently than if it were the main module. The module must not require
   769  // a higher version of itself.
   770  //
   771  // - Vendor directories are not used in any module. (Vendor directories are not
   772  // included in the module zip files downloaded by 'go install'.)
   773  //
   774  // If the arguments don't have version suffixes, "go install" may run in
   775  // module-aware mode or GOPATH mode, depending on the GO111MODULE environment
   776  // variable and the presence of a go.mod file. See 'go help modules' for details.
   777  // If module-aware mode is enabled, "go install" runs in the context of the main
   778  // module.
   779  //
   780  // When module-aware mode is disabled, non-main packages are installed in the
   781  // directory $GOPATH/pkg/$GOOS_$GOARCH. When module-aware mode is enabled,
   782  // non-main packages are built and cached but not installed.
   783  //
   784  // Before Go 1.20, the standard library was installed to
   785  // $GOROOT/pkg/$GOOS_$GOARCH.
   786  // Starting in Go 1.20, the standard library is built and cached but not installed.
   787  // Setting GODEBUG=installgoroot=all restores the use of
   788  // $GOROOT/pkg/$GOOS_$GOARCH.
   789  //
   790  // For more about build flags, see 'go help build'.
   791  //
   792  // For more about specifying packages, see 'go help packages'.
   793  //
   794  // See also: go build, go get, go clean.
   795  //
   796  // # List packages or modules
   797  //
   798  // Usage:
   799  //
   800  //	go list [-f format] [-json] [-m] [list flags] [build flags] [packages]
   801  //
   802  // List lists the named packages, one per line.
   803  // The most commonly-used flags are -f and -json, which control the form
   804  // of the output printed for each package. Other list flags, documented below,
   805  // control more specific details.
   806  //
   807  // The default output shows the package import path:
   808  //
   809  //	bytes
   810  //	encoding/json
   811  //	github.com/gorilla/mux
   812  //	golang.org/x/net/html
   813  //
   814  // The -f flag specifies an alternate format for the list, using the
   815  // syntax of package template. The default output is equivalent
   816  // to -f '{{.ImportPath}}'. The struct being passed to the template is:
   817  //
   818  //	type Package struct {
   819  //	    Dir            string   // directory containing package sources
   820  //	    ImportPath     string   // import path of package in dir
   821  //	    ImportComment  string   // path in import comment on package statement
   822  //	    Name           string   // package name
   823  //	    Doc            string   // package documentation string
   824  //	    Target         string   // install path
   825  //	    Shlib          string   // the shared library that contains this package (only set when -linkshared)
   826  //	    Goroot         bool     // is this package in the Go root?
   827  //	    Standard       bool     // is this package part of the standard Go library?
   828  //	    Stale          bool     // would 'go install' do anything for this package?
   829  //	    StaleReason    string   // explanation for Stale==true
   830  //	    Root           string   // Go root or Go path dir containing this package
   831  //	    ConflictDir    string   // this directory shadows Dir in $GOPATH
   832  //	    BinaryOnly     bool     // binary-only package (no longer supported)
   833  //	    ForTest        string   // package is only for use in named test
   834  //	    Export         string   // file containing export data (when using -export)
   835  //	    BuildID        string   // build ID of the compiled package (when using -export)
   836  //	    Module         *Module  // info about package's containing module, if any (can be nil)
   837  //	    Match          []string // command-line patterns matching this package
   838  //	    DepOnly        bool     // package is only a dependency, not explicitly listed
   839  //	    DefaultGODEBUG string  // default GODEBUG setting, for main packages
   840  //
   841  //	    // Source files
   842  //	    GoFiles           []string   // .go source files (excluding CgoFiles, TestGoFiles, XTestGoFiles)
   843  //	    CgoFiles          []string   // .go source files that import "C"
   844  //	    CompiledGoFiles   []string   // .go files presented to compiler (when using -compiled)
   845  //	    IgnoredGoFiles    []string   // .go source files ignored due to build constraints
   846  //	    IgnoredOtherFiles []string // non-.go source files ignored due to build constraints
   847  //	    CFiles            []string   // .c source files
   848  //	    CXXFiles          []string   // .cc, .cxx and .cpp source files
   849  //	    MFiles            []string   // .m source files
   850  //	    HFiles            []string   // .h, .hh, .hpp and .hxx source files
   851  //	    FFiles            []string   // .f, .F, .for and .f90 Fortran source files
   852  //	    SFiles            []string   // .s source files
   853  //	    SwigFiles         []string   // .swig files
   854  //	    SwigCXXFiles      []string   // .swigcxx files
   855  //	    SysoFiles         []string   // .syso object files to add to archive
   856  //	    TestGoFiles       []string   // _test.go files in package
   857  //	    XTestGoFiles      []string   // _test.go files outside package
   858  //
   859  //	    // Embedded files
   860  //	    EmbedPatterns      []string // //go:embed patterns
   861  //	    EmbedFiles         []string // files matched by EmbedPatterns
   862  //	    TestEmbedPatterns  []string // //go:embed patterns in TestGoFiles
   863  //	    TestEmbedFiles     []string // files matched by TestEmbedPatterns
   864  //	    XTestEmbedPatterns []string // //go:embed patterns in XTestGoFiles
   865  //	    XTestEmbedFiles    []string // files matched by XTestEmbedPatterns
   866  //
   867  //	    // Cgo directives
   868  //	    CgoCFLAGS    []string // cgo: flags for C compiler
   869  //	    CgoCPPFLAGS  []string // cgo: flags for C preprocessor
   870  //	    CgoCXXFLAGS  []string // cgo: flags for C++ compiler
   871  //	    CgoFFLAGS    []string // cgo: flags for Fortran compiler
   872  //	    CgoLDFLAGS   []string // cgo: flags for linker
   873  //	    CgoPkgConfig []string // cgo: pkg-config names
   874  //
   875  //	    // Dependency information
   876  //	    Imports      []string          // import paths used by this package
   877  //	    ImportMap    map[string]string // map from source import to ImportPath (identity entries omitted)
   878  //	    Deps         []string          // all (recursively) imported dependencies
   879  //	    TestImports  []string          // imports from TestGoFiles
   880  //	    XTestImports []string          // imports from XTestGoFiles
   881  //
   882  //	    // Error information
   883  //	    Incomplete bool            // this package or a dependency has an error
   884  //	    Error      *PackageError   // error loading package
   885  //	    DepsErrors []*PackageError // errors loading dependencies
   886  //	}
   887  //
   888  // Packages stored in vendor directories report an ImportPath that includes the
   889  // path to the vendor directory (for example, "d/vendor/p" instead of "p"),
   890  // so that the ImportPath uniquely identifies a given copy of a package.
   891  // The Imports, Deps, TestImports, and XTestImports lists also contain these
   892  // expanded import paths. See golang.org/s/go15vendor for more about vendoring.
   893  //
   894  // The error information, if any, is
   895  //
   896  //	type PackageError struct {
   897  //	    ImportStack   []string // shortest path from package named on command line to this one
   898  //	    Pos           string   // position of error (if present, file:line:col)
   899  //	    Err           string   // the error itself
   900  //	}
   901  //
   902  // The module information is a Module struct, defined in the discussion
   903  // of list -m below.
   904  //
   905  // The template function "join" calls strings.Join.
   906  //
   907  // The template function "context" returns the build context, defined as:
   908  //
   909  //	type Context struct {
   910  //	    GOARCH        string   // target architecture
   911  //	    GOOS          string   // target operating system
   912  //	    GOROOT        string   // Go root
   913  //	    GOPATH        string   // Go path
   914  //	    CgoEnabled    bool     // whether cgo can be used
   915  //	    UseAllFiles   bool     // use files regardless of //go:build lines, file names
   916  //	    Compiler      string   // compiler to assume when computing target paths
   917  //	    BuildTags     []string // build constraints to match in //go:build lines
   918  //	    ToolTags      []string // toolchain-specific build constraints
   919  //	    ReleaseTags   []string // releases the current release is compatible with
   920  //	    InstallSuffix string   // suffix to use in the name of the install dir
   921  //	}
   922  //
   923  // For more information about the meaning of these fields see the documentation
   924  // for the go/build package's Context type.
   925  //
   926  // The -json flag causes the package data to be printed in JSON format
   927  // instead of using the template format. The JSON flag can optionally be
   928  // provided with a set of comma-separated required field names to be output.
   929  // If so, those required fields will always appear in JSON output, but
   930  // others may be omitted to save work in computing the JSON struct.
   931  //
   932  // The -compiled flag causes list to set CompiledGoFiles to the Go source
   933  // files presented to the compiler. Typically this means that it repeats
   934  // the files listed in GoFiles and then also adds the Go code generated
   935  // by processing CgoFiles and SwigFiles. The Imports list contains the
   936  // union of all imports from both GoFiles and CompiledGoFiles.
   937  //
   938  // The -deps flag causes list to iterate over not just the named packages
   939  // but also all their dependencies. It visits them in a depth-first post-order
   940  // traversal, so that a package is listed only after all its dependencies.
   941  // Packages not explicitly listed on the command line will have the DepOnly
   942  // field set to true.
   943  //
   944  // The -e flag changes the handling of erroneous packages, those that
   945  // cannot be found or are malformed. By default, the list command
   946  // prints an error to standard error for each erroneous package and
   947  // omits the packages from consideration during the usual printing.
   948  // With the -e flag, the list command never prints errors to standard
   949  // error and instead processes the erroneous packages with the usual
   950  // printing. Erroneous packages will have a non-empty ImportPath and
   951  // a non-nil Error field; other information may or may not be missing
   952  // (zeroed).
   953  //
   954  // The -export flag causes list to set the Export field to the name of a
   955  // file containing up-to-date export information for the given package,
   956  // and the BuildID field to the build ID of the compiled package.
   957  //
   958  // The -find flag causes list to identify the named packages but not
   959  // resolve their dependencies: the Imports and Deps lists will be empty.
   960  // With the -find flag, the -deps, -test and -export commands cannot be
   961  // used.
   962  //
   963  // The -test flag causes list to report not only the named packages
   964  // but also their test binaries (for packages with tests), to convey to
   965  // source code analysis tools exactly how test binaries are constructed.
   966  // The reported import path for a test binary is the import path of
   967  // the package followed by a ".test" suffix, as in "math/rand.test".
   968  // When building a test, it is sometimes necessary to rebuild certain
   969  // dependencies specially for that test (most commonly the tested
   970  // package itself). The reported import path of a package recompiled
   971  // for a particular test binary is followed by a space and the name of
   972  // the test binary in brackets, as in "math/rand [math/rand.test]"
   973  // or "regexp [sort.test]". The ForTest field is also set to the name
   974  // of the package being tested ("math/rand" or "sort" in the previous
   975  // examples).
   976  //
   977  // The Dir, Target, Shlib, Root, ConflictDir, and Export file paths
   978  // are all absolute paths.
   979  //
   980  // By default, the lists GoFiles, CgoFiles, and so on hold names of files in Dir
   981  // (that is, paths relative to Dir, not absolute paths).
   982  // The generated files added when using the -compiled and -test flags
   983  // are absolute paths referring to cached copies of generated Go source files.
   984  // Although they are Go source files, the paths may not end in ".go".
   985  //
   986  // The -m flag causes list to list modules instead of packages.
   987  //
   988  // When listing modules, the -f flag still specifies a format template
   989  // applied to a Go struct, but now a Module struct:
   990  //
   991  //	type Module struct {
   992  //	    Path       string        // module path
   993  //	    Query      string        // version query corresponding to this version
   994  //	    Version    string        // module version
   995  //	    Versions   []string      // available module versions
   996  //	    Replace    *Module       // replaced by this module
   997  //	    Time       *time.Time    // time version was created
   998  //	    Update     *Module       // available update (with -u)
   999  //	    Main       bool          // is this the main module?
  1000  //	    Indirect   bool          // module is only indirectly needed by main module
  1001  //	    Dir        string        // directory holding local copy of files, if any
  1002  //	    GoMod      string        // path to go.mod file describing module, if any
  1003  //	    GoVersion  string        // go version used in module
  1004  //	    Retracted  []string      // retraction information, if any (with -retracted or -u)
  1005  //	    Deprecated string        // deprecation message, if any (with -u)
  1006  //	    Error      *ModuleError  // error loading module
  1007  //	    Origin     any           // provenance of module
  1008  //	    Reuse      bool          // reuse of old module info is safe
  1009  //	}
  1010  //
  1011  //	type ModuleError struct {
  1012  //	    Err string // the error itself
  1013  //	}
  1014  //
  1015  // The file GoMod refers to may be outside the module directory if the
  1016  // module is in the module cache or if the -modfile flag is used.
  1017  //
  1018  // The default output is to print the module path and then
  1019  // information about the version and replacement if any.
  1020  // For example, 'go list -m all' might print:
  1021  //
  1022  //	my/main/module
  1023  //	golang.org/x/text v0.3.0 => /tmp/text
  1024  //	rsc.io/pdf v0.1.1
  1025  //
  1026  // The Module struct has a String method that formats this
  1027  // line of output, so that the default format is equivalent
  1028  // to -f '{{.String}}'.
  1029  //
  1030  // Note that when a module has been replaced, its Replace field
  1031  // describes the replacement module, and its Dir field is set to
  1032  // the replacement's source code, if present. (That is, if Replace
  1033  // is non-nil, then Dir is set to Replace.Dir, with no access to
  1034  // the replaced source code.)
  1035  //
  1036  // The -u flag adds information about available upgrades.
  1037  // When the latest version of a given module is newer than
  1038  // the current one, list -u sets the Module's Update field
  1039  // to information about the newer module. list -u will also set
  1040  // the module's Retracted field if the current version is retracted.
  1041  // The Module's String method indicates an available upgrade by
  1042  // formatting the newer version in brackets after the current version.
  1043  // If a version is retracted, the string "(retracted)" will follow it.
  1044  // For example, 'go list -m -u all' might print:
  1045  //
  1046  //	my/main/module
  1047  //	golang.org/x/text v0.3.0 [v0.4.0] => /tmp/text
  1048  //	rsc.io/pdf v0.1.1 (retracted) [v0.1.2]
  1049  //
  1050  // (For tools, 'go list -m -u -json all' may be more convenient to parse.)
  1051  //
  1052  // The -versions flag causes list to set the Module's Versions field
  1053  // to a list of all known versions of that module, ordered according
  1054  // to semantic versioning, earliest to latest. The flag also changes
  1055  // the default output format to display the module path followed by the
  1056  // space-separated version list.
  1057  //
  1058  // The -retracted flag causes list to report information about retracted
  1059  // module versions. When -retracted is used with -f or -json, the Retracted
  1060  // field will be set to a string explaining why the version was retracted.
  1061  // The string is taken from comments on the retract directive in the
  1062  // module's go.mod file. When -retracted is used with -versions, retracted
  1063  // versions are listed together with unretracted versions. The -retracted
  1064  // flag may be used with or without -m.
  1065  //
  1066  // The arguments to list -m are interpreted as a list of modules, not packages.
  1067  // The main module is the module containing the current directory.
  1068  // The active modules are the main module and its dependencies.
  1069  // With no arguments, list -m shows the main module.
  1070  // With arguments, list -m shows the modules specified by the arguments.
  1071  // Any of the active modules can be specified by its module path.
  1072  // The special pattern "all" specifies all the active modules, first the main
  1073  // module and then dependencies sorted by module path.
  1074  // A pattern containing "..." specifies the active modules whose
  1075  // module paths match the pattern.
  1076  // A query of the form path@version specifies the result of that query,
  1077  // which is not limited to active modules.
  1078  // See 'go help modules' for more about module queries.
  1079  //
  1080  // The template function "module" takes a single string argument
  1081  // that must be a module path or query and returns the specified
  1082  // module as a Module struct. If an error occurs, the result will
  1083  // be a Module struct with a non-nil Error field.
  1084  //
  1085  // When using -m, the -reuse=old.json flag accepts the name of file containing
  1086  // the JSON output of a previous 'go list -m -json' invocation with the
  1087  // same set of modifier flags (such as -u, -retracted, and -versions).
  1088  // The go command may use this file to determine that a module is unchanged
  1089  // since the previous invocation and avoid redownloading information about it.
  1090  // Modules that are not redownloaded will be marked in the new output by
  1091  // setting the Reuse field to true. Normally the module cache provides this
  1092  // kind of reuse automatically; the -reuse flag can be useful on systems that
  1093  // do not preserve the module cache.
  1094  //
  1095  // For more about build flags, see 'go help build'.
  1096  //
  1097  // For more about specifying packages, see 'go help packages'.
  1098  //
  1099  // For more about modules, see https://golang.org/ref/mod.
  1100  //
  1101  // # Module maintenance
  1102  //
  1103  // Go mod provides access to operations on modules.
  1104  //
  1105  // Note that support for modules is built into all the go commands,
  1106  // not just 'go mod'. For example, day-to-day adding, removing, upgrading,
  1107  // and downgrading of dependencies should be done using 'go get'.
  1108  // See 'go help modules' for an overview of module functionality.
  1109  //
  1110  // Usage:
  1111  //
  1112  //	go mod <command> [arguments]
  1113  //
  1114  // The commands are:
  1115  //
  1116  //	download    download modules to local cache
  1117  //	edit        edit go.mod from tools or scripts
  1118  //	graph       print module requirement graph
  1119  //	init        initialize new module in current directory
  1120  //	tidy        add missing and remove unused modules
  1121  //	vendor      make vendored copy of dependencies
  1122  //	verify      verify dependencies have expected content
  1123  //	why         explain why packages or modules are needed
  1124  //
  1125  // Use "go help mod <command>" for more information about a command.
  1126  //
  1127  // # Download modules to local cache
  1128  //
  1129  // Usage:
  1130  //
  1131  //	go mod download [-x] [-json] [-reuse=old.json] [modules]
  1132  //
  1133  // Download downloads the named modules, which can be module patterns selecting
  1134  // dependencies of the main module or module queries of the form path@version.
  1135  //
  1136  // With no arguments, download applies to the modules needed to build and test
  1137  // the packages in the main module: the modules explicitly required by the main
  1138  // module if it is at 'go 1.17' or higher, or all transitively-required modules
  1139  // if at 'go 1.16' or lower.
  1140  //
  1141  // The go command will automatically download modules as needed during ordinary
  1142  // execution. The "go mod download" command is useful mainly for pre-filling
  1143  // the local cache or to compute the answers for a Go module proxy.
  1144  //
  1145  // By default, download writes nothing to standard output. It may print progress
  1146  // messages and errors to standard error.
  1147  //
  1148  // The -json flag causes download to print a sequence of JSON objects
  1149  // to standard output, describing each downloaded module (or failure),
  1150  // corresponding to this Go struct:
  1151  //
  1152  //	type Module struct {
  1153  //	    Path     string // module path
  1154  //	    Query    string // version query corresponding to this version
  1155  //	    Version  string // module version
  1156  //	    Error    string // error loading module
  1157  //	    Info     string // absolute path to cached .info file
  1158  //	    GoMod    string // absolute path to cached .mod file
  1159  //	    Zip      string // absolute path to cached .zip file
  1160  //	    Dir      string // absolute path to cached source root directory
  1161  //	    Sum      string // checksum for path, version (as in go.sum)
  1162  //	    GoModSum string // checksum for go.mod (as in go.sum)
  1163  //	    Origin   any    // provenance of module
  1164  //	    Reuse    bool   // reuse of old module info is safe
  1165  //	}
  1166  //
  1167  // The -reuse flag accepts the name of file containing the JSON output of a
  1168  // previous 'go mod download -json' invocation. The go command may use this
  1169  // file to determine that a module is unchanged since the previous invocation
  1170  // and avoid redownloading it. Modules that are not redownloaded will be marked
  1171  // in the new output by setting the Reuse field to true. Normally the module
  1172  // cache provides this kind of reuse automatically; the -reuse flag can be
  1173  // useful on systems that do not preserve the module cache.
  1174  //
  1175  // The -x flag causes download to print the commands download executes.
  1176  //
  1177  // See https://golang.org/ref/mod#go-mod-download for more about 'go mod download'.
  1178  //
  1179  // See https://golang.org/ref/mod#version-queries for more about version queries.
  1180  //
  1181  // # Edit go.mod from tools or scripts
  1182  //
  1183  // Usage:
  1184  //
  1185  //	go mod edit [editing flags] [-fmt|-print|-json] [go.mod]
  1186  //
  1187  // Edit provides a command-line interface for editing go.mod,
  1188  // for use primarily by tools or scripts. It reads only go.mod;
  1189  // it does not look up information about the modules involved.
  1190  // By default, edit reads and writes the go.mod file of the main module,
  1191  // but a different target file can be specified after the editing flags.
  1192  //
  1193  // The editing flags specify a sequence of editing operations.
  1194  //
  1195  // The -fmt flag reformats the go.mod file without making other changes.
  1196  // This reformatting is also implied by any other modifications that use or
  1197  // rewrite the go.mod file. The only time this flag is needed is if no other
  1198  // flags are specified, as in 'go mod edit -fmt'.
  1199  //
  1200  // The -module flag changes the module's path (the go.mod file's module line).
  1201  //
  1202  // The -require=path@version and -droprequire=path flags
  1203  // add and drop a requirement on the given module path and version.
  1204  // Note that -require overrides any existing requirements on path.
  1205  // These flags are mainly for tools that understand the module graph.
  1206  // Users should prefer 'go get path@version' or 'go get path@none',
  1207  // which make other go.mod adjustments as needed to satisfy
  1208  // constraints imposed by other modules.
  1209  //
  1210  // The -exclude=path@version and -dropexclude=path@version flags
  1211  // add and drop an exclusion for the given module path and version.
  1212  // Note that -exclude=path@version is a no-op if that exclusion already exists.
  1213  //
  1214  // The -replace=old[@v]=new[@v] flag adds a replacement of the given
  1215  // module path and version pair. If the @v in old@v is omitted, a
  1216  // replacement without a version on the left side is added, which applies
  1217  // to all versions of the old module path. If the @v in new@v is omitted,
  1218  // the new path should be a local module root directory, not a module
  1219  // path. Note that -replace overrides any redundant replacements for old[@v],
  1220  // so omitting @v will drop existing replacements for specific versions.
  1221  //
  1222  // The -dropreplace=old[@v] flag drops a replacement of the given
  1223  // module path and version pair. If the @v is omitted, a replacement without
  1224  // a version on the left side is dropped.
  1225  //
  1226  // The -retract=version and -dropretract=version flags add and drop a
  1227  // retraction on the given version. The version may be a single version
  1228  // like "v1.2.3" or a closed interval like "[v1.1.0,v1.1.9]". Note that
  1229  // -retract=version is a no-op if that retraction already exists.
  1230  //
  1231  // The -require, -droprequire, -exclude, -dropexclude, -replace,
  1232  // -dropreplace, -retract, and -dropretract editing flags may be repeated,
  1233  // and the changes are applied in the order given.
  1234  //
  1235  // The -go=version flag sets the expected Go language version.
  1236  //
  1237  // The -toolchain=name flag sets the Go toolchain to use.
  1238  //
  1239  // The -print flag prints the final go.mod in its text format instead of
  1240  // writing it back to go.mod.
  1241  //
  1242  // The -json flag prints the final go.mod file in JSON format instead of
  1243  // writing it back to go.mod. The JSON output corresponds to these Go types:
  1244  //
  1245  //	type Module struct {
  1246  //		Path    string
  1247  //		Version string
  1248  //	}
  1249  //
  1250  //	type GoMod struct {
  1251  //		Module    ModPath
  1252  //		Go        string
  1253  //		Toolchain string
  1254  //		Require   []Require
  1255  //		Exclude   []Module
  1256  //		Replace   []Replace
  1257  //		Retract   []Retract
  1258  //	}
  1259  //
  1260  //	type ModPath struct {
  1261  //		Path       string
  1262  //		Deprecated string
  1263  //	}
  1264  //
  1265  //	type Require struct {
  1266  //		Path string
  1267  //		Version string
  1268  //		Indirect bool
  1269  //	}
  1270  //
  1271  //	type Replace struct {
  1272  //		Old Module
  1273  //		New Module
  1274  //	}
  1275  //
  1276  //	type Retract struct {
  1277  //		Low       string
  1278  //		High      string
  1279  //		Rationale string
  1280  //	}
  1281  //
  1282  // Retract entries representing a single version (not an interval) will have
  1283  // the "Low" and "High" fields set to the same value.
  1284  //
  1285  // Note that this only describes the go.mod file itself, not other modules
  1286  // referred to indirectly. For the full set of modules available to a build,
  1287  // use 'go list -m -json all'.
  1288  //
  1289  // Edit also provides the -C, -n, and -x build flags.
  1290  //
  1291  // See https://golang.org/ref/mod#go-mod-edit for more about 'go mod edit'.
  1292  //
  1293  // # Print module requirement graph
  1294  //
  1295  // Usage:
  1296  //
  1297  //	go mod graph [-go=version] [-x]
  1298  //
  1299  // Graph prints the module requirement graph (with replacements applied)
  1300  // in text form. Each line in the output has two space-separated fields: a module
  1301  // and one of its requirements. Each module is identified as a string of the form
  1302  // path@version, except for the main module, which has no @version suffix.
  1303  //
  1304  // The -go flag causes graph to report the module graph as loaded by the
  1305  // given Go version, instead of the version indicated by the 'go' directive
  1306  // in the go.mod file.
  1307  //
  1308  // The -x flag causes graph to print the commands graph executes.
  1309  //
  1310  // See https://golang.org/ref/mod#go-mod-graph for more about 'go mod graph'.
  1311  //
  1312  // # Initialize new module in current directory
  1313  //
  1314  // Usage:
  1315  //
  1316  //	go mod init [module-path]
  1317  //
  1318  // Init initializes and writes a new go.mod file in the current directory, in
  1319  // effect creating a new module rooted at the current directory. The go.mod file
  1320  // must not already exist.
  1321  //
  1322  // Init accepts one optional argument, the module path for the new module. If the
  1323  // module path argument is omitted, init will attempt to infer the module path
  1324  // using import comments in .go files, vendoring tool configuration files (like
  1325  // Gopkg.lock), and the current directory (if in GOPATH).
  1326  //
  1327  // See https://golang.org/ref/mod#go-mod-init for more about 'go mod init'.
  1328  //
  1329  // # Add missing and remove unused modules
  1330  //
  1331  // Usage:
  1332  //
  1333  //	go mod tidy [-e] [-v] [-x] [-go=version] [-compat=version]
  1334  //
  1335  // Tidy makes sure go.mod matches the source code in the module.
  1336  // It adds any missing modules necessary to build the current module's
  1337  // packages and dependencies, and it removes unused modules that
  1338  // don't provide any relevant packages. It also adds any missing entries
  1339  // to go.sum and removes any unnecessary ones.
  1340  //
  1341  // The -v flag causes tidy to print information about removed modules
  1342  // to standard error.
  1343  //
  1344  // The -e flag causes tidy to attempt to proceed despite errors
  1345  // encountered while loading packages.
  1346  //
  1347  // The -go flag causes tidy to update the 'go' directive in the go.mod
  1348  // file to the given version, which may change which module dependencies
  1349  // are retained as explicit requirements in the go.mod file.
  1350  // (Go versions 1.17 and higher retain more requirements in order to
  1351  // support lazy module loading.)
  1352  //
  1353  // The -compat flag preserves any additional checksums needed for the
  1354  // 'go' command from the indicated major Go release to successfully load
  1355  // the module graph, and causes tidy to error out if that version of the
  1356  // 'go' command would load any imported package from a different module
  1357  // version. By default, tidy acts as if the -compat flag were set to the
  1358  // version prior to the one indicated by the 'go' directive in the go.mod
  1359  // file.
  1360  //
  1361  // The -x flag causes tidy to print the commands download executes.
  1362  //
  1363  // See https://golang.org/ref/mod#go-mod-tidy for more about 'go mod tidy'.
  1364  //
  1365  // # Make vendored copy of dependencies
  1366  //
  1367  // Usage:
  1368  //
  1369  //	go mod vendor [-e] [-v] [-o outdir]
  1370  //
  1371  // Vendor resets the main module's vendor directory to include all packages
  1372  // needed to build and test all the main module's packages.
  1373  // It does not include test code for vendored packages.
  1374  //
  1375  // The -v flag causes vendor to print the names of vendored
  1376  // modules and packages to standard error.
  1377  //
  1378  // The -e flag causes vendor to attempt to proceed despite errors
  1379  // encountered while loading packages.
  1380  //
  1381  // The -o flag causes vendor to create the vendor directory at the given
  1382  // path instead of "vendor". The go command can only use a vendor directory
  1383  // named "vendor" within the module root directory, so this flag is
  1384  // primarily useful for other tools.
  1385  //
  1386  // See https://golang.org/ref/mod#go-mod-vendor for more about 'go mod vendor'.
  1387  //
  1388  // # Verify dependencies have expected content
  1389  //
  1390  // Usage:
  1391  //
  1392  //	go mod verify
  1393  //
  1394  // Verify checks that the dependencies of the current module,
  1395  // which are stored in a local downloaded source cache, have not been
  1396  // modified since being downloaded. If all the modules are unmodified,
  1397  // verify prints "all modules verified." Otherwise it reports which
  1398  // modules have been changed and causes 'go mod' to exit with a
  1399  // non-zero status.
  1400  //
  1401  // See https://golang.org/ref/mod#go-mod-verify for more about 'go mod verify'.
  1402  //
  1403  // # Explain why packages or modules are needed
  1404  //
  1405  // Usage:
  1406  //
  1407  //	go mod why [-m] [-vendor] packages...
  1408  //
  1409  // Why shows a shortest path in the import graph from the main module to
  1410  // each of the listed packages. If the -m flag is given, why treats the
  1411  // arguments as a list of modules and finds a path to any package in each
  1412  // of the modules.
  1413  //
  1414  // By default, why queries the graph of packages matched by "go list all",
  1415  // which includes tests for reachable packages. The -vendor flag causes why
  1416  // to exclude tests of dependencies.
  1417  //
  1418  // The output is a sequence of stanzas, one for each package or module
  1419  // name on the command line, separated by blank lines. Each stanza begins
  1420  // with a comment line "# package" or "# module" giving the target
  1421  // package or module. Subsequent lines give a path through the import
  1422  // graph, one package per line. If the package or module is not
  1423  // referenced from the main module, the stanza will display a single
  1424  // parenthesized note indicating that fact.
  1425  //
  1426  // For example:
  1427  //
  1428  //	$ go mod why golang.org/x/text/language golang.org/x/text/encoding
  1429  //	# golang.org/x/text/language
  1430  //	rsc.io/quote
  1431  //	rsc.io/sampler
  1432  //	golang.org/x/text/language
  1433  //
  1434  //	# golang.org/x/text/encoding
  1435  //	(main module does not need package golang.org/x/text/encoding)
  1436  //	$
  1437  //
  1438  // See https://golang.org/ref/mod#go-mod-why for more about 'go mod why'.
  1439  //
  1440  // # Workspace maintenance
  1441  //
  1442  // Work provides access to operations on workspaces.
  1443  //
  1444  // Note that support for workspaces is built into many other commands, not
  1445  // just 'go work'.
  1446  //
  1447  // See 'go help modules' for information about Go's module system of which
  1448  // workspaces are a part.
  1449  //
  1450  // See https://go.dev/ref/mod#workspaces for an in-depth reference on
  1451  // workspaces.
  1452  //
  1453  // See https://go.dev/doc/tutorial/workspaces for an introductory
  1454  // tutorial on workspaces.
  1455  //
  1456  // A workspace is specified by a go.work file that specifies a set of
  1457  // module directories with the "use" directive. These modules are used as
  1458  // root modules by the go command for builds and related operations.  A
  1459  // workspace that does not specify modules to be used cannot be used to do
  1460  // builds from local modules.
  1461  //
  1462  // go.work files are line-oriented. Each line holds a single directive,
  1463  // made up of a keyword followed by arguments. For example:
  1464  //
  1465  //	go 1.18
  1466  //
  1467  //	use ../foo/bar
  1468  //	use ./baz
  1469  //
  1470  //	replace example.com/foo v1.2.3 => example.com/bar v1.4.5
  1471  //
  1472  // The leading keyword can be factored out of adjacent lines to create a block,
  1473  // like in Go imports.
  1474  //
  1475  //	use (
  1476  //	  ../foo/bar
  1477  //	  ./baz
  1478  //	)
  1479  //
  1480  // The use directive specifies a module to be included in the workspace's
  1481  // set of main modules. The argument to the use directive is the directory
  1482  // containing the module's go.mod file.
  1483  //
  1484  // The go directive specifies the version of Go the file was written at. It
  1485  // is possible there may be future changes in the semantics of workspaces
  1486  // that could be controlled by this version, but for now the version
  1487  // specified has no effect.
  1488  //
  1489  // The replace directive has the same syntax as the replace directive in a
  1490  // go.mod file and takes precedence over replaces in go.mod files.  It is
  1491  // primarily intended to override conflicting replaces in different workspace
  1492  // modules.
  1493  //
  1494  // To determine whether the go command is operating in workspace mode, use
  1495  // the "go env GOWORK" command. This will specify the workspace file being
  1496  // used.
  1497  //
  1498  // Usage:
  1499  //
  1500  //	go work <command> [arguments]
  1501  //
  1502  // The commands are:
  1503  //
  1504  //	edit        edit go.work from tools or scripts
  1505  //	init        initialize workspace file
  1506  //	sync        sync workspace build list to modules
  1507  //	use         add modules to workspace file
  1508  //	vendor      make vendored copy of dependencies
  1509  //
  1510  // Use "go help work <command>" for more information about a command.
  1511  //
  1512  // # Edit go.work from tools or scripts
  1513  //
  1514  // Usage:
  1515  //
  1516  //	go work edit [editing flags] [go.work]
  1517  //
  1518  // Edit provides a command-line interface for editing go.work,
  1519  // for use primarily by tools or scripts. It only reads go.work;
  1520  // it does not look up information about the modules involved.
  1521  // If no file is specified, Edit looks for a go.work file in the current
  1522  // directory and its parent directories
  1523  //
  1524  // The editing flags specify a sequence of editing operations.
  1525  //
  1526  // The -fmt flag reformats the go.work file without making other changes.
  1527  // This reformatting is also implied by any other modifications that use or
  1528  // rewrite the go.mod file. The only time this flag is needed is if no other
  1529  // flags are specified, as in 'go work edit -fmt'.
  1530  //
  1531  // The -use=path and -dropuse=path flags
  1532  // add and drop a use directive from the go.work file's set of module directories.
  1533  //
  1534  // The -replace=old[@v]=new[@v] flag adds a replacement of the given
  1535  // module path and version pair. If the @v in old@v is omitted, a
  1536  // replacement without a version on the left side is added, which applies
  1537  // to all versions of the old module path. If the @v in new@v is omitted,
  1538  // the new path should be a local module root directory, not a module
  1539  // path. Note that -replace overrides any redundant replacements for old[@v],
  1540  // so omitting @v will drop existing replacements for specific versions.
  1541  //
  1542  // The -dropreplace=old[@v] flag drops a replacement of the given
  1543  // module path and version pair. If the @v is omitted, a replacement without
  1544  // a version on the left side is dropped.
  1545  //
  1546  // The -use, -dropuse, -replace, and -dropreplace,
  1547  // editing flags may be repeated, and the changes are applied in the order given.
  1548  //
  1549  // The -go=version flag sets the expected Go language version.
  1550  //
  1551  // The -toolchain=name flag sets the Go toolchain to use.
  1552  //
  1553  // The -print flag prints the final go.work in its text format instead of
  1554  // writing it back to go.mod.
  1555  //
  1556  // The -json flag prints the final go.work file in JSON format instead of
  1557  // writing it back to go.mod. The JSON output corresponds to these Go types:
  1558  //
  1559  //	type GoWork struct {
  1560  //		Go        string
  1561  //		Toolchain string
  1562  //		Use       []Use
  1563  //		Replace   []Replace
  1564  //	}
  1565  //
  1566  //	type Use struct {
  1567  //		DiskPath   string
  1568  //		ModulePath string
  1569  //	}
  1570  //
  1571  //	type Replace struct {
  1572  //		Old Module
  1573  //		New Module
  1574  //	}
  1575  //
  1576  //	type Module struct {
  1577  //		Path    string
  1578  //		Version string
  1579  //	}
  1580  //
  1581  // See the workspaces reference at https://go.dev/ref/mod#workspaces
  1582  // for more information.
  1583  //
  1584  // # Initialize workspace file
  1585  //
  1586  // Usage:
  1587  //
  1588  //	go work init [moddirs]
  1589  //
  1590  // Init initializes and writes a new go.work file in the
  1591  // current directory, in effect creating a new workspace at the current
  1592  // directory.
  1593  //
  1594  // go work init optionally accepts paths to the workspace modules as
  1595  // arguments. If the argument is omitted, an empty workspace with no
  1596  // modules will be created.
  1597  //
  1598  // Each argument path is added to a use directive in the go.work file. The
  1599  // current go version will also be listed in the go.work file.
  1600  //
  1601  // See the workspaces reference at https://go.dev/ref/mod#workspaces
  1602  // for more information.
  1603  //
  1604  // # Sync workspace build list to modules
  1605  //
  1606  // Usage:
  1607  //
  1608  //	go work sync
  1609  //
  1610  // Sync syncs the workspace's build list back to the
  1611  // workspace's modules
  1612  //
  1613  // The workspace's build list is the set of versions of all the
  1614  // (transitive) dependency modules used to do builds in the workspace. go
  1615  // work sync generates that build list using the Minimal Version Selection
  1616  // algorithm, and then syncs those versions back to each of modules
  1617  // specified in the workspace (with use directives).
  1618  //
  1619  // The syncing is done by sequentially upgrading each of the dependency
  1620  // modules specified in a workspace module to the version in the build list
  1621  // if the dependency module's version is not already the same as the build
  1622  // list's version. Note that Minimal Version Selection guarantees that the
  1623  // build list's version of each module is always the same or higher than
  1624  // that in each workspace module.
  1625  //
  1626  // See the workspaces reference at https://go.dev/ref/mod#workspaces
  1627  // for more information.
  1628  //
  1629  // # Add modules to workspace file
  1630  //
  1631  // Usage:
  1632  //
  1633  //	go work use [-r] [moddirs]
  1634  //
  1635  // Use provides a command-line interface for adding
  1636  // directories, optionally recursively, to a go.work file.
  1637  //
  1638  // A use directive will be added to the go.work file for each argument
  1639  // directory listed on the command line go.work file, if it exists,
  1640  // or removed from the go.work file if it does not exist.
  1641  // Use fails if any remaining use directives refer to modules that
  1642  // do not exist.
  1643  //
  1644  // Use updates the go line in go.work to specify a version at least as
  1645  // new as all the go lines in the used modules, both preexisting ones
  1646  // and newly added ones. With no arguments, this update is the only
  1647  // thing that go work use does.
  1648  //
  1649  // The -r flag searches recursively for modules in the argument
  1650  // directories, and the use command operates as if each of the directories
  1651  // were specified as arguments: namely, use directives will be added for
  1652  // directories that exist, and removed for directories that do not exist.
  1653  //
  1654  // See the workspaces reference at https://go.dev/ref/mod#workspaces
  1655  // for more information.
  1656  //
  1657  // # Make vendored copy of dependencies
  1658  //
  1659  // Usage:
  1660  //
  1661  //	go work vendor [-e] [-v] [-o outdir]
  1662  //
  1663  // Vendor resets the workspace's vendor directory to include all packages
  1664  // needed to build and test all the workspace's packages.
  1665  // It does not include test code for vendored packages.
  1666  //
  1667  // The -v flag causes vendor to print the names of vendored
  1668  // modules and packages to standard error.
  1669  //
  1670  // The -e flag causes vendor to attempt to proceed despite errors
  1671  // encountered while loading packages.
  1672  //
  1673  // The -o flag causes vendor to create the vendor directory at the given
  1674  // path instead of "vendor". The go command can only use a vendor directory
  1675  // named "vendor" within the module root directory, so this flag is
  1676  // primarily useful for other tools.
  1677  //
  1678  // # Compile and run Go program
  1679  //
  1680  // Usage:
  1681  //
  1682  //	go run [build flags] [-exec xprog] package [arguments...]
  1683  //
  1684  // Run compiles and runs the named main Go package.
  1685  // Typically the package is specified as a list of .go source files from a single
  1686  // directory, but it may also be an import path, file system path, or pattern
  1687  // matching a single known package, as in 'go run .' or 'go run my/cmd'.
  1688  //
  1689  // If the package argument has a version suffix (like @latest or @v1.0.0),
  1690  // "go run" builds the program in module-aware mode, ignoring the go.mod file in
  1691  // the current directory or any parent directory, if there is one. This is useful
  1692  // for running programs without affecting the dependencies of the main module.
  1693  //
  1694  // If the package argument doesn't have a version suffix, "go run" may run in
  1695  // module-aware mode or GOPATH mode, depending on the GO111MODULE environment
  1696  // variable and the presence of a go.mod file. See 'go help modules' for details.
  1697  // If module-aware mode is enabled, "go run" runs in the context of the main
  1698  // module.
  1699  //
  1700  // By default, 'go run' runs the compiled binary directly: 'a.out arguments...'.
  1701  // If the -exec flag is given, 'go run' invokes the binary using xprog:
  1702  //
  1703  //	'xprog a.out arguments...'.
  1704  //
  1705  // If the -exec flag is not given, GOOS or GOARCH is different from the system
  1706  // default, and a program named go_$GOOS_$GOARCH_exec can be found
  1707  // on the current search path, 'go run' invokes the binary using that program,
  1708  // for example 'go_js_wasm_exec a.out arguments...'. This allows execution of
  1709  // cross-compiled programs when a simulator or other execution method is
  1710  // available.
  1711  //
  1712  // By default, 'go run' compiles the binary without generating the information
  1713  // used by debuggers, to reduce build time. To include debugger information in
  1714  // the binary, use 'go build'.
  1715  //
  1716  // The exit status of Run is not the exit status of the compiled binary.
  1717  //
  1718  // For more about build flags, see 'go help build'.
  1719  // For more about specifying packages, see 'go help packages'.
  1720  //
  1721  // See also: go build.
  1722  //
  1723  // # Test packages
  1724  //
  1725  // Usage:
  1726  //
  1727  //	go test [build/test flags] [packages] [build/test flags & test binary flags]
  1728  //
  1729  // 'Go test' automates testing the packages named by the import paths.
  1730  // It prints a summary of the test results in the format:
  1731  //
  1732  //	ok   archive/tar   0.011s
  1733  //	FAIL archive/zip   0.022s
  1734  //	ok   compress/gzip 0.033s
  1735  //	...
  1736  //
  1737  // followed by detailed output for each failed package.
  1738  //
  1739  // 'Go test' recompiles each package along with any files with names matching
  1740  // the file pattern "*_test.go".
  1741  // These additional files can contain test functions, benchmark functions, fuzz
  1742  // tests and example functions. See 'go help testfunc' for more.
  1743  // Each listed package causes the execution of a separate test binary.
  1744  // Files whose names begin with "_" (including "_test.go") or "." are ignored.
  1745  //
  1746  // Test files that declare a package with the suffix "_test" will be compiled as a
  1747  // separate package, and then linked and run with the main test binary.
  1748  //
  1749  // The go tool will ignore a directory named "testdata", making it available
  1750  // to hold ancillary data needed by the tests.
  1751  //
  1752  // As part of building a test binary, go test runs go vet on the package
  1753  // and its test source files to identify significant problems. If go vet
  1754  // finds any problems, go test reports those and does not run the test
  1755  // binary. Only a high-confidence subset of the default go vet checks are
  1756  // used. That subset is: atomic, bool, buildtags, directive, errorsas,
  1757  // ifaceassert, nilfunc, printf, and stringintconv. You can see
  1758  // the documentation for these and other vet tests via "go doc cmd/vet".
  1759  // To disable the running of go vet, use the -vet=off flag. To run all
  1760  // checks, use the -vet=all flag.
  1761  //
  1762  // All test output and summary lines are printed to the go command's
  1763  // standard output, even if the test printed them to its own standard
  1764  // error. (The go command's standard error is reserved for printing
  1765  // errors building the tests.)
  1766  //
  1767  // The go command places $GOROOT/bin at the beginning of $PATH
  1768  // in the test's environment, so that tests that execute
  1769  // 'go' commands use the same 'go' as the parent 'go test' command.
  1770  //
  1771  // Go test runs in two different modes:
  1772  //
  1773  // The first, called local directory mode, occurs when go test is
  1774  // invoked with no package arguments (for example, 'go test' or 'go
  1775  // test -v'). In this mode, go test compiles the package sources and
  1776  // tests found in the current directory and then runs the resulting
  1777  // test binary. In this mode, caching (discussed below) is disabled.
  1778  // After the package test finishes, go test prints a summary line
  1779  // showing the test status ('ok' or 'FAIL'), package name, and elapsed
  1780  // time.
  1781  //
  1782  // The second, called package list mode, occurs when go test is invoked
  1783  // with explicit package arguments (for example 'go test math', 'go
  1784  // test ./...', and even 'go test .'). In this mode, go test compiles
  1785  // and tests each of the packages listed on the command line. If a
  1786  // package test passes, go test prints only the final 'ok' summary
  1787  // line. If a package test fails, go test prints the full test output.
  1788  // If invoked with the -bench or -v flag, go test prints the full
  1789  // output even for passing package tests, in order to display the
  1790  // requested benchmark results or verbose logging. After the package
  1791  // tests for all of the listed packages finish, and their output is
  1792  // printed, go test prints a final 'FAIL' status if any package test
  1793  // has failed.
  1794  //
  1795  // In package list mode only, go test caches successful package test
  1796  // results to avoid unnecessary repeated running of tests. When the
  1797  // result of a test can be recovered from the cache, go test will
  1798  // redisplay the previous output instead of running the test binary
  1799  // again. When this happens, go test prints '(cached)' in place of the
  1800  // elapsed time in the summary line.
  1801  //
  1802  // The rule for a match in the cache is that the run involves the same
  1803  // test binary and the flags on the command line come entirely from a
  1804  // restricted set of 'cacheable' test flags, defined as -benchtime, -cpu,
  1805  // -list, -parallel, -run, -short, -timeout, -failfast, and -v.
  1806  // If a run of go test has any test or non-test flags outside this set,
  1807  // the result is not cached. To disable test caching, use any test flag
  1808  // or argument other than the cacheable flags. The idiomatic way to disable
  1809  // test caching explicitly is to use -count=1. Tests that open files within
  1810  // the package's source root (usually $GOPATH) or that consult environment
  1811  // variables only match future runs in which the files and environment
  1812  // variables are unchanged. A cached test result is treated as executing
  1813  // in no time at all, so a successful package test result will be cached and
  1814  // reused regardless of -timeout setting.
  1815  //
  1816  // In addition to the build flags, the flags handled by 'go test' itself are:
  1817  //
  1818  //	-args
  1819  //	    Pass the remainder of the command line (everything after -args)
  1820  //	    to the test binary, uninterpreted and unchanged.
  1821  //	    Because this flag consumes the remainder of the command line,
  1822  //	    the package list (if present) must appear before this flag.
  1823  //
  1824  //	-c
  1825  //	    Compile the test binary to pkg.test in the current directory but do not run it
  1826  //	    (where pkg is the last element of the package's import path).
  1827  //	    The file name or target directory can be changed with the -o flag.
  1828  //
  1829  //	-exec xprog
  1830  //	    Run the test binary using xprog. The behavior is the same as
  1831  //	    in 'go run'. See 'go help run' for details.
  1832  //
  1833  //	-json
  1834  //	    Convert test output to JSON suitable for automated processing.
  1835  //	    See 'go doc test2json' for the encoding details.
  1836  //
  1837  //	-o file
  1838  //	    Compile the test binary to the named file.
  1839  //	    The test still runs (unless -c or -i is specified).
  1840  //	    If file ends in a slash or names an existing directory,
  1841  //	    the test is written to pkg.test in that directory.
  1842  //
  1843  // The test binary also accepts flags that control execution of the test; these
  1844  // flags are also accessible by 'go test'. See 'go help testflag' for details.
  1845  //
  1846  // For more about build flags, see 'go help build'.
  1847  // For more about specifying packages, see 'go help packages'.
  1848  //
  1849  // See also: go build, go vet.
  1850  //
  1851  // # Run specified go tool
  1852  //
  1853  // Usage:
  1854  //
  1855  //	go tool [-n] command [args...]
  1856  //
  1857  // Tool runs the go tool command identified by the arguments.
  1858  // With no arguments it prints the list of known tools.
  1859  //
  1860  // The -n flag causes tool to print the command that would be
  1861  // executed but not execute it.
  1862  //
  1863  // For more about each tool command, see 'go doc cmd/<command>'.
  1864  //
  1865  // # Print Go version
  1866  //
  1867  // Usage:
  1868  //
  1869  //	go version [-m] [-v] [file ...]
  1870  //
  1871  // Version prints the build information for Go binary files.
  1872  //
  1873  // Go version reports the Go version used to build each of the named files.
  1874  //
  1875  // If no files are named on the command line, go version prints its own
  1876  // version information.
  1877  //
  1878  // If a directory is named, go version walks that directory, recursively,
  1879  // looking for recognized Go binaries and reporting their versions.
  1880  // By default, go version does not report unrecognized files found
  1881  // during a directory scan. The -v flag causes it to report unrecognized files.
  1882  //
  1883  // The -m flag causes go version to print each file's embedded
  1884  // module version information, when available. In the output, the module
  1885  // information consists of multiple lines following the version line, each
  1886  // indented by a leading tab character.
  1887  //
  1888  // See also: go doc runtime/debug.BuildInfo.
  1889  //
  1890  // # Report likely mistakes in packages
  1891  //
  1892  // Usage:
  1893  //
  1894  //	go vet [build flags] [-vettool prog] [vet flags] [packages]
  1895  //
  1896  // Vet runs the Go vet command on the packages named by the import paths.
  1897  //
  1898  // For more about vet and its flags, see 'go doc cmd/vet'.
  1899  // For more about specifying packages, see 'go help packages'.
  1900  // For a list of checkers and their flags, see 'go tool vet help'.
  1901  // For details of a specific checker such as 'printf', see 'go tool vet help printf'.
  1902  //
  1903  // The -vettool=prog flag selects a different analysis tool with alternative
  1904  // or additional checks.
  1905  // For example, the 'shadow' analyzer can be built and run using these commands:
  1906  //
  1907  //	go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow@latest
  1908  //	go vet -vettool=$(which shadow)
  1909  //
  1910  // The build flags supported by go vet are those that control package resolution
  1911  // and execution, such as -C, -n, -x, -v, -tags, and -toolexec.
  1912  // For more about these flags, see 'go help build'.
  1913  //
  1914  // See also: go fmt, go fix.
  1915  //
  1916  // # Build constraints
  1917  //
  1918  // A build constraint, also known as a build tag, is a condition under which a
  1919  // file should be included in the package. Build constraints are given by a
  1920  // line comment that begins
  1921  //
  1922  //	//go:build
  1923  //
  1924  // Constraints may appear in any kind of source file (not just Go), but
  1925  // they must appear near the top of the file, preceded
  1926  // only by blank lines and other comments. These rules mean that in Go
  1927  // files a build constraint must appear before the package clause.
  1928  //
  1929  // To distinguish build constraints from package documentation,
  1930  // a build constraint should be followed by a blank line.
  1931  //
  1932  // A build constraint comment is evaluated as an expression containing
  1933  // build tags combined by ||, &&, and ! operators and parentheses.
  1934  // Operators have the same meaning as in Go.
  1935  //
  1936  // For example, the following build constraint constrains a file to
  1937  // build when the "linux" and "386" constraints are satisfied, or when
  1938  // "darwin" is satisfied and "cgo" is not:
  1939  //
  1940  //	//go:build (linux && 386) || (darwin && !cgo)
  1941  //
  1942  // It is an error for a file to have more than one //go:build line.
  1943  //
  1944  // During a particular build, the following build tags are satisfied:
  1945  //
  1946  //   - the target operating system, as spelled by runtime.GOOS, set with the
  1947  //     GOOS environment variable.
  1948  //   - the target architecture, as spelled by runtime.GOARCH, set with the
  1949  //     GOARCH environment variable.
  1950  //   - any architecture features, in the form GOARCH.feature
  1951  //     (for example, "amd64.v2"), as detailed below.
  1952  //   - "unix", if GOOS is a Unix or Unix-like system.
  1953  //   - the compiler being used, either "gc" or "gccgo"
  1954  //   - "cgo", if the cgo command is supported (see CGO_ENABLED in
  1955  //     'go help environment').
  1956  //   - a term for each Go major release, through the current version:
  1957  //     "go1.1" from Go version 1.1 onward, "go1.12" from Go 1.12, and so on.
  1958  //   - any additional tags given by the -tags flag (see 'go help build').
  1959  //
  1960  // There are no separate build tags for beta or minor releases.
  1961  //
  1962  // If a file's name, after stripping the extension and a possible _test suffix,
  1963  // matches any of the following patterns:
  1964  //
  1965  //	*_GOOS
  1966  //	*_GOARCH
  1967  //	*_GOOS_GOARCH
  1968  //
  1969  // (example: source_windows_amd64.go) where GOOS and GOARCH represent
  1970  // any known operating system and architecture values respectively, then
  1971  // the file is considered to have an implicit build constraint requiring
  1972  // those terms (in addition to any explicit constraints in the file).
  1973  //
  1974  // Using GOOS=android matches build tags and files as for GOOS=linux
  1975  // in addition to android tags and files.
  1976  //
  1977  // Using GOOS=illumos matches build tags and files as for GOOS=solaris
  1978  // in addition to illumos tags and files.
  1979  //
  1980  // Using GOOS=ios matches build tags and files as for GOOS=darwin
  1981  // in addition to ios tags and files.
  1982  //
  1983  // The defined architecture feature build tags are:
  1984  //
  1985  //   - For GOARCH=386, GO386=387 and GO386=sse2
  1986  //     set the 386.387 and 386.sse2 build tags, respectively.
  1987  //   - For GOARCH=amd64, GOAMD64=v1, v2, and v3
  1988  //     correspond to the amd64.v1, amd64.v2, and amd64.v3 feature build tags.
  1989  //   - For GOARCH=arm, GOARM=5, 6, and 7
  1990  //     correspond to the arm.5, arm.6, and arm.7 feature build tags.
  1991  //   - For GOARCH=mips or mipsle,
  1992  //     GOMIPS=hardfloat and softfloat
  1993  //     correspond to the mips.hardfloat and mips.softfloat
  1994  //     (or mipsle.hardfloat and mipsle.softfloat) feature build tags.
  1995  //   - For GOARCH=mips64 or mips64le,
  1996  //     GOMIPS64=hardfloat and softfloat
  1997  //     correspond to the mips64.hardfloat and mips64.softfloat
  1998  //     (or mips64le.hardfloat and mips64le.softfloat) feature build tags.
  1999  //   - For GOARCH=ppc64 or ppc64le,
  2000  //     GOPPC64=power8, power9, and power10 correspond to the
  2001  //     ppc64.power8, ppc64.power9, and ppc64.power10
  2002  //     (or ppc64le.power8, ppc64le.power9, and ppc64le.power10)
  2003  //     feature build tags.
  2004  //   - For GOARCH=wasm, GOWASM=satconv and signext
  2005  //     correspond to the wasm.satconv and wasm.signext feature build tags.
  2006  //
  2007  // For GOARCH=amd64, arm, ppc64, and ppc64le, a particular feature level
  2008  // sets the feature build tags for all previous levels as well.
  2009  // For example, GOAMD64=v2 sets the amd64.v1 and amd64.v2 feature flags.
  2010  // This ensures that code making use of v2 features continues to compile
  2011  // when, say, GOAMD64=v4 is introduced.
  2012  // Code handling the absence of a particular feature level
  2013  // should use a negation:
  2014  //
  2015  //	//go:build !amd64.v2
  2016  //
  2017  // To keep a file from being considered for any build:
  2018  //
  2019  //	//go:build ignore
  2020  //
  2021  // (Any other unsatisfied word will work as well, but "ignore" is conventional.)
  2022  //
  2023  // To build a file only when using cgo, and only on Linux and OS X:
  2024  //
  2025  //	//go:build cgo && (linux || darwin)
  2026  //
  2027  // Such a file is usually paired with another file implementing the
  2028  // default functionality for other systems, which in this case would
  2029  // carry the constraint:
  2030  //
  2031  //	//go:build !(cgo && (linux || darwin))
  2032  //
  2033  // Naming a file dns_windows.go will cause it to be included only when
  2034  // building the package for Windows; similarly, math_386.s will be included
  2035  // only when building the package for 32-bit x86.
  2036  //
  2037  // Go versions 1.16 and earlier used a different syntax for build constraints,
  2038  // with a "// +build" prefix. The gofmt command will add an equivalent //go:build
  2039  // constraint when encountering the older syntax.
  2040  //
  2041  // # Build modes
  2042  //
  2043  // The 'go build' and 'go install' commands take a -buildmode argument which
  2044  // indicates which kind of object file is to be built. Currently supported values
  2045  // are:
  2046  //
  2047  //	-buildmode=archive
  2048  //		Build the listed non-main packages into .a files. Packages named
  2049  //		main are ignored.
  2050  //
  2051  //	-buildmode=c-archive
  2052  //		Build the listed main package, plus all packages it imports,
  2053  //		into a C archive file. The only callable symbols will be those
  2054  //		functions exported using a cgo //export comment. Requires
  2055  //		exactly one main package to be listed.
  2056  //
  2057  //	-buildmode=c-shared
  2058  //		Build the listed main package, plus all packages it imports,
  2059  //		into a C shared library. The only callable symbols will
  2060  //		be those functions exported using a cgo //export comment.
  2061  //		Requires exactly one main package to be listed.
  2062  //
  2063  //	-buildmode=default
  2064  //		Listed main packages are built into executables and listed
  2065  //		non-main packages are built into .a files (the default
  2066  //		behavior).
  2067  //
  2068  //	-buildmode=shared
  2069  //		Combine all the listed non-main packages into a single shared
  2070  //		library that will be used when building with the -linkshared
  2071  //		option. Packages named main are ignored.
  2072  //
  2073  //	-buildmode=exe
  2074  //		Build the listed main packages and everything they import into
  2075  //		executables. Packages not named main are ignored.
  2076  //
  2077  //	-buildmode=pie
  2078  //		Build the listed main packages and everything they import into
  2079  //		position independent executables (PIE). Packages not named
  2080  //		main are ignored.
  2081  //
  2082  //	-buildmode=plugin
  2083  //		Build the listed main packages, plus all packages that they
  2084  //		import, into a Go plugin. Packages not named main are ignored.
  2085  //
  2086  // On AIX, when linking a C program that uses a Go archive built with
  2087  // -buildmode=c-archive, you must pass -Wl,-bnoobjreorder to the C compiler.
  2088  //
  2089  // # Calling between Go and C
  2090  //
  2091  // There are two different ways to call between Go and C/C++ code.
  2092  //
  2093  // The first is the cgo tool, which is part of the Go distribution. For
  2094  // information on how to use it see the cgo documentation (go doc cmd/cgo).
  2095  //
  2096  // The second is the SWIG program, which is a general tool for
  2097  // interfacing between languages. For information on SWIG see
  2098  // http://swig.org/. When running go build, any file with a .swig
  2099  // extension will be passed to SWIG. Any file with a .swigcxx extension
  2100  // will be passed to SWIG with the -c++ option.
  2101  //
  2102  // When either cgo or SWIG is used, go build will pass any .c, .m, .s, .S
  2103  // or .sx files to the C compiler, and any .cc, .cpp, .cxx files to the C++
  2104  // compiler. The CC or CXX environment variables may be set to determine
  2105  // the C or C++ compiler, respectively, to use.
  2106  //
  2107  // # Build and test caching
  2108  //
  2109  // The go command caches build outputs for reuse in future builds.
  2110  // The default location for cache data is a subdirectory named go-build
  2111  // in the standard user cache directory for the current operating system.
  2112  // Setting the GOCACHE environment variable overrides this default,
  2113  // and running 'go env GOCACHE' prints the current cache directory.
  2114  //
  2115  // The go command periodically deletes cached data that has not been
  2116  // used recently. Running 'go clean -cache' deletes all cached data.
  2117  //
  2118  // The build cache correctly accounts for changes to Go source files,
  2119  // compilers, compiler options, and so on: cleaning the cache explicitly
  2120  // should not be necessary in typical use. However, the build cache
  2121  // does not detect changes to C libraries imported with cgo.
  2122  // If you have made changes to the C libraries on your system, you
  2123  // will need to clean the cache explicitly or else use the -a build flag
  2124  // (see 'go help build') to force rebuilding of packages that
  2125  // depend on the updated C libraries.
  2126  //
  2127  // The go command also caches successful package test results.
  2128  // See 'go help test' for details. Running 'go clean -testcache' removes
  2129  // all cached test results (but not cached build results).
  2130  //
  2131  // The go command also caches values used in fuzzing with 'go test -fuzz',
  2132  // specifically, values that expanded code coverage when passed to a
  2133  // fuzz function. These values are not used for regular building and
  2134  // testing, but they're stored in a subdirectory of the build cache.
  2135  // Running 'go clean -fuzzcache' removes all cached fuzzing values.
  2136  // This may make fuzzing less effective, temporarily.
  2137  //
  2138  // The GODEBUG environment variable can enable printing of debugging
  2139  // information about the state of the cache:
  2140  //
  2141  // GODEBUG=gocacheverify=1 causes the go command to bypass the
  2142  // use of any cache entries and instead rebuild everything and check
  2143  // that the results match existing cache entries.
  2144  //
  2145  // GODEBUG=gocachehash=1 causes the go command to print the inputs
  2146  // for all of the content hashes it uses to construct cache lookup keys.
  2147  // The output is voluminous but can be useful for debugging the cache.
  2148  //
  2149  // GODEBUG=gocachetest=1 causes the go command to print details of its
  2150  // decisions about whether to reuse a cached test result.
  2151  //
  2152  // # Environment variables
  2153  //
  2154  // The go command and the tools it invokes consult environment variables
  2155  // for configuration. If an environment variable is unset or empty, the go
  2156  // command uses a sensible default setting. To see the effective setting of
  2157  // the variable <NAME>, run 'go env <NAME>'. To change the default setting,
  2158  // run 'go env -w <NAME>=<VALUE>'. Defaults changed using 'go env -w'
  2159  // are recorded in a Go environment configuration file stored in the
  2160  // per-user configuration directory, as reported by os.UserConfigDir.
  2161  // The location of the configuration file can be changed by setting
  2162  // the environment variable GOENV, and 'go env GOENV' prints the
  2163  // effective location, but 'go env -w' cannot change the default location.
  2164  // See 'go help env' for details.
  2165  //
  2166  // General-purpose environment variables:
  2167  //
  2168  //	GO111MODULE
  2169  //		Controls whether the go command runs in module-aware mode or GOPATH mode.
  2170  //		May be "off", "on", or "auto".
  2171  //		See https://golang.org/ref/mod#mod-commands.
  2172  //	GCCGO
  2173  //		The gccgo command to run for 'go build -compiler=gccgo'.
  2174  //	GOARCH
  2175  //		The architecture, or processor, for which to compile code.
  2176  //		Examples are amd64, 386, arm, ppc64.
  2177  //	GOBIN
  2178  //		The directory where 'go install' will install a command.
  2179  //	GOCACHE
  2180  //		The directory where the go command will store cached
  2181  //		information for reuse in future builds.
  2182  //	GOMODCACHE
  2183  //		The directory where the go command will store downloaded modules.
  2184  //	GODEBUG
  2185  //		Enable various debugging facilities. See https://go.dev/doc/godebug
  2186  //		for details.
  2187  //	GOENV
  2188  //		The location of the Go environment configuration file.
  2189  //		Cannot be set using 'go env -w'.
  2190  //		Setting GOENV=off in the environment disables the use of the
  2191  //		default configuration file.
  2192  //	GOFLAGS
  2193  //		A space-separated list of -flag=value settings to apply
  2194  //		to go commands by default, when the given flag is known by
  2195  //		the current command. Each entry must be a standalone flag.
  2196  //		Because the entries are space-separated, flag values must
  2197  //		not contain spaces. Flags listed on the command line
  2198  //		are applied after this list and therefore override it.
  2199  //	GOINSECURE
  2200  //		Comma-separated list of glob patterns (in the syntax of Go's path.Match)
  2201  //		of module path prefixes that should always be fetched in an insecure
  2202  //		manner. Only applies to dependencies that are being fetched directly.
  2203  //		GOINSECURE does not disable checksum database validation. GOPRIVATE or
  2204  //		GONOSUMDB may be used to achieve that.
  2205  //	GOOS
  2206  //		The operating system for which to compile code.
  2207  //		Examples are linux, darwin, windows, netbsd.
  2208  //	GOPATH
  2209  //		Controls where various files are stored. See: 'go help gopath'.
  2210  //	GOPROXY
  2211  //		URL of Go module proxy. See https://golang.org/ref/mod#environment-variables
  2212  //		and https://golang.org/ref/mod#module-proxy for details.
  2213  //	GOPRIVATE, GONOPROXY, GONOSUMDB
  2214  //		Comma-separated list of glob patterns (in the syntax of Go's path.Match)
  2215  //		of module path prefixes that should always be fetched directly
  2216  //		or that should not be compared against the checksum database.
  2217  //		See https://golang.org/ref/mod#private-modules.
  2218  //	GOROOT
  2219  //		The root of the go tree.
  2220  //	GOSUMDB
  2221  //		The name of checksum database to use and optionally its public key and
  2222  //		URL. See https://golang.org/ref/mod#authenticating.
  2223  //	GOTOOLCHAIN
  2224  //		Controls which Go toolchain is used. See https://go.dev/doc/toolchain.
  2225  //	GOTMPDIR
  2226  //		The directory where the go command will write
  2227  //		temporary source files, packages, and binaries.
  2228  //	GOVCS
  2229  //		Lists version control commands that may be used with matching servers.
  2230  //		See 'go help vcs'.
  2231  //	GOWORK
  2232  //		In module aware mode, use the given go.work file as a workspace file.
  2233  //		By default or when GOWORK is "auto", the go command searches for a
  2234  //		file named go.work in the current directory and then containing directories
  2235  //		until one is found. If a valid go.work file is found, the modules
  2236  //		specified will collectively be used as the main modules. If GOWORK
  2237  //		is "off", or a go.work file is not found in "auto" mode, workspace
  2238  //		mode is disabled.
  2239  //
  2240  // Environment variables for use with cgo:
  2241  //
  2242  //	AR
  2243  //		The command to use to manipulate library archives when
  2244  //		building with the gccgo compiler.
  2245  //		The default is 'ar'.
  2246  //	CC
  2247  //		The command to use to compile C code.
  2248  //	CGO_ENABLED
  2249  //		Whether the cgo command is supported. Either 0 or 1.
  2250  //	CGO_CFLAGS
  2251  //		Flags that cgo will pass to the compiler when compiling
  2252  //		C code.
  2253  //	CGO_CFLAGS_ALLOW
  2254  //		A regular expression specifying additional flags to allow
  2255  //		to appear in #cgo CFLAGS source code directives.
  2256  //		Does not apply to the CGO_CFLAGS environment variable.
  2257  //	CGO_CFLAGS_DISALLOW
  2258  //		A regular expression specifying flags that must be disallowed
  2259  //		from appearing in #cgo CFLAGS source code directives.
  2260  //		Does not apply to the CGO_CFLAGS environment variable.
  2261  //	CGO_CPPFLAGS, CGO_CPPFLAGS_ALLOW, CGO_CPPFLAGS_DISALLOW
  2262  //		Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW,
  2263  //		but for the C preprocessor.
  2264  //	CGO_CXXFLAGS, CGO_CXXFLAGS_ALLOW, CGO_CXXFLAGS_DISALLOW
  2265  //		Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW,
  2266  //		but for the C++ compiler.
  2267  //	CGO_FFLAGS, CGO_FFLAGS_ALLOW, CGO_FFLAGS_DISALLOW
  2268  //		Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW,
  2269  //		but for the Fortran compiler.
  2270  //	CGO_LDFLAGS, CGO_LDFLAGS_ALLOW, CGO_LDFLAGS_DISALLOW
  2271  //		Like CGO_CFLAGS, CGO_CFLAGS_ALLOW, and CGO_CFLAGS_DISALLOW,
  2272  //		but for the linker.
  2273  //	CXX
  2274  //		The command to use to compile C++ code.
  2275  //	FC
  2276  //		The command to use to compile Fortran code.
  2277  //	PKG_CONFIG
  2278  //		Path to pkg-config tool.
  2279  //
  2280  // Architecture-specific environment variables:
  2281  //
  2282  //	GOARM
  2283  //		For GOARCH=arm, the ARM architecture for which to compile.
  2284  //		Valid values are 5, 6, 7.
  2285  //		The value can be followed by an option specifying how to implement floating point instructions.
  2286  //		Valid options are ,softfloat (default for 5) and ,hardfloat (default for 6 and 7).
  2287  //	GO386
  2288  //		For GOARCH=386, how to implement floating point instructions.
  2289  //		Valid values are sse2 (default), softfloat.
  2290  //	GOAMD64
  2291  //		For GOARCH=amd64, the microarchitecture level for which to compile.
  2292  //		Valid values are v1 (default), v2, v3, v4.
  2293  //		See https://golang.org/wiki/MinimumRequirements#amd64
  2294  //	GOMIPS
  2295  //		For GOARCH=mips{,le}, whether to use floating point instructions.
  2296  //		Valid values are hardfloat (default), softfloat.
  2297  //	GOMIPS64
  2298  //		For GOARCH=mips64{,le}, whether to use floating point instructions.
  2299  //		Valid values are hardfloat (default), softfloat.
  2300  //	GOPPC64
  2301  //		For GOARCH=ppc64{,le}, the target ISA (Instruction Set Architecture).
  2302  //		Valid values are power8 (default), power9, power10.
  2303  //	GOWASM
  2304  //		For GOARCH=wasm, comma-separated list of experimental WebAssembly features to use.
  2305  //		Valid values are satconv, signext.
  2306  //
  2307  // Environment variables for use with code coverage:
  2308  //
  2309  //	GOCOVERDIR
  2310  //		Directory into which to write code coverage data files
  2311  //		generated by running a "go build -cover" binary.
  2312  //		Requires that GOEXPERIMENT=coverageredesign is enabled.
  2313  //
  2314  // Special-purpose environment variables:
  2315  //
  2316  //	GCCGOTOOLDIR
  2317  //		If set, where to find gccgo tools, such as cgo.
  2318  //		The default is based on how gccgo was configured.
  2319  //	GOEXPERIMENT
  2320  //		Comma-separated list of toolchain experiments to enable or disable.
  2321  //		The list of available experiments may change arbitrarily over time.
  2322  //		See src/internal/goexperiment/flags.go for currently valid values.
  2323  //		Warning: This variable is provided for the development and testing
  2324  //		of the Go toolchain itself. Use beyond that purpose is unsupported.
  2325  //	GOROOT_FINAL
  2326  //		The root of the installed Go tree, when it is
  2327  //		installed in a location other than where it is built.
  2328  //		File names in stack traces are rewritten from GOROOT to
  2329  //		GOROOT_FINAL.
  2330  //	GO_EXTLINK_ENABLED
  2331  //		Whether the linker should use external linking mode
  2332  //		when using -linkmode=auto with code that uses cgo.
  2333  //		Set to 0 to disable external linking mode, 1 to enable it.
  2334  //	GIT_ALLOW_PROTOCOL
  2335  //		Defined by Git. A colon-separated list of schemes that are allowed
  2336  //		to be used with git fetch/clone. If set, any scheme not explicitly
  2337  //		mentioned will be considered insecure by 'go get'.
  2338  //		Because the variable is defined by Git, the default value cannot
  2339  //		be set using 'go env -w'.
  2340  //
  2341  // Additional information available from 'go env' but not read from the environment:
  2342  //
  2343  //	GOEXE
  2344  //		The executable file name suffix (".exe" on Windows, "" on other systems).
  2345  //	GOGCCFLAGS
  2346  //		A space-separated list of arguments supplied to the CC command.
  2347  //	GOHOSTARCH
  2348  //		The architecture (GOARCH) of the Go toolchain binaries.
  2349  //	GOHOSTOS
  2350  //		The operating system (GOOS) of the Go toolchain binaries.
  2351  //	GOMOD
  2352  //		The absolute path to the go.mod of the main module.
  2353  //		If module-aware mode is enabled, but there is no go.mod, GOMOD will be
  2354  //		os.DevNull ("/dev/null" on Unix-like systems, "NUL" on Windows).
  2355  //		If module-aware mode is disabled, GOMOD will be the empty string.
  2356  //	GOTOOLDIR
  2357  //		The directory where the go tools (compile, cover, doc, etc...) are installed.
  2358  //	GOVERSION
  2359  //		The version of the installed Go tree, as reported by runtime.Version.
  2360  //
  2361  // # File types
  2362  //
  2363  // The go command examines the contents of a restricted set of files
  2364  // in each directory. It identifies which files to examine based on
  2365  // the extension of the file name. These extensions are:
  2366  //
  2367  //	.go
  2368  //		Go source files.
  2369  //	.c, .h
  2370  //		C source files.
  2371  //		If the package uses cgo or SWIG, these will be compiled with the
  2372  //		OS-native compiler (typically gcc); otherwise they will
  2373  //		trigger an error.
  2374  //	.cc, .cpp, .cxx, .hh, .hpp, .hxx
  2375  //		C++ source files. Only useful with cgo or SWIG, and always
  2376  //		compiled with the OS-native compiler.
  2377  //	.m
  2378  //		Objective-C source files. Only useful with cgo, and always
  2379  //		compiled with the OS-native compiler.
  2380  //	.s, .S, .sx
  2381  //		Assembler source files.
  2382  //		If the package uses cgo or SWIG, these will be assembled with the
  2383  //		OS-native assembler (typically gcc (sic)); otherwise they
  2384  //		will be assembled with the Go assembler.
  2385  //	.swig, .swigcxx
  2386  //		SWIG definition files.
  2387  //	.syso
  2388  //		System object files.
  2389  //
  2390  // Files of each of these types except .syso may contain build
  2391  // constraints, but the go command stops scanning for build constraints
  2392  // at the first item in the file that is not a blank line or //-style
  2393  // line comment. See the go/build package documentation for
  2394  // more details.
  2395  //
  2396  // # The go.mod file
  2397  //
  2398  // A module version is defined by a tree of source files, with a go.mod
  2399  // file in its root. When the go command is run, it looks in the current
  2400  // directory and then successive parent directories to find the go.mod
  2401  // marking the root of the main (current) module.
  2402  //
  2403  // The go.mod file format is described in detail at
  2404  // https://golang.org/ref/mod#go-mod-file.
  2405  //
  2406  // To create a new go.mod file, use 'go mod init'. For details see
  2407  // 'go help mod init' or https://golang.org/ref/mod#go-mod-init.
  2408  //
  2409  // To add missing module requirements or remove unneeded requirements,
  2410  // use 'go mod tidy'. For details, see 'go help mod tidy' or
  2411  // https://golang.org/ref/mod#go-mod-tidy.
  2412  //
  2413  // To add, upgrade, downgrade, or remove a specific module requirement, use
  2414  // 'go get'. For details, see 'go help module-get' or
  2415  // https://golang.org/ref/mod#go-get.
  2416  //
  2417  // To make other changes or to parse go.mod as JSON for use by other tools,
  2418  // use 'go mod edit'. See 'go help mod edit' or
  2419  // https://golang.org/ref/mod#go-mod-edit.
  2420  //
  2421  // # GOPATH environment variable
  2422  //
  2423  // The Go path is used to resolve import statements.
  2424  // It is implemented by and documented in the go/build package.
  2425  //
  2426  // The GOPATH environment variable lists places to look for Go code.
  2427  // On Unix, the value is a colon-separated string.
  2428  // On Windows, the value is a semicolon-separated string.
  2429  // On Plan 9, the value is a list.
  2430  //
  2431  // If the environment variable is unset, GOPATH defaults
  2432  // to a subdirectory named "go" in the user's home directory
  2433  // ($HOME/go on Unix, %USERPROFILE%\go on Windows),
  2434  // unless that directory holds a Go distribution.
  2435  // Run "go env GOPATH" to see the current GOPATH.
  2436  //
  2437  // See https://golang.org/wiki/SettingGOPATH to set a custom GOPATH.
  2438  //
  2439  // Each directory listed in GOPATH must have a prescribed structure:
  2440  //
  2441  // The src directory holds source code. The path below src
  2442  // determines the import path or executable name.
  2443  //
  2444  // The pkg directory holds installed package objects.
  2445  // As in the Go tree, each target operating system and
  2446  // architecture pair has its own subdirectory of pkg
  2447  // (pkg/GOOS_GOARCH).
  2448  //
  2449  // If DIR is a directory listed in the GOPATH, a package with
  2450  // source in DIR/src/foo/bar can be imported as "foo/bar" and
  2451  // has its compiled form installed to "DIR/pkg/GOOS_GOARCH/foo/bar.a".
  2452  //
  2453  // The bin directory holds compiled commands.
  2454  // Each command is named for its source directory, but only
  2455  // the final element, not the entire path. That is, the
  2456  // command with source in DIR/src/foo/quux is installed into
  2457  // DIR/bin/quux, not DIR/bin/foo/quux. The "foo/" prefix is stripped
  2458  // so that you can add DIR/bin to your PATH to get at the
  2459  // installed commands. If the GOBIN environment variable is
  2460  // set, commands are installed to the directory it names instead
  2461  // of DIR/bin. GOBIN must be an absolute path.
  2462  //
  2463  // Here's an example directory layout:
  2464  //
  2465  //	GOPATH=/home/user/go
  2466  //
  2467  //	/home/user/go/
  2468  //	    src/
  2469  //	        foo/
  2470  //	            bar/               (go code in package bar)
  2471  //	                x.go
  2472  //	            quux/              (go code in package gocmd)
  2473  //	                y.go
  2474  //	    bin/
  2475  //	        quux                   (installed command)
  2476  //	    pkg/
  2477  //	        linux_amd64/
  2478  //	            foo/
  2479  //	                bar.a          (installed package object)
  2480  //
  2481  // Go searches each directory listed in GOPATH to find source code,
  2482  // but new packages are always downloaded into the first directory
  2483  // in the list.
  2484  //
  2485  // See https://golang.org/doc/code.html for an example.
  2486  //
  2487  // # GOPATH and Modules
  2488  //
  2489  // When using modules, GOPATH is no longer used for resolving imports.
  2490  // However, it is still used to store downloaded source code (in GOPATH/pkg/mod)
  2491  // and compiled commands (in GOPATH/bin).
  2492  //
  2493  // # Internal Directories
  2494  //
  2495  // Code in or below a directory named "internal" is importable only
  2496  // by code in the directory tree rooted at the parent of "internal".
  2497  // Here's an extended version of the directory layout above:
  2498  //
  2499  //	/home/user/go/
  2500  //	    src/
  2501  //	        crash/
  2502  //	            bang/              (go code in package bang)
  2503  //	                b.go
  2504  //	        foo/                   (go code in package foo)
  2505  //	            f.go
  2506  //	            bar/               (go code in package bar)
  2507  //	                x.go
  2508  //	            internal/
  2509  //	                baz/           (go code in package baz)
  2510  //	                    z.go
  2511  //	            quux/              (go code in package gocmd)
  2512  //	                y.go
  2513  //
  2514  // The code in z.go is imported as "foo/internal/baz", but that
  2515  // import statement can only appear in source files in the subtree
  2516  // rooted at foo. The source files foo/f.go, foo/bar/x.go, and
  2517  // foo/quux/y.go can all import "foo/internal/baz", but the source file
  2518  // crash/bang/b.go cannot.
  2519  //
  2520  // See https://golang.org/s/go14internal for details.
  2521  //
  2522  // # Vendor Directories
  2523  //
  2524  // Go 1.6 includes support for using local copies of external dependencies
  2525  // to satisfy imports of those dependencies, often referred to as vendoring.
  2526  //
  2527  // Code below a directory named "vendor" is importable only
  2528  // by code in the directory tree rooted at the parent of "vendor",
  2529  // and only using an import path that omits the prefix up to and
  2530  // including the vendor element.
  2531  //
  2532  // Here's the example from the previous section,
  2533  // but with the "internal" directory renamed to "vendor"
  2534  // and a new foo/vendor/crash/bang directory added:
  2535  //
  2536  //	/home/user/go/
  2537  //	    src/
  2538  //	        crash/
  2539  //	            bang/              (go code in package bang)
  2540  //	                b.go
  2541  //	        foo/                   (go code in package foo)
  2542  //	            f.go
  2543  //	            bar/               (go code in package bar)
  2544  //	                x.go
  2545  //	            vendor/
  2546  //	                crash/
  2547  //	                    bang/      (go code in package bang)
  2548  //	                        b.go
  2549  //	                baz/           (go code in package baz)
  2550  //	                    z.go
  2551  //	            quux/              (go code in package gocmd)
  2552  //	                y.go
  2553  //
  2554  // The same visibility rules apply as for internal, but the code
  2555  // in z.go is imported as "baz", not as "foo/vendor/baz".
  2556  //
  2557  // Code in vendor directories deeper in the source tree shadows
  2558  // code in higher directories. Within the subtree rooted at foo, an import
  2559  // of "crash/bang" resolves to "foo/vendor/crash/bang", not the
  2560  // top-level "crash/bang".
  2561  //
  2562  // Code in vendor directories is not subject to import path
  2563  // checking (see 'go help importpath').
  2564  //
  2565  // When 'go get' checks out or updates a git repository, it now also
  2566  // updates submodules.
  2567  //
  2568  // Vendor directories do not affect the placement of new repositories
  2569  // being checked out for the first time by 'go get': those are always
  2570  // placed in the main GOPATH, never in a vendor subtree.
  2571  //
  2572  // See https://golang.org/s/go15vendor for details.
  2573  //
  2574  // # Module proxy protocol
  2575  //
  2576  // A Go module proxy is any web server that can respond to GET requests for
  2577  // URLs of a specified form. The requests have no query parameters, so even
  2578  // a site serving from a fixed file system (including a file:/// URL)
  2579  // can be a module proxy.
  2580  //
  2581  // For details on the GOPROXY protocol, see
  2582  // https://golang.org/ref/mod#goproxy-protocol.
  2583  //
  2584  // # Import path syntax
  2585  //
  2586  // An import path (see 'go help packages') denotes a package stored in the local
  2587  // file system. In general, an import path denotes either a standard package (such
  2588  // as "unicode/utf8") or a package found in one of the work spaces (For more
  2589  // details see: 'go help gopath').
  2590  //
  2591  // # Relative import paths
  2592  //
  2593  // An import path beginning with ./ or ../ is called a relative path.
  2594  // The toolchain supports relative import paths as a shortcut in two ways.
  2595  //
  2596  // First, a relative path can be used as a shorthand on the command line.
  2597  // If you are working in the directory containing the code imported as
  2598  // "unicode" and want to run the tests for "unicode/utf8", you can type
  2599  // "go test ./utf8" instead of needing to specify the full path.
  2600  // Similarly, in the reverse situation, "go test .." will test "unicode" from
  2601  // the "unicode/utf8" directory. Relative patterns are also allowed, like
  2602  // "go test ./..." to test all subdirectories. See 'go help packages' for details
  2603  // on the pattern syntax.
  2604  //
  2605  // Second, if you are compiling a Go program not in a work space,
  2606  // you can use a relative path in an import statement in that program
  2607  // to refer to nearby code also not in a work space.
  2608  // This makes it easy to experiment with small multipackage programs
  2609  // outside of the usual work spaces, but such programs cannot be
  2610  // installed with "go install" (there is no work space in which to install them),
  2611  // so they are rebuilt from scratch each time they are built.
  2612  // To avoid ambiguity, Go programs cannot use relative import paths
  2613  // within a work space.
  2614  //
  2615  // # Remote import paths
  2616  //
  2617  // Certain import paths also
  2618  // describe how to obtain the source code for the package using
  2619  // a revision control system.
  2620  //
  2621  // A few common code hosting sites have special syntax:
  2622  //
  2623  //	Bitbucket (Git, Mercurial)
  2624  //
  2625  //		import "bitbucket.org/user/project"
  2626  //		import "bitbucket.org/user/project/sub/directory"
  2627  //
  2628  //	GitHub (Git)
  2629  //
  2630  //		import "github.com/user/project"
  2631  //		import "github.com/user/project/sub/directory"
  2632  //
  2633  //	Launchpad (Bazaar)
  2634  //
  2635  //		import "launchpad.net/project"
  2636  //		import "launchpad.net/project/series"
  2637  //		import "launchpad.net/project/series/sub/directory"
  2638  //
  2639  //		import "launchpad.net/~user/project/branch"
  2640  //		import "launchpad.net/~user/project/branch/sub/directory"
  2641  //
  2642  //	IBM DevOps Services (Git)
  2643  //
  2644  //		import "hub.jazz.net/git/user/project"
  2645  //		import "hub.jazz.net/git/user/project/sub/directory"
  2646  //
  2647  // For code hosted on other servers, import paths may either be qualified
  2648  // with the version control type, or the go tool can dynamically fetch
  2649  // the import path over https/http and discover where the code resides
  2650  // from a <meta> tag in the HTML.
  2651  //
  2652  // To declare the code location, an import path of the form
  2653  //
  2654  //	repository.vcs/path
  2655  //
  2656  // specifies the given repository, with or without the .vcs suffix,
  2657  // using the named version control system, and then the path inside
  2658  // that repository. The supported version control systems are:
  2659  //
  2660  //	Bazaar      .bzr
  2661  //	Fossil      .fossil
  2662  //	Git         .git
  2663  //	Mercurial   .hg
  2664  //	Subversion  .svn
  2665  //
  2666  // For example,
  2667  //
  2668  //	import "example.org/user/foo.hg"
  2669  //
  2670  // denotes the root directory of the Mercurial repository at
  2671  // example.org/user/foo or foo.hg, and
  2672  //
  2673  //	import "example.org/repo.git/foo/bar"
  2674  //
  2675  // denotes the foo/bar directory of the Git repository at
  2676  // example.org/repo or repo.git.
  2677  //
  2678  // When a version control system supports multiple protocols,
  2679  // each is tried in turn when downloading. For example, a Git
  2680  // download tries https://, then git+ssh://.
  2681  //
  2682  // By default, downloads are restricted to known secure protocols
  2683  // (e.g. https, ssh). To override this setting for Git downloads, the
  2684  // GIT_ALLOW_PROTOCOL environment variable can be set (For more details see:
  2685  // 'go help environment').
  2686  //
  2687  // If the import path is not a known code hosting site and also lacks a
  2688  // version control qualifier, the go tool attempts to fetch the import
  2689  // over https/http and looks for a <meta> tag in the document's HTML
  2690  // <head>.
  2691  //
  2692  // The meta tag has the form:
  2693  //
  2694  //	<meta name="go-import" content="import-prefix vcs repo-root">
  2695  //
  2696  // The import-prefix is the import path corresponding to the repository
  2697  // root. It must be a prefix or an exact match of the package being
  2698  // fetched with "go get". If it's not an exact match, another http
  2699  // request is made at the prefix to verify the <meta> tags match.
  2700  //
  2701  // The meta tag should appear as early in the file as possible.
  2702  // In particular, it should appear before any raw JavaScript or CSS,
  2703  // to avoid confusing the go command's restricted parser.
  2704  //
  2705  // The vcs is one of "bzr", "fossil", "git", "hg", "svn".
  2706  //
  2707  // The repo-root is the root of the version control system
  2708  // containing a scheme and not containing a .vcs qualifier.
  2709  //
  2710  // For example,
  2711  //
  2712  //	import "example.org/pkg/foo"
  2713  //
  2714  // will result in the following requests:
  2715  //
  2716  //	https://example.org/pkg/foo?go-get=1 (preferred)
  2717  //	http://example.org/pkg/foo?go-get=1  (fallback, only with use of correctly set GOINSECURE)
  2718  //
  2719  // If that page contains the meta tag
  2720  //
  2721  //	<meta name="go-import" content="example.org git https://code.org/r/p/exproj">
  2722  //
  2723  // the go tool will verify that https://example.org/?go-get=1 contains the
  2724  // same meta tag and then git clone https://code.org/r/p/exproj into
  2725  // GOPATH/src/example.org.
  2726  //
  2727  // When using GOPATH, downloaded packages are written to the first directory
  2728  // listed in the GOPATH environment variable.
  2729  // (See 'go help gopath-get' and 'go help gopath'.)
  2730  //
  2731  // When using modules, downloaded packages are stored in the module cache.
  2732  // See https://golang.org/ref/mod#module-cache.
  2733  //
  2734  // When using modules, an additional variant of the go-import meta tag is
  2735  // recognized and is preferred over those listing version control systems.
  2736  // That variant uses "mod" as the vcs in the content value, as in:
  2737  //
  2738  //	<meta name="go-import" content="example.org mod https://code.org/moduleproxy">
  2739  //
  2740  // This tag means to fetch modules with paths beginning with example.org
  2741  // from the module proxy available at the URL https://code.org/moduleproxy.
  2742  // See https://golang.org/ref/mod#goproxy-protocol for details about the
  2743  // proxy protocol.
  2744  //
  2745  // # Import path checking
  2746  //
  2747  // When the custom import path feature described above redirects to a
  2748  // known code hosting site, each of the resulting packages has two possible
  2749  // import paths, using the custom domain or the known hosting site.
  2750  //
  2751  // A package statement is said to have an "import comment" if it is immediately
  2752  // followed (before the next newline) by a comment of one of these two forms:
  2753  //
  2754  //	package math // import "path"
  2755  //	package math /* import "path" */
  2756  //
  2757  // The go command will refuse to install a package with an import comment
  2758  // unless it is being referred to by that import path. In this way, import comments
  2759  // let package authors make sure the custom import path is used and not a
  2760  // direct path to the underlying code hosting site.
  2761  //
  2762  // Import path checking is disabled for code found within vendor trees.
  2763  // This makes it possible to copy code into alternate locations in vendor trees
  2764  // without needing to update import comments.
  2765  //
  2766  // Import path checking is also disabled when using modules.
  2767  // Import path comments are obsoleted by the go.mod file's module statement.
  2768  //
  2769  // See https://golang.org/s/go14customimport for details.
  2770  //
  2771  // # Modules, module versions, and more
  2772  //
  2773  // Modules are how Go manages dependencies.
  2774  //
  2775  // A module is a collection of packages that are released, versioned, and
  2776  // distributed together. Modules may be downloaded directly from version control
  2777  // repositories or from module proxy servers.
  2778  //
  2779  // For a series of tutorials on modules, see
  2780  // https://golang.org/doc/tutorial/create-module.
  2781  //
  2782  // For a detailed reference on modules, see https://golang.org/ref/mod.
  2783  //
  2784  // By default, the go command may download modules from https://proxy.golang.org.
  2785  // It may authenticate modules using the checksum database at
  2786  // https://sum.golang.org. Both services are operated by the Go team at Google.
  2787  // The privacy policies for these services are available at
  2788  // https://proxy.golang.org/privacy and https://sum.golang.org/privacy,
  2789  // respectively.
  2790  //
  2791  // The go command's download behavior may be configured using GOPROXY, GOSUMDB,
  2792  // GOPRIVATE, and other environment variables. See 'go help environment'
  2793  // and https://golang.org/ref/mod#private-module-privacy for more information.
  2794  //
  2795  // # Module authentication using go.sum
  2796  //
  2797  // When the go command downloads a module zip file or go.mod file into the
  2798  // module cache, it computes a cryptographic hash and compares it with a known
  2799  // value to verify the file hasn't changed since it was first downloaded. Known
  2800  // hashes are stored in a file in the module root directory named go.sum. Hashes
  2801  // may also be downloaded from the checksum database depending on the values of
  2802  // GOSUMDB, GOPRIVATE, and GONOSUMDB.
  2803  //
  2804  // For details, see https://golang.org/ref/mod#authenticating.
  2805  //
  2806  // # Package lists and patterns
  2807  //
  2808  // Many commands apply to a set of packages:
  2809  //
  2810  //	go <action> [packages]
  2811  //
  2812  // Usually, [packages] is a list of import paths.
  2813  //
  2814  // An import path that is a rooted path or that begins with
  2815  // a . or .. element is interpreted as a file system path and
  2816  // denotes the package in that directory.
  2817  //
  2818  // Otherwise, the import path P denotes the package found in
  2819  // the directory DIR/src/P for some DIR listed in the GOPATH
  2820  // environment variable (For more details see: 'go help gopath').
  2821  //
  2822  // If no import paths are given, the action applies to the
  2823  // package in the current directory.
  2824  //
  2825  // There are four reserved names for paths that should not be used
  2826  // for packages to be built with the go tool:
  2827  //
  2828  // - "main" denotes the top-level package in a stand-alone executable.
  2829  //
  2830  // - "all" expands to all packages found in all the GOPATH
  2831  // trees. For example, 'go list all' lists all the packages on the local
  2832  // system. When using modules, "all" expands to all packages in
  2833  // the main module and their dependencies, including dependencies
  2834  // needed by tests of any of those.
  2835  //
  2836  // - "std" is like all but expands to just the packages in the standard
  2837  // Go library.
  2838  //
  2839  // - "cmd" expands to the Go repository's commands and their
  2840  // internal libraries.
  2841  //
  2842  // Import paths beginning with "cmd/" only match source code in
  2843  // the Go repository.
  2844  //
  2845  // An import path is a pattern if it includes one or more "..." wildcards,
  2846  // each of which can match any string, including the empty string and
  2847  // strings containing slashes. Such a pattern expands to all package
  2848  // directories found in the GOPATH trees with names matching the
  2849  // patterns.
  2850  //
  2851  // To make common patterns more convenient, there are two special cases.
  2852  // First, /... at the end of the pattern can match an empty string,
  2853  // so that net/... matches both net and packages in its subdirectories, like net/http.
  2854  // Second, any slash-separated pattern element containing a wildcard never
  2855  // participates in a match of the "vendor" element in the path of a vendored
  2856  // package, so that ./... does not match packages in subdirectories of
  2857  // ./vendor or ./mycode/vendor, but ./vendor/... and ./mycode/vendor/... do.
  2858  // Note, however, that a directory named vendor that itself contains code
  2859  // is not a vendored package: cmd/vendor would be a command named vendor,
  2860  // and the pattern cmd/... matches it.
  2861  // See golang.org/s/go15vendor for more about vendoring.
  2862  //
  2863  // An import path can also name a package to be downloaded from
  2864  // a remote repository. Run 'go help importpath' for details.
  2865  //
  2866  // Every package in a program must have a unique import path.
  2867  // By convention, this is arranged by starting each path with a
  2868  // unique prefix that belongs to you. For example, paths used
  2869  // internally at Google all begin with 'google', and paths
  2870  // denoting remote repositories begin with the path to the code,
  2871  // such as 'github.com/user/repo'.
  2872  //
  2873  // Packages in a program need not have unique package names,
  2874  // but there are two reserved package names with special meaning.
  2875  // The name main indicates a command, not a library.
  2876  // Commands are built into binaries and cannot be imported.
  2877  // The name documentation indicates documentation for
  2878  // a non-Go program in the directory. Files in package documentation
  2879  // are ignored by the go command.
  2880  //
  2881  // As a special case, if the package list is a list of .go files from a
  2882  // single directory, the command is applied to a single synthesized
  2883  // package made up of exactly those files, ignoring any build constraints
  2884  // in those files and ignoring any other files in the directory.
  2885  //
  2886  // Directory and file names that begin with "." or "_" are ignored
  2887  // by the go tool, as are directories named "testdata".
  2888  //
  2889  // # Configuration for downloading non-public code
  2890  //
  2891  // The go command defaults to downloading modules from the public Go module
  2892  // mirror at proxy.golang.org. It also defaults to validating downloaded modules,
  2893  // regardless of source, against the public Go checksum database at sum.golang.org.
  2894  // These defaults work well for publicly available source code.
  2895  //
  2896  // The GOPRIVATE environment variable controls which modules the go command
  2897  // considers to be private (not available publicly) and should therefore not use
  2898  // the proxy or checksum database. The variable is a comma-separated list of
  2899  // glob patterns (in the syntax of Go's path.Match) of module path prefixes.
  2900  // For example,
  2901  //
  2902  //	GOPRIVATE=*.corp.example.com,rsc.io/private
  2903  //
  2904  // causes the go command to treat as private any module with a path prefix
  2905  // matching either pattern, including git.corp.example.com/xyzzy, rsc.io/private,
  2906  // and rsc.io/private/quux.
  2907  //
  2908  // For fine-grained control over module download and validation, the GONOPROXY
  2909  // and GONOSUMDB environment variables accept the same kind of glob list
  2910  // and override GOPRIVATE for the specific decision of whether to use the proxy
  2911  // and checksum database, respectively.
  2912  //
  2913  // For example, if a company ran a module proxy serving private modules,
  2914  // users would configure go using:
  2915  //
  2916  //	GOPRIVATE=*.corp.example.com
  2917  //	GOPROXY=proxy.example.com
  2918  //	GONOPROXY=none
  2919  //
  2920  // The GOPRIVATE variable is also used to define the "public" and "private"
  2921  // patterns for the GOVCS variable; see 'go help vcs'. For that usage,
  2922  // GOPRIVATE applies even in GOPATH mode. In that case, it matches import paths
  2923  // instead of module paths.
  2924  //
  2925  // The 'go env -w' command (see 'go help env') can be used to set these variables
  2926  // for future go command invocations.
  2927  //
  2928  // For more details, see https://golang.org/ref/mod#private-modules.
  2929  //
  2930  // # Testing flags
  2931  //
  2932  // The 'go test' command takes both flags that apply to 'go test' itself
  2933  // and flags that apply to the resulting test binary.
  2934  //
  2935  // Several of the flags control profiling and write an execution profile
  2936  // suitable for "go tool pprof"; run "go tool pprof -h" for more
  2937  // information. The --alloc_space, --alloc_objects, and --show_bytes
  2938  // options of pprof control how the information is presented.
  2939  //
  2940  // The following flags are recognized by the 'go test' command and
  2941  // control the execution of any test:
  2942  //
  2943  //	-bench regexp
  2944  //	    Run only those benchmarks matching a regular expression.
  2945  //	    By default, no benchmarks are run.
  2946  //	    To run all benchmarks, use '-bench .' or '-bench=.'.
  2947  //	    The regular expression is split by unbracketed slash (/)
  2948  //	    characters into a sequence of regular expressions, and each
  2949  //	    part of a benchmark's identifier must match the corresponding
  2950  //	    element in the sequence, if any. Possible parents of matches
  2951  //	    are run with b.N=1 to identify sub-benchmarks. For example,
  2952  //	    given -bench=X/Y, top-level benchmarks matching X are run
  2953  //	    with b.N=1 to find any sub-benchmarks matching Y, which are
  2954  //	    then run in full.
  2955  //
  2956  //	-benchtime t
  2957  //	    Run enough iterations of each benchmark to take t, specified
  2958  //	    as a time.Duration (for example, -benchtime 1h30s).
  2959  //	    The default is 1 second (1s).
  2960  //	    The special syntax Nx means to run the benchmark N times
  2961  //	    (for example, -benchtime 100x).
  2962  //
  2963  //	-count n
  2964  //	    Run each test, benchmark, and fuzz seed n times (default 1).
  2965  //	    If -cpu is set, run n times for each GOMAXPROCS value.
  2966  //	    Examples are always run once. -count does not apply to
  2967  //	    fuzz tests matched by -fuzz.
  2968  //
  2969  //	-cover
  2970  //	    Enable coverage analysis.
  2971  //	    Note that because coverage works by annotating the source
  2972  //	    code before compilation, compilation and test failures with
  2973  //	    coverage enabled may report line numbers that don't correspond
  2974  //	    to the original sources.
  2975  //
  2976  //	-covermode set,count,atomic
  2977  //	    Set the mode for coverage analysis for the package[s]
  2978  //	    being tested. The default is "set" unless -race is enabled,
  2979  //	    in which case it is "atomic".
  2980  //	    The values:
  2981  //		set: bool: does this statement run?
  2982  //		count: int: how many times does this statement run?
  2983  //		atomic: int: count, but correct in multithreaded tests;
  2984  //			significantly more expensive.
  2985  //	    Sets -cover.
  2986  //
  2987  //	-coverpkg pattern1,pattern2,pattern3
  2988  //	    Apply coverage analysis in each test to packages matching the patterns.
  2989  //	    The default is for each test to analyze only the package being tested.
  2990  //	    See 'go help packages' for a description of package patterns.
  2991  //	    Sets -cover.
  2992  //
  2993  //	-cpu 1,2,4
  2994  //	    Specify a list of GOMAXPROCS values for which the tests, benchmarks or
  2995  //	    fuzz tests should be executed. The default is the current value
  2996  //	    of GOMAXPROCS. -cpu does not apply to fuzz tests matched by -fuzz.
  2997  //
  2998  //	-failfast
  2999  //	    Do not start new tests after the first test failure.
  3000  //
  3001  //	-fullpath
  3002  //	    Show full file names in the error messages.
  3003  //
  3004  //	-fuzz regexp
  3005  //	    Run the fuzz test matching the regular expression. When specified,
  3006  //	    the command line argument must match exactly one package within the
  3007  //	    main module, and regexp must match exactly one fuzz test within
  3008  //	    that package. Fuzzing will occur after tests, benchmarks, seed corpora
  3009  //	    of other fuzz tests, and examples have completed. See the Fuzzing
  3010  //	    section of the testing package documentation for details.
  3011  //
  3012  //	-fuzztime t
  3013  //	    Run enough iterations of the fuzz target during fuzzing to take t,
  3014  //	    specified as a time.Duration (for example, -fuzztime 1h30s).
  3015  //		The default is to run forever.
  3016  //	    The special syntax Nx means to run the fuzz target N times
  3017  //	    (for example, -fuzztime 1000x).
  3018  //
  3019  //	-fuzzminimizetime t
  3020  //	    Run enough iterations of the fuzz target during each minimization
  3021  //	    attempt to take t, as specified as a time.Duration (for example,
  3022  //	    -fuzzminimizetime 30s).
  3023  //		The default is 60s.
  3024  //	    The special syntax Nx means to run the fuzz target N times
  3025  //	    (for example, -fuzzminimizetime 100x).
  3026  //
  3027  //	-json
  3028  //	    Log verbose output and test results in JSON. This presents the
  3029  //	    same information as the -v flag in a machine-readable format.
  3030  //
  3031  //	-list regexp
  3032  //	    List tests, benchmarks, fuzz tests, or examples matching the regular
  3033  //	    expression. No tests, benchmarks, fuzz tests, or examples will be run.
  3034  //	    This will only list top-level tests. No subtest or subbenchmarks will be
  3035  //	    shown.
  3036  //
  3037  //	-parallel n
  3038  //	    Allow parallel execution of test functions that call t.Parallel, and
  3039  //	    fuzz targets that call t.Parallel when running the seed corpus.
  3040  //	    The value of this flag is the maximum number of tests to run
  3041  //	    simultaneously.
  3042  //	    While fuzzing, the value of this flag is the maximum number of
  3043  //	    subprocesses that may call the fuzz function simultaneously, regardless of
  3044  //	    whether T.Parallel is called.
  3045  //	    By default, -parallel is set to the value of GOMAXPROCS.
  3046  //	    Setting -parallel to values higher than GOMAXPROCS may cause degraded
  3047  //	    performance due to CPU contention, especially when fuzzing.
  3048  //	    Note that -parallel only applies within a single test binary.
  3049  //	    The 'go test' command may run tests for different packages
  3050  //	    in parallel as well, according to the setting of the -p flag
  3051  //	    (see 'go help build').
  3052  //
  3053  //	-run regexp
  3054  //	    Run only those tests, examples, and fuzz tests matching the regular
  3055  //	    expression. For tests, the regular expression is split by unbracketed
  3056  //	    slash (/) characters into a sequence of regular expressions, and each
  3057  //	    part of a test's identifier must match the corresponding element in
  3058  //	    the sequence, if any. Note that possible parents of matches are
  3059  //	    run too, so that -run=X/Y matches and runs and reports the result
  3060  //	    of all tests matching X, even those without sub-tests matching Y,
  3061  //	    because it must run them to look for those sub-tests.
  3062  //	    See also -skip.
  3063  //
  3064  //	-short
  3065  //	    Tell long-running tests to shorten their run time.
  3066  //	    It is off by default but set during all.bash so that installing
  3067  //	    the Go tree can run a sanity check but not spend time running
  3068  //	    exhaustive tests.
  3069  //
  3070  //	-shuffle off,on,N
  3071  //	    Randomize the execution order of tests and benchmarks.
  3072  //	    It is off by default. If -shuffle is set to on, then it will seed
  3073  //	    the randomizer using the system clock. If -shuffle is set to an
  3074  //	    integer N, then N will be used as the seed value. In both cases,
  3075  //	    the seed will be reported for reproducibility.
  3076  //
  3077  //	-skip regexp
  3078  //	    Run only those tests, examples, fuzz tests, and benchmarks that
  3079  //	    do not match the regular expression. Like for -run and -bench,
  3080  //	    for tests and benchmarks, the regular expression is split by unbracketed
  3081  //	    slash (/) characters into a sequence of regular expressions, and each
  3082  //	    part of a test's identifier must match the corresponding element in
  3083  //	    the sequence, if any.
  3084  //
  3085  //	-timeout d
  3086  //	    If a test binary runs longer than duration d, panic.
  3087  //	    If d is 0, the timeout is disabled.
  3088  //	    The default is 10 minutes (10m).
  3089  //
  3090  //	-v
  3091  //	    Verbose output: log all tests as they are run. Also print all
  3092  //	    text from Log and Logf calls even if the test succeeds.
  3093  //
  3094  //	-vet list
  3095  //	    Configure the invocation of "go vet" during "go test"
  3096  //	    to use the comma-separated list of vet checks.
  3097  //	    If list is empty, "go test" runs "go vet" with a curated list of
  3098  //	    checks believed to be always worth addressing.
  3099  //	    If list is "off", "go test" does not run "go vet" at all.
  3100  //
  3101  // The following flags are also recognized by 'go test' and can be used to
  3102  // profile the tests during execution:
  3103  //
  3104  //	-benchmem
  3105  //	    Print memory allocation statistics for benchmarks.
  3106  //
  3107  //	-blockprofile block.out
  3108  //	    Write a goroutine blocking profile to the specified file
  3109  //	    when all tests are complete.
  3110  //	    Writes test binary as -c would.
  3111  //
  3112  //	-blockprofilerate n
  3113  //	    Control the detail provided in goroutine blocking profiles by
  3114  //	    calling runtime.SetBlockProfileRate with n.
  3115  //	    See 'go doc runtime.SetBlockProfileRate'.
  3116  //	    The profiler aims to sample, on average, one blocking event every
  3117  //	    n nanoseconds the program spends blocked. By default,
  3118  //	    if -test.blockprofile is set without this flag, all blocking events
  3119  //	    are recorded, equivalent to -test.blockprofilerate=1.
  3120  //
  3121  //	-coverprofile cover.out
  3122  //	    Write a coverage profile to the file after all tests have passed.
  3123  //	    Sets -cover.
  3124  //
  3125  //	-cpuprofile cpu.out
  3126  //	    Write a CPU profile to the specified file before exiting.
  3127  //	    Writes test binary as -c would.
  3128  //
  3129  //	-memprofile mem.out
  3130  //	    Write an allocation profile to the file after all tests have passed.
  3131  //	    Writes test binary as -c would.
  3132  //
  3133  //	-memprofilerate n
  3134  //	    Enable more precise (and expensive) memory allocation profiles by
  3135  //	    setting runtime.MemProfileRate. See 'go doc runtime.MemProfileRate'.
  3136  //	    To profile all memory allocations, use -test.memprofilerate=1.
  3137  //
  3138  //	-mutexprofile mutex.out
  3139  //	    Write a mutex contention profile to the specified file
  3140  //	    when all tests are complete.
  3141  //	    Writes test binary as -c would.
  3142  //
  3143  //	-mutexprofilefraction n
  3144  //	    Sample 1 in n stack traces of goroutines holding a
  3145  //	    contended mutex.
  3146  //
  3147  //	-outputdir directory
  3148  //	    Place output files from profiling in the specified directory,
  3149  //	    by default the directory in which "go test" is running.
  3150  //
  3151  //	-trace trace.out
  3152  //	    Write an execution trace to the specified file before exiting.
  3153  //
  3154  // Each of these flags is also recognized with an optional 'test.' prefix,
  3155  // as in -test.v. When invoking the generated test binary (the result of
  3156  // 'go test -c') directly, however, the prefix is mandatory.
  3157  //
  3158  // The 'go test' command rewrites or removes recognized flags,
  3159  // as appropriate, both before and after the optional package list,
  3160  // before invoking the test binary.
  3161  //
  3162  // For instance, the command
  3163  //
  3164  //	go test -v -myflag testdata -cpuprofile=prof.out -x
  3165  //
  3166  // will compile the test binary and then run it as
  3167  //
  3168  //	pkg.test -test.v -myflag testdata -test.cpuprofile=prof.out
  3169  //
  3170  // (The -x flag is removed because it applies only to the go command's
  3171  // execution, not to the test itself.)
  3172  //
  3173  // The test flags that generate profiles (other than for coverage) also
  3174  // leave the test binary in pkg.test for use when analyzing the profiles.
  3175  //
  3176  // When 'go test' runs a test binary, it does so from within the
  3177  // corresponding package's source code directory. Depending on the test,
  3178  // it may be necessary to do the same when invoking a generated test
  3179  // binary directly. Because that directory may be located within the
  3180  // module cache, which may be read-only and is verified by checksums, the
  3181  // test must not write to it or any other directory within the module
  3182  // unless explicitly requested by the user (such as with the -fuzz flag,
  3183  // which writes failures to testdata/fuzz).
  3184  //
  3185  // The command-line package list, if present, must appear before any
  3186  // flag not known to the go test command. Continuing the example above,
  3187  // the package list would have to appear before -myflag, but could appear
  3188  // on either side of -v.
  3189  //
  3190  // When 'go test' runs in package list mode, 'go test' caches successful
  3191  // package test results to avoid unnecessary repeated running of tests. To
  3192  // disable test caching, use any test flag or argument other than the
  3193  // cacheable flags. The idiomatic way to disable test caching explicitly
  3194  // is to use -count=1.
  3195  //
  3196  // To keep an argument for a test binary from being interpreted as a
  3197  // known flag or a package name, use -args (see 'go help test') which
  3198  // passes the remainder of the command line through to the test binary
  3199  // uninterpreted and unaltered.
  3200  //
  3201  // For instance, the command
  3202  //
  3203  //	go test -v -args -x -v
  3204  //
  3205  // will compile the test binary and then run it as
  3206  //
  3207  //	pkg.test -test.v -x -v
  3208  //
  3209  // Similarly,
  3210  //
  3211  //	go test -args math
  3212  //
  3213  // will compile the test binary and then run it as
  3214  //
  3215  //	pkg.test math
  3216  //
  3217  // In the first example, the -x and the second -v are passed through to the
  3218  // test binary unchanged and with no effect on the go command itself.
  3219  // In the second example, the argument math is passed through to the test
  3220  // binary, instead of being interpreted as the package list.
  3221  //
  3222  // # Testing functions
  3223  //
  3224  // The 'go test' command expects to find test, benchmark, and example functions
  3225  // in the "*_test.go" files corresponding to the package under test.
  3226  //
  3227  // A test function is one named TestXxx (where Xxx does not start with a
  3228  // lower case letter) and should have the signature,
  3229  //
  3230  //	func TestXxx(t *testing.T) { ... }
  3231  //
  3232  // A benchmark function is one named BenchmarkXxx and should have the signature,
  3233  //
  3234  //	func BenchmarkXxx(b *testing.B) { ... }
  3235  //
  3236  // A fuzz test is one named FuzzXxx and should have the signature,
  3237  //
  3238  //	func FuzzXxx(f *testing.F) { ... }
  3239  //
  3240  // An example function is similar to a test function but, instead of using
  3241  // *testing.T to report success or failure, prints output to os.Stdout.
  3242  // If the last comment in the function starts with "Output:" then the output
  3243  // is compared exactly against the comment (see examples below). If the last
  3244  // comment begins with "Unordered output:" then the output is compared to the
  3245  // comment, however the order of the lines is ignored. An example with no such
  3246  // comment is compiled but not executed. An example with no text after
  3247  // "Output:" is compiled, executed, and expected to produce no output.
  3248  //
  3249  // Godoc displays the body of ExampleXxx to demonstrate the use
  3250  // of the function, constant, or variable Xxx. An example of a method M with
  3251  // receiver type T or *T is named ExampleT_M. There may be multiple examples
  3252  // for a given function, constant, or variable, distinguished by a trailing _xxx,
  3253  // where xxx is a suffix not beginning with an upper case letter.
  3254  //
  3255  // Here is an example of an example:
  3256  //
  3257  //	func ExamplePrintln() {
  3258  //		Println("The output of\nthis example.")
  3259  //		// Output: The output of
  3260  //		// this example.
  3261  //	}
  3262  //
  3263  // Here is another example where the ordering of the output is ignored:
  3264  //
  3265  //	func ExamplePerm() {
  3266  //		for _, value := range Perm(4) {
  3267  //			fmt.Println(value)
  3268  //		}
  3269  //
  3270  //		// Unordered output: 4
  3271  //		// 2
  3272  //		// 1
  3273  //		// 3
  3274  //		// 0
  3275  //	}
  3276  //
  3277  // The entire test file is presented as the example when it contains a single
  3278  // example function, at least one other function, type, variable, or constant
  3279  // declaration, and no tests, benchmarks, or fuzz tests.
  3280  //
  3281  // See the documentation of the testing package for more information.
  3282  //
  3283  // # Controlling version control with GOVCS
  3284  //
  3285  // The 'go get' command can run version control commands like git
  3286  // to download imported code. This functionality is critical to the decentralized
  3287  // Go package ecosystem, in which code can be imported from any server,
  3288  // but it is also a potential security problem, if a malicious server finds a
  3289  // way to cause the invoked version control command to run unintended code.
  3290  //
  3291  // To balance the functionality and security concerns, the 'go get' command
  3292  // by default will only use git and hg to download code from public servers.
  3293  // But it will use any known version control system (bzr, fossil, git, hg, svn)
  3294  // to download code from private servers, defined as those hosting packages
  3295  // matching the GOPRIVATE variable (see 'go help private'). The rationale behind
  3296  // allowing only Git and Mercurial is that these two systems have had the most
  3297  // attention to issues of being run as clients of untrusted servers. In contrast,
  3298  // Bazaar, Fossil, and Subversion have primarily been used in trusted,
  3299  // authenticated environments and are not as well scrutinized as attack surfaces.
  3300  //
  3301  // The version control command restrictions only apply when using direct version
  3302  // control access to download code. When downloading modules from a proxy,
  3303  // 'go get' uses the proxy protocol instead, which is always permitted.
  3304  // By default, the 'go get' command uses the Go module mirror (proxy.golang.org)
  3305  // for public packages and only falls back to version control for private
  3306  // packages or when the mirror refuses to serve a public package (typically for
  3307  // legal reasons). Therefore, clients can still access public code served from
  3308  // Bazaar, Fossil, or Subversion repositories by default, because those downloads
  3309  // use the Go module mirror, which takes on the security risk of running the
  3310  // version control commands using a custom sandbox.
  3311  //
  3312  // The GOVCS variable can be used to change the allowed version control systems
  3313  // for specific packages (identified by a module or import path).
  3314  // The GOVCS variable applies when building package in both module-aware mode
  3315  // and GOPATH mode. When using modules, the patterns match against the module path.
  3316  // When using GOPATH, the patterns match against the import path corresponding to
  3317  // the root of the version control repository.
  3318  //
  3319  // The general form of the GOVCS setting is a comma-separated list of
  3320  // pattern:vcslist rules. The pattern is a glob pattern that must match
  3321  // one or more leading elements of the module or import path. The vcslist
  3322  // is a pipe-separated list of allowed version control commands, or "all"
  3323  // to allow use of any known command, or "off" to disallow all commands.
  3324  // Note that if a module matches a pattern with vcslist "off", it may still be
  3325  // downloaded if the origin server uses the "mod" scheme, which instructs the
  3326  // go command to download the module using the GOPROXY protocol.
  3327  // The earliest matching pattern in the list applies, even if later patterns
  3328  // might also match.
  3329  //
  3330  // For example, consider:
  3331  //
  3332  //	GOVCS=github.com:git,evil.com:off,*:git|hg
  3333  //
  3334  // With this setting, code with a module or import path beginning with
  3335  // github.com/ can only use git; paths on evil.com cannot use any version
  3336  // control command, and all other paths (* matches everything) can use
  3337  // only git or hg.
  3338  //
  3339  // The special patterns "public" and "private" match public and private
  3340  // module or import paths. A path is private if it matches the GOPRIVATE
  3341  // variable; otherwise it is public.
  3342  //
  3343  // If no rules in the GOVCS variable match a particular module or import path,
  3344  // the 'go get' command applies its default rule, which can now be summarized
  3345  // in GOVCS notation as 'public:git|hg,private:all'.
  3346  //
  3347  // To allow unfettered use of any version control system for any package, use:
  3348  //
  3349  //	GOVCS=*:all
  3350  //
  3351  // To disable all use of version control, use:
  3352  //
  3353  //	GOVCS=*:off
  3354  //
  3355  // The 'go env -w' command (see 'go help env') can be used to set the GOVCS
  3356  // variable for future go command invocations.
  3357  package gocmd