cmd/go/internal/modload: refactor global state into exported struct type

[jayconrod]

The modload package has a lot of global state. In general, variables that are set once during initialization and global caches are fine. But buildList and loader in particular cause problems, since most exported functions either read values out of them or replace and overwrite them. It's frequently not obvious when this is happening.

This leads to some unfortunate situations. For example, see get.go in CL 228383. If modload.ListModules is called before modload.WriteGoMod, the go.mod file will contain spurious // indirect comments. This happens because WriteGoMod uses loaded.direct to decide whether to mark a requirement as indirect, but ListModules calls LoadBuildList, which replaces loaded, so it appears that nothing is directly required.

I think these side effects should be more obvious to callers, and the loaded and buildList variables should be removed. Instead, the loader struct type should be exported, and exported functions that create, read, or write it should be converted to methods.

[jayconrod]

Another problem to add: PackageModuleInfo returns a new *modinfo.ModulePublic on every call. It would be nice for packages from the same module to share the same instance. This would require adding state to loaded, which I'd rather not do until this is improved.

[jayconrod]

Another problem: WriteGoMod is highly sensitive to global state in modload. We should be careful not to call WriteGoMod more than once, since calling it multiple times can result in cosmetic differences in go.mod files, based on which changes were made when.

CL 237017 was a step in this direction, but we should confirm other commands like go get only call WriteGoMod once at the end.

[gopherbot]

Change https://golang.org/cl/249398 mentions this issue: cmd/gorelease: fix brittle test broken by CL 237017

[bcmills]

Unfortunately, the buildList and loader variables basically need to be global as long as GOPATH mode continues to exist: they carry implicit state that would not be practical to thread through the GOPATH-mode loader. (The coupling between the GOPATH load package and the module-mode modload package occurs through callback functions, not explicitly-plumbed variables. Which is maybe fine, because in practice we ~never want two distinct build lists or package graphs.)

In the meantime, it should be possible to address the other symptoms you report without eliminating the globals. (For example, LoadBuildList should probably preserve, rather than discard, the existing direct markings — but I think that particular function will go away with lazy loading anyway.)

[gopherbot]

Change https://golang.org/cl/255938 mentions this issue: cmd/go/internal/modget: consolidate Load entrypoints

[gopherbot]

Change https://golang.org/cl/261640 mentions this issue: cmd/go/internal/modload: avoid using the global build list in QueryPattern

[gopherbot]

Change https://golang.org/cl/272129 mentions this issue: cmd/go/internal/modload: remove the Reqs function

[gopherbot]

Change https://golang.org/cl/293689 mentions this issue: cmd/go/internal/modload: replace the global buildList with structured requirements