This command modifies the call tree starting at `work.runInstall` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/work
rf 'inject modload.LoaderState runInstall'
cd ..
./rf-cleanup.zsh
Change-Id: I038d2c4870d67835c165852b223eaad3e2496202
Reviewed-on: https://go-review.googlesource.com/c/go/+/710304
Reviewed-by: Michael Matloob <matloob@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This command modifies the call tree starting at `work.runBuild` and
`work.runInstall` to inject a `State` parameter to every function that
is currently using the global `modload.LoaderState` variable. By
explicilty passing a `State` parameter, we can begin to eliminate the
usage of the global `modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/work
rf 'inject modload.LoaderState runBuild'
cd ..
./rf-cleanup.zsh
# cd work
# rf 'inject modload.LoaderState runInstall'
# cd ..
# ./rf-cleanup.zsh
Change-Id: I232452d877211d4ac72f42aa193b30dab9649481
Reviewed-on: https://go-review.googlesource.com/c/go/+/709990
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@google.com>
This command modifies the call tree starting at `list.runList` to
inject a `State` parameter to every function that is currently using
the global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/list
rf 'inject modload.LoaderState runList'
cd ..
./rf-cleanup.zsh
Change-Id: I7274bc3dc6779bd8306fb79c158aa6f0473827a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/709979
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This command modifies the call tree starting at `run.runRun` to inject
a `State` parameter to every function that is currently using the
global `modload.LoaderState` variable. By explicilty passing a
`State` parameter, we can begin to eliminate the usage of the global
`modload.LoaderState`.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/run
rf 'inject modload.LoaderState runRun'
cd ..
./rf-cleanup.zsh
Change-Id: I337323c087ed4e43af28973fad27152791eefbc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/698063
TryBot-Bypass: Ian Alexander <jitsu@google.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change replaces most occurrences (in code as well as in comments) of
errors.As with errors.AsType. It leaves the errors package and vendored
code untouched.
Change-Id: I3bde73f318a0b408bdb8f5a251494af15a13118a
GitHub-Last-Rev: 8aaaa36a5a
GitHub-Pull-Request: golang/go#75698
Reviewed-on: https://go-review.googlesource.com/c/go/+/708495
Auto-Submit: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This commit refactors usage of the global variable `RootMode` to the
global LoaderState variable of the same name.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'mv State.rootMode State.RootMode'
for dir in load modcmd run tool toolchain work ; do
cd ../${dir}
rf 'ex {
import "cmd/go/internal/modload";
modload.RootMode -> modload.LoaderState.RootMode
}'
done
cd ../modload
rf 'ex { RootMode -> LoaderState.RootMode }'
rf 'add State.ForceUseModules \
// RootMode determines whether a module root is needed.'
rf 'rm RootMode'
Change-Id: Ib5e513ee570dfc3b01cc974fe32944e5e391fd82
Reviewed-on: https://go-review.googlesource.com/c/go/+/698058
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This commit refactors usage of the global variable `ForceUseModules`
to the global LoaderState field of the same name.
This commit is part of the overall effort to eliminate global
modloader state.
[git-generate]
cd src/cmd/go/internal/modload
rf 'mv State.forceUseModules State.ForceUseModules'
rf 'ex { ForceUseModules -> LoaderState.ForceUseModules }'
for dir in load modcmd modget run toolchain work workcmd ; do
cd ../${dir}
rf 'ex {
import "cmd/go/internal/modload";
modload.ForceUseModules -> modload.LoaderState.ForceUseModules
}'
done
cd ../modload
rf 'add State.initialized \
// ForceUseModules may be set to force modules to be enabled when\
// GO111MODULE=auto or to report an error when GO111MODULE=off.'
rf 'rm ForceUseModules'
Change-Id: Ibdecfd273ff672516c9eb86279e5dfc6cdecb2ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/698057
Reviewed-by: Michael Matloob <matloob@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This enables support for the race detector on linux/riscv64.
Fixes#64345
Cq-Include-Trybots: luci.golang.try:gotip-linux-riscv64
Change-Id: I98962827e91455404858549b0f9691ee438f104b
Reviewed-on: https://go-review.googlesource.com/c/go/+/690497
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
The go command assumes that GOMODCACHE is immutable. As an example of
one place the assumption is made, the modindex won't stat the files in
GOMODCACHE when getting the cache key for the index entry and just uses
the path of the module in the modcache (basically the module's name and
version). Explicitly reject overlays affecting GOMODCACHE to avoid
surprising and incorrect behavior.
For #71783
For #71075
Change-Id: I21dd5d39d71037de473b09ac8482a1867864e11f
Reviewed-on: https://go-review.googlesource.com/c/go/+/650475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
The coverageredesign experiment was turned on by default by
CL 436236 in September, 2022. We've documented it and people
are using it. This CL removes the ability to turn off the experiment.
This removes some old code that is no longer being executed.
For #51430
Change-Id: I88d4998c8b5ea98eef8145d7ca6ebd96f64fbc2b
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-darwin-amd64-longtest,gotip-linux-arm64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/644997
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Commit-Queue: Ian Lance Taylor <iant@google.com>
This adds support for a "-json" flag in all build-related go
subcommands. This causes build output and build failures to be
reported to stdout in a machine-readable way.
For #62067.
Fixes#23037.
Change-Id: Id045c5bd5dde9d16cc09dde6248a4b9637896a30
Reviewed-on: https://go-review.googlesource.com/c/go/+/536397
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Sort the table of variables in the envcmd source code,
because all tables in all source code should be sorted
unless there's a reason they can't be.
Sort the go env output as well.
Sort the flag registrations, same reason.
Remove redundant range variable.
Change-Id: I5f1af3e22a09621706eb57c369bd2675b754b063
Reviewed-on: https://go-review.googlesource.com/c/go/+/627476
Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change amends the long-form help output for 'go help build' and
'go help testflag' to specify that the '-coverpkg' flag operates
explicitly on import paths as well as package names. Import paths are
fundamental for precise specification of packages versus unqualified
package names, and the naming of the flag '-coverpkg' and its original
documentation leads a user to assume that it only operates on the
simple, unqualified package name form. The situation warrants
clarification.
Fixes#69653
Change-Id: Ifde6a974405ce1614e28898fc2b92ed5bad94e57
GitHub-Last-Rev: 466c662a70
GitHub-Pull-Request: golang/go#69655
Reviewed-on: https://go-review.googlesource.com/c/go/+/616257
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Lift out the LookPath cached lookup utility function into a separate
"cmd/internal/pathcache" package, so that it can be reused in other
commands in addition to cmd/go. No change in functionality.
Change-Id: Ica7fa627000843360c3e353d40a9a70605fbe033
Reviewed-on: https://go-review.googlesource.com/c/go/+/601479
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The existing documentation for `go help build` does not match the current behavior of `go build`. This commit fixes inconsistency between documentation and behavior as suggested in #60836 ticket.
Fixes#60836
Change-Id: I22f24f84815f50fecfa8c51b7f1c24e8e0cd8bc8
GitHub-Last-Rev: 7613930a3d
GitHub-Pull-Request: golang/go#61438
Reviewed-on: https://go-review.googlesource.com/c/go/+/511015
Reviewed-by: qiulaidongfeng <2645477756@qq.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The recently released llvm-16/LoongArch already supports the asan feature;
but gcc13/LoongArch does not yet fully support the asan feature, and asan
will be fully supported in gcc14.
Change-Id: I48a65f2f10e3dc488acd9c02ea1a1f37de192be0
Reviewed-on: https://go-review.googlesource.com/c/go/+/481317
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Meidan Li <limeidan@loongson.cn>
TryBot-Result: Gopher Robot <gobot@golang.org>
Commit-Queue: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The msan feature depends on llvm. The currently released llvm-16
already supports the LoongArch architecture, and msan's support
for LoongArch64 has been added in this patch[1], and it has been
merged in branches main and release/17.x.
[1]: https://reviews.llvm.org/D140528
Change-Id: If537c5ffb1c9d4b3316b9b3794d411953bc5764b
Reviewed-on: https://go-review.googlesource.com/c/go/+/481315
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: abner chenc <chenguoqi@loongson.cn>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: WANG Xuerui <git@xen0n.name>
The -C dir flag was added in Go 1.20.
This CL adds a new restriction: the -C must appear as the first flag on the command line.
This restriction makes finding the -C flag robust and matches the general way
people tend to think about and use the -C flag anyway.
It may break a few scripts that have been written since Go 1.20
but hopefully they will not be hard to find and fix.
(There is no strict compatibility guarantee for the command line.)
For #57001.
Change-Id: Ice2e5982c58d41eabdaef42a80d3624cde2c9873
Reviewed-on: https://go-review.googlesource.com/c/go/+/500915
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Many many places in the go command use
base.Errorf("go: %v", err)
or
base.Fatalf("go: %v", err)
Introduce Error(error) and Fatal(error) to do this
and update all call sites (global search and replace).
The new Error gives us the opportunity to unwrap
a multierror and add the go prefix to each line,
which is the motivation for this change.
(We want to start returning a multierror from LoadModFile
and LoadModGraph.)
For #57001.
Change-Id: I9613653b94808224146077c30d22f814d4e19eed
Reviewed-on: https://go-review.googlesource.com/c/go/+/499980
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Cover flag documentation was not up to date, and the -covermode flag
documentation was missing.
Fixes#60438
Change-Id: I11e769fa2a32d074de7a748aa534afdfe2ca4e78
Reviewed-on: https://go-review.googlesource.com/c/go/+/498415
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Clean up Go version comparison.
CL 494436 added an ad hoc version comparison for the toolchain switch.
There are also other version comparisons scattered throughout the code,
assuming that using semver.Compare with a "v" prefix gives the right answer.
As we start to allow versions like "go 1.21rc1" in the go.mod file,
those comparisons will not work properly.
A future CL will need to inject Go versions into semver for use with MVS,
so do what Bryan suggested in the review of CL 494436 and rewrite the
comparison in terms of that conversion.
For #57001.
Change-Id: Ia1d441f1bc259874c6c1b3b9349bdf9823a707d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/496735
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
The runtime/trace package proved useful for investigating go command
performance, and it makes sense (to me) to make this available for
development behind an undocumented flag, at the cost of ~25KB of binary
size. We could of course futher hide this functionality behind an
experiment or build tag, if necessary.
Updates #59157
Change-Id: I612320920ca935f1ee10bb6a803b7952f36c939b
Reviewed-on: https://go-review.googlesource.com/c/go/+/477896
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
In -pgo=auto mode, the go command finds a profile named
default.pgo in the main package's directly, and if found, use it
as the profile for the build. Currently we only support a single
main package when -pgo=auto is used.
When multiple main packages are included in a build, they may
have different default profiles (or some have profiles whereas
some don't), so a common dependent package would need to be built
multiple times, with different profiles (or lack of). This CL
handles this. To do so, we need to split (unshare) the dependency
graph so they can attach different profiles.
Fixes#58099.
Change-Id: I1ad21361967aafbf5089d8d5e89229f95fe31276
Reviewed-on: https://go-review.googlesource.com/c/go/+/472358
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
At the moment the only documentation is the release notes,
but everything mentioned in the release notes should have
proper documentation separate from them.
Change-Id: I9885962f6c6d947039b0be59b608385781479271
Reviewed-on: https://go-review.googlesource.com/c/go/+/462196
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Add "auto" mode for the -pgo build flag. When -pgo=auto is
specified, if there is a default.pgo file in the directory of the
main package, it will be selected and used for the build.
Currently it requires exactly one main package when -pgo=auto is
specified. (We'll support multiple main packages in the future.)
Also apply to other build-related subcommands, "go install", "go
run", "go test", and "go list".
For #55022.
Change-Id: Iab7974ab8932daf0e83506de505e044a8e412466
Reviewed-on: https://go-review.googlesource.com/c/go/+/438737
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
The "go test" and "go build" commands have special-case behavior when
passed "-o /dev/null". These checks are case-sensitive and assume that
os.DevNull is an absolute path. Windows filesystems are case-insensitive
and os.DevNull is NUL, which is not an absolute path.
CL 145220 changed filepath.IsAbs to report "NUL" as absolute to work
around this issue; that change is being rolled back and a better fix here
is to compare the value of -o against os.DevNull before attempting to
merge it with a base path. Make that fix.
On Windows, accept any capitilization of "NUL" as the null device.
This change doesn't cover every possible name for the null device, such
as "-o //./NUL", but this test is for efficiency rather than correctness.
Accepting just the most common name is fine.
For #56217.
Change-Id: I60b59b671789fc456074d3c8bc755a74ea8d5765
Reviewed-on: https://go-review.googlesource.com/c/go/+/449117
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Instead of hardcoding the set of five packages that depend on cgo to
decide whether a package should have an install target, make the
decision based on whether the package has any CgoFiles. This means that
in nocgo configurations, there will be no installed packages, and that
if an GOOS/GOARCH combination doesn't have cgo files we don't
unnecessarily install a .a.
Because the determination of whether a file is a CgoFile is made later
in the Import functions, the choice of whether to add a PkgObj for teh
case there are CgoFiles is moved later. One concern here is that in some
cases, PkgObj may be set differently in the case of the FindOnly mode,
since the determination is moved across the boundary. We might want
to always set PkgObj after the FindOnly boundary for consistency? cmd/go
doesn't seem to use it when calling Import with FindOnly.
Also remove internal/buildinternal/needs_install.go because we will be
checking whether to install based on the number of cgo files and it
might be overkill to make the NeedsInstalledDotA function be the
equivalent of len(input) > 0.
For #47257
Change-Id: I5f7f2137dc99aaeb2e2695c14e0222093a6b2407
Reviewed-on: https://go-review.googlesource.com/c/go/+/448803
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Add a -pgo flag for "go build" (and other build actions), to
specify the file path of a profile used for PGO. Special name
"off" turns off PGO.
The given profile path is passed to the compiler.
The build cache is sensitive to the content of the given PGO
profile.
TODO: auto mode.
For #55022.
Change-Id: Ieee1b131b4c041f9502fd0a1acf112f3e44246be
Reviewed-on: https://go-review.googlesource.com/c/go/+/438736
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
The -C flag is like tar -C or make -C: it changes to the named directory
early in command startup, before anything else happens.
Fixes#50332.
Change-Id: I8e4546f69044cb3a028d4d26dfba482b08cb845d
Reviewed-on: https://go-review.googlesource.com/c/go/+/421436
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Packages in GOROOT that don't use cgo will not be installed in
GOROOT/pkg, and will instead be cached as usual like other Go
packages.
- add a internal/buildinternal package to hold the identities of the
five packages that use cgo
- update dist's test code to do a go build std cmd before checking
staleness on builders. Because most of those packages no longer have
install locations, and have dependencies that don't either, the
packages need to be cached to not be stale.
- fix index_test to import packages with the path "." when preparing
the "want" values to compare the indexed data to. (the module index
matches the behavior of build.ImportDir, which always passes in "."
as the path.
- In both the index and go/build Importers, don't set
PkgObj for GOROOT packages which will no longer have install
targets. PkgTargetRoot will still be set to compute target paths,
which will still be needed in buildmode=shared.
- "downgrade" all install actions that don't have a target to build
actions. (The target should already not be set for packages that
shouldn't be installed).
For #47257
Change-Id: Ia5aee6b3b20b58e028119cf0352a4c4a2f10f6b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/432535
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Enable -msan flag on freebsd/amd64 and amend PIE comment in
internal/work/init.go to indicate that MSAN requires PIE on all platforms
except linux/amd64.
R=go1.20
For #53298
Change-Id: I93d94efa95d7f292c23c433fb1d3f4301d820bde
Reviewed-on: https://go-review.googlesource.com/c/go/+/411275
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The flag is now removed from `go build` and `go test`.
It has been deprecated since Go 1.16, printing a warning message.
The idea was to fully delete it in Go 1.17, but that didn't happen.
First, delete the BuildI variable and its flag declarations,
as well as all the bits of docs that mentioned the flag.
Second, delete or simplify the code paths that used BuildI.
Third, adapt the tests to the removed flag.
Some of them are removed, like test_relative_import_dash_i.txt and
TestGoTestDashIDashOWritesBinary, as they centered around the flag.
The rest are modified to not cover or use the flag.
Finally, change cmd/dist to no longer use `go install -i`.
The purpose of the flag was that, when bootstrapping the toolchain,
all of its dependencies would also be installed as object files.
When removing the use of the -i flags, the checkNotStale call right
after building toolchain3 would fail as expected,
because runtime/internal/sys is now only up to date in the build cache.
Luckily, that's not a problem: we run `go install std cmd` right after,
so all standard library packages will be installed as object files.
Move the checkNotStale call after that install command.
Fixes#41696.
Change-Id: I5d8139f18aaee07da886d483e663f3f2f00d5f3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/416094
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gopher Robot <gobot@golang.org>
If GOEXPERIMENT=coverageredesign is in effect, introduce a new
top-level '-cover' option to "go build" to turn on new-style hybrid
code coverage instrumentation. Similarly, use the new instrumentation
for "go test -cover".
The main effects of "-cover" under the hood are to instrument files at
the package level using cmd/cover and to pass additional options to
the compiler when building instrumented packages.
The previous workflow for "go tool -cover mypkg" would expand to a
series of "go tool cover" commands (one per file) followed by a single
package compilation command to build the rewritten sources.
With the new workflow, the Go command will pass all of the Go files in
a package to the cover tool as a chunk (along with a config file
containing other parameters), then the cover tool will write
instrumented versions of the sources along with another "output"
config with info on coverage variable names for the the compiler. The
Go command will then kick off the compiler on the modified source
files, also passing in the config file generated by cmd/cover.
Updates #51430.
Change-Id: Id65621ff6a8c70a30168c1412c2d6f805ff3b9e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/355452
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Ever since 'go build' was added (in CL 5483069), it has used an atexit
handler to clean up working directories. At some point (prior to CL
95900044), Init was called multiple times per builder, registering
potentially many atexit handlers that execute asynchronously and make
debugging more difficult.
The use of an AtExit handler also makes the Builder (and anything that
uses it) prone to races: the base.AtExit API is not designed for
concurrent use, but cmd/go is becoming increasingly concurrent over
time. The AtExit handler also makes the Builder inappropriate to use
within a unit-test, since the handlers do not run during the test
function and accumulate over time.
This change makes NewBuilder safe for concurrent use by registering
the AtExit handler only once (during BuildInit, which was already not
safe for concurrent use), and using a sync.Map to store the set of
builders that need cleanup in case of an unclean exit. In addition, it
causes the test variant of cmd/go to fail if any Builder instance
leaks from a clean exit, helping to ensure that functions that create
Builders do not leak them indefinitely, especially in tests.
Updates #54423.
Change-Id: Ia227b15b8fa53c33177c71271d756ac0858feebe
Reviewed-on: https://go-review.googlesource.com/c/go/+/425254
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Ever since 'go build' was added (in CL 5483069), it has used an atexit
handler to clean up working directories.
CL 154109 introduced 'cc' command to the script test framework that
called Init on a builder once per invocation. Unfortunately, since
base.AtExit is unsynchronized, the Init added there caused any script
that invokes that command to be unsafe for concurrent use.
This change fixes the race by having the 'cc' command pass in its
working directory instead of allowing the Builder to allocate one.
Following modern Go best practices, it also replaces the in-place Init
method (which is prone to typestate and aliasing bugs) with a
NewBuilder constructor function.
Fixes#54423.
Change-Id: I8fc2127a7d877bb39a1174e398736bb51d03d4d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/425205
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
(But still not when -buildvcs=auto, the default.)
Fixes#52648.
Change-Id: I87a87d4ea84e8bf9635a4f7c8674c9311c3e21be
Reviewed-on: https://go-review.googlesource.com/c/go/+/409177
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Clarify that the //go:build line is an expression of constraints,
not a constraint itself.
Fixes#53308
Change-Id: Ib67243c6ee5cfe3b688c12b943b5e7496f686035
Reviewed-on: https://go-review.googlesource.com/c/go/+/411697
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: David Chase <drchase@google.com>
With this patch, -asan option can detect the error memory
access to global variables.
So this patch makes a few changes:
1. Add the asanregisterglobals runtime support function,
which calls asan runtime function _asan_register_globals
to register global variables.
2. Create a new initialization function for the package
being compiled. This function initializes an array of
instrumented global variables and pass it to function
runtime.asanregisterglobals. An instrumented global
variable has trailing redzone.
3. Writes the new size of instrumented global variables
that have trailing redzones into object file.
4. Notice that the current implementation is only compatible with
the ASan library from version v7 to v9. Therefore, using the
-asan option requires that the gcc version is not less than 7
and the clang version is less than 4, otherwise a segmentation
fault will occur. So this patch adds a check on whether the compiler
being used is a supported version in cmd/go.
(This is a redo of CL 401775 with a fix for a build break due to an
intervening commit that removed the internal/execabs package.)
Updates #44853.
Change-Id: I719d4ef2b22cb2d5516e1494cd453c3efb47d6c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/403851
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
With this patch, -asan option can detect the error memory
access to global variables.
So this patch makes a few changes:
1. Add the asanregisterglobals runtime support function,
which calls asan runtime function _asan_register_globals
to register global variables.
2. Create a new initialization function for the package
being compiled. This function initializes an array of
instrumented global variables and pass it to function
runtime.asanregisterglobals. An instrumented global
variable has trailing redzone.
3. Writes the new size of instrumented global variables
that have trailing redzones into object file.
4. Notice that the current implementation is only compatible with
the ASan library from version v7 to v9. Therefore, using the
-asan option requires that the gcc version is not less than 7
and the clang version is less than 4, otherwise a segmentation
fault will occur. So this patch adds a check on whether the compiler
being used is a supported version in cmd/go.
Updates #44853.
Change-Id: Ib877a817209ab2be68a8e22c418fe4a4a20880fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/401775
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We added internal/execabs back in January 2021 in order to fix
a security problem caused by os/exec's handling of the current
directory. Now that os/exec has that code, internal/execabs is
superfluous and can be deleted.
This commit rewrites all the imports back to os/exec and
deletes internal/execabs.
For #43724.
Change-Id: Ib9736baf978be2afd42a1225e2ab3fd5d33d19df
Reviewed-on: https://go-review.googlesource.com/c/go/+/381375
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
With this patch, -asan option can detect the error memory
access to global variables.
So this patch makes a few changes:
1. Add the asanregisterglobals runtime support function,
which calls asan runtime function _asan_register_globals
to register global variables.
2. Create a new initialization function for the package
being compiled. This function initializes an array of
instrumented global variables and pass it to function
runtime.asanregisterglobals. An instrumented global
variable has trailing redzone.
3. Writes the new size of instrumented global variables
that have trailing redzones into object file.
4. Notice that the current implementation is only compatible with
the ASan library from version v7 to v9. Therefore, using the
-asan option requires that the gcc version is not less than 7
and the clang version is less than 4, otherwise a segmentation
fault will occur. So this patch adds a check on whether the compiler
being used is a supported version in cmd/go.
Change-Id: I664e74dcabf5dc7ed46802859174606454e8f1d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/321715
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Fannie Zhang <Fannie.Zhang@arm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
When we added VCS stamping in the Go 1.18 release, we defaulted to
-buildvcs=true, on the theory that most folks will actually want VCS
information stamped.
We also made -buildvcs=true error out if a VCS directory is found and
no VCS tool is available, on the theory that a user who builds with
'-buildvcs=true' will be very surprised if the VCS metadata is
silently missing.
However, that causes a problem for CI environments that don't have the
appropriate VCS tool installed. (And we know that's a common situation
because we're in that situation ourselves — see #46693!)
The new '-buildvcs=auto' setting provides a middle ground: it stamps
VCS information by default when the tool is present (and reports
explicit errors if the tool errors out), but omits the metadata
when the tool isn't present at all.
Fixes#51748.
Updates #51999.
Change-Id: Iebc955c2af0abca9b7517f62ca48b1d944eb2df4
Reviewed-on: https://go-review.googlesource.com/c/go/+/398855
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
