Package-Level Functions (total 15, in which 6 are exported)
GoVersion reports the minor version number of the highest release
tag built into the go command on the PATH.
Note that this may be higher than the version of the go tool used
to build this application, and thus the versions of the standard
go/{scanner,parser,ast,types} packages that are linked into it.
In that case, callers should either downgrade to the version of
go used to build the application, or report an error that the
application is too old to use the go command on the PATH.
GoVersionOutput returns the complete output of the go version command.
ParseGoVersionOutput extracts the Go version string
from the output of the "go version" command.
Given an unrecognized form, it returns an empty string.
VendorEnabled reports whether vendoring is enabled. It takes a *Runner to execute Go commands
with the supplied context.Context and Invocation. The Invocation can contain pre-defined fields,
of which only Verb and Args are modified to run the appropriate Go command.
Inspired by setDefaultBuildMod in modload/init.go
WorkspaceVendorEnabled reports whether workspace vendoring is enabled. It takes a *Runner to execute Go commands
with the supplied context.Context and Invocation. The Invocation can contain pre-defined fields,
of which only Verb and Args are modified to run the appropriate Go command.
Inspired by setDefaultBuildMod in modload/init.go
WriteOverlays writes each value in the overlay (see the Overlay
field of go/packages.Config) to a temporary file and returns the name
of a JSON file describing the mapping that is suitable for the "go
list -overlay" flag.
On success, the caller must call the cleanup function exactly once
when the files are no longer needed.
getMainModuleAnd114 gets one of the main modules' information and whether the
go command in use is 1.14+. This is the information needed to figure out
if vendoring should be enabled.
getWorkspaceMainModules gets the main modules' information.
This is the information needed to figure out if vendoring should be enabled.
handleHangingGoCommand outputs debugging information to help diagnose the
cause of a hanging Go command, and then exits with log.Fatalf.
interruptProcess sends SIGINT to the entire process group (-pid) so that both
the Go command and any subprocesses (such as C compilers) get
the interrupt signal and terminate promptly.
Unlike cmd.Process.Signal, syscall.Kill(-pid, ...) does not synchronize with
cmd.Process.Wait via os.Process's internal lock. PGID reuse is not a
problem, as the kernel reserves the PGID as long as any member
of the process group is alive, and runCmdContext only signals the
process group while cmd.Wait is still blocked on the process or its open pipes.
killProcess sends SIGKILL to the entire process group (-pid) to forcefully
terminate any remaining descendant processes. It ignores ESRCH if the process
group has already terminated.
runCmdContext is like exec.CommandContext except it sends os.Interrupt
before os.Kill.
setProcessGroup sets Setpgid so that the child process runs as the leader of
its own process group. Any subprocesses spawned by the Go command (such as
cgo, compilers, or assemblers) will inherit this process group, allowing
cancellation signals to reach all descendant processes rather than orphaning
them (see golang/go#81408).
Package-Level Variables (total 6, in which 1 is exported)
DebugHangingGoCommands may be set by tests to enable additional
instrumentation (including panics) for debugging hanging Go commands.
See golang/go#54461 for details.
event keys for go command invocations
1.13: go: updates to go.mod needed, but contents have changed
1.14: go: updating go.mod: existing contents have changed since last read