|author||Russ Cox <firstname.lastname@example.org>||Fri Jun 22 12:08:49 2018 -0400|
|committer||Russ Cox <email@example.com>||Tue Jul 10 05:41:16 2018 +0000|
cmd/go/internal/vgo: load packages in parallel This is a large CL. The best way to read it is probably to treat vgo/load.go as if it were a newly-written file, not by reading diffs. The main motivation here is to do package loading in parallel, including the on-demand downloading of dependency zip files. Running the load in parallel requires making the structure a bit cleaner than it was before: the old recursive traversal could retraverse sections of the graph if it decided that now it needed tests and their dependencies, and so on. To parallelize, the work had to be split up into items visited exactly once, and the result is a bit cleaner. Most of vgo/search.go has been absorbed into load.go's ImportPaths. Previously, there was an odd recursion where ImportPaths's loader callback could call into MatchAll/MatchALL, which created and ran a new loader before returning back to the original loader's callback. The new structure more properly expresses the dependency of the loader on matching, which in turn depends on the current state of the loader (namely buildList). The magic "ALL" package pattern is gone. Code that needs that functionality now has a proper entry point (vgo.LoadALL). Finally, isolate all the "what happened?" loader state consulted after the fact into a single struct. The build list remains separate, at least for now. The cleaner structure sets us up well for the next CL. Fixes golang/go#25162. Change-Id: I963f0effd7314f7e77eaad058774dbd2586c9cd2 Reviewed-on: https://go-review.googlesource.com/121303 Reviewed-by: Bryan C. Mills <firstname.lastname@example.org>
This repository holds a prototype of what the go command might look like with integrated support for package versioning.
See research.swtch.com/vgo for documents about the design.
go get -u golang.org/x/vgo.
You can also manually git clone the repository to
This is still a very early prototype. You are likely to run into bugs. Please file bugs in the main Go issue tracker, golang.org/issue, and put the prefix
x/vgo: in the issue title.