Please sign in to comment.
cmd/go: switch to entirely content-based staleness determination
This CL changes the go command to base all its rebuilding decisions on the content of the files being processed and not their file system modification times. It also eliminates the special handling of release toolchains, which were previously considered always up-to-date because modification time order could not be trusted when unpacking a pre-built release. The go command previously tracked "build IDs" as a backup to modification times, to catch changes not reflected in modification times. For example, if you remove one .go file in a package with multiple .go files, there is no modification time remaining in the system that indicates that the installed package is out of date. The old build ID was the hash of a list of file names and a few other factors, expected to change if those factors changed. This CL moves to using this kind of build ID as the only way to detect staleness, making sure that the build ID hash includes all possible factors that need to influence the rebuild decision. One such factor is the compiler flags. As of this CL, if you run go build -gcflags -N cmd/gofmt you will get a gofmt where every package is built with -N, regardless of what may or may not be installed already. Another such factor is the linker flags. As of this CL, if you run go install myprog go install -ldflags=-s myprog the second go install will now correctly build a new myprog with the updated linker flags. (Previously the installed myprog appeared up-to-date, because the ldflags were not included in the build ID.) Because we have more precise information we can also validate whether the target of a "go test -c" operation is already the right binary and therefore can avoid a rebuild. This CL sets us up for having a more general build artifact cache, maybe even a step toward not having a pkg directory with .a files, but this CL does not take that step. For now the result of go install is the same as it ever was; we just do a better job of what needs to be installed. This CL does slow down builds a small amount by reading all the dependent source files in full. (The go command already read the beginning of every dependent source file to discover build tags and imports.) On my MacBook Pro, before this CL all.bash takes 3m58s, while after this CL and a few optimizations stacked above it all.bash takes 4m28s. Given that CL 73850 cut 1m43s off the all.bash time earlier today, we can afford adding 30s back for now. More optimizations are planned that should make the go command more efficient than it was even before this CL. Fixes #15799. Fixes #18369. Fixes #19340. Fixes #21477. Change-Id: I10d7ca0e31ca3f58aabb9b1f11e2e3d9d18f0bc9 Reviewed-on: https://go-review.googlesource.com/73212 Run-TryBot: Russ Cox <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: David Crawshaw <firstname.lastname@example.org>
- Loading branch information...
Showing with 1,003 additions and 921 deletions.
- +1 −0 misc/cgo/testshared/shared_test.go
- +112 −44 src/cmd/dist/build.go
- +1 −1 src/cmd/dist/buildtool.go
- +48 −44 src/cmd/dist/deps.go
- +5 −1 src/cmd/dist/test.go
- +26 −33 src/cmd/go/go_test.go
- +1 −1 src/cmd/go/internal/cache/hash.go
- +20 −3 src/cmd/go/internal/list/list.go
- +9 −552 src/cmd/go/internal/load/pkg.go
- +0 −21 src/cmd/go/internal/load/testgo.go
- +5 −15 src/cmd/go/internal/test/test.go
- +50 −92 src/cmd/go/internal/work/action.go
- +0 −3 src/cmd/go/internal/work/build.go
- +397 −0 src/cmd/go/internal/work/buildid.go
- +313 −102 src/cmd/go/internal/work/exec.go
- +9 −4 src/cmd/go/internal/work/gc.go
- +1 −0 src/cmd/internal/objabi/flag.go
- +5 −5 test/inline_callers.go
Oops, something went wrong.