aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/go/internal/modcmd/why.go
AgeCommit message (Collapse)Author
2021-07-26[dev.cmdgo] cmd/go: add the workspace modeMichael Matloob
This change adds the outline of the implementation of the workspace mode. The go command will now locate go.work files, and read them to determine which modules are in the workspace. It will then put those modules in the root of the workspace when building the build list. It supports building, running, testing, and listing in workspaces. There are still many TODOs for undone work and other changes to fix certain cases. Some of these undone parts include: replaces and go.work.sum files, as well as go mod {test,why,verify}, excludes in workspaces, updating work files to include module names in comments and setting the GOWORK variable. For #45713 Change-Id: I72716af7a300a2896087fc8a79c04e951d248278 Reviewed-on: https://go-review.googlesource.com/c/go/+/334934 Trust: Michael Matloob <matloob@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2021-04-27cmd/go/internal/modload: clean up error reportingBryan C. Mills
• Consolidate 'if ld.AllowErrors' conditions into an 'ld.errorf' method. • Rename SilenceErrors to SilencePackageErrors and clarify its documentation. (There is currently no way to silence errors in the module graph. Perhaps we should add one, but for now let's at least clarify the existing behavior.) • Move 'tidy -v' verbose logging into LoadPackages, where other logging happens. • Make checkMultiplePaths a loader method (since it only matters during package loading anyway). • Check package and module-graph errors in loadFromRoots instead of LoadPackages. These checks were previously omitted on the ImportFromFiles path, which seems likely to be a bug. (We now suppress package errors explicitly in ImportFromFiles, which at least makes the bug more explicit.) This somewhat simplifies the code structure in preparation for the lazy-mode tidy implementation. For #36460 Change-Id: I3ce3586c6934989d5194f00f99e7cc4423cf767f Reviewed-on: https://go-review.googlesource.com/c/go/+/313229 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
2021-04-05cmd/go: refactor modload.ListModules to accept bit flagsJay Conrod
Instead of accepting bool flags, ListModules now accepts ListMode, a set of bit flags. Four flags are defined. listRetracted is split into ListRetracted and ListRetractedVersion to avoid ambiguity with -u, -retracted, and -versions. For #40357 Change-Id: Ibbbe44dc1e285ed17f27a6581f3392679f2124fb Reviewed-on: https://go-review.googlesource.com/c/go/+/306331 Trust: Jay Conrod <jayconrod@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
2021-03-25cmd/go/internal/modload: replace the global buildList with structured ↵Bryan C. Mills
requirements This is intended to be a pure-refactoring change, with very little observable change in the behavior of the 'go' command. A few error messages have prefixes changed (by virtue of being attached to packages or modules instead of the build list overall), and 'go list -m' (without arguments) no longer loads the complete module graph in order to provide the name of the (local) main module. The previous modload.buildList variable contained a flattened build list, from which the go.mod file was reconstructed using various heuristics and metadata cobbled together from the original go.mod file, the package loader (which was occasionally constructed without actually loading packages, for the sole purpose of populating otherwise-unrelated metadata!), and the updated build list. This change replaces that variable with a new package-level variable, named "requirements". The new variable is structured to match the structure of the go.mod file: it explicitly specifies the roots of the module graph, from which the complete module graph and complete build list can be reconstructed (and cached) on demand. Similarly, the "direct" markings on the go.mod requirements are now stored alongside the requirements themselves, rather than side-channeled through the loader. The requirements are now plumbed explicitly though the modload package, with accesses to the package-level variable occurring only within top-level exported functions. The structured requirements are logically immutable, so a new copy of the requirements is constructed whenever the requirements are changed, substantially reducing implicit communication-by-sharing in the package. For #36460 Updates #40775 Change-Id: I97bb0381708f9d3e42af385b5c88a7038e1f0556 Reviewed-on: https://go-review.googlesource.com/c/go/+/293689 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
2021-03-02cmd/go: resolve std-vendored dependencies as std packages except in 'go get' ↵Bryan C. Mills
and 'go mod' In CL 251159, I removed a hard-coded special case changing the rewriting behavior for std dependencies in GOROOT/src/vendor and GOROOT/src/cmd/vendor. Unfortunately, that caused packages in 'std' to be reported as stale when run within GOROOT/src. This change restores the special-case behavior, but plumbs it through the PackageOpts explicitly instead of comparing strings stored in global variables. Fixes #44725 Change-Id: If084fe74972ce1704715ca79b0b7e092dd90c88b Reviewed-on: https://go-review.googlesource.com/c/go/+/297869 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2021-01-08cmd/go: revise 'go help' documentation for modulesJay Conrod
Module-related help pages now contain a brief summary and point to the reference documentation at golang.org/ref/mod for details. Help pages for commands like 'go get' still describe the basic usage and summarize flags but don't provide as much background detail. Fixes #41427 Fixes #43419 Change-Id: Icacd38e0f33c352c447cc5a496c99674493abde2 Reviewed-on: https://go-review.googlesource.com/c/go/+/282615 Trust: Jay Conrod <jayconrod@google.com> Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-09-22cmd/go: add a '-e' flag to 'mod tidy' and 'mod vendor'Bryan C. Mills
This flag, like the -e flag to 'go list', instructs the command to make a best effort to continue in spite of errors for specific packages. Fixes #26603 Change-Id: I5ee2f50c71870ae8ef3f9b3e5b045474adcca525 Reviewed-on: https://go-review.googlesource.com/c/go/+/255960 Trust: Bryan C. Mills <bcmills@google.com> Trust: Jay Conrod <jayconrod@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-09-22cmd/go/internal/modget: consolidate Load entrypointsBryan C. Mills
This change replaces ImportPaths, ImportPathsQuiet, LoadALL, and LoadVendor with a single LoadPackages function, with a LoadOpts struct that more clearly documents the variations in behavior. It also eliminates the cmd/go/internal/load.ImportPaths function, which was undocumented and had only one call site (within its own package). The modload.LoadTests global variable is subsumed by a field in the new LoadOpts struct, and is no longer needed for callers that invoke LoadPackages directly. It has been (temporarily) replaced with a similar global variable, load.ModResolveTests, which can itself be converted to an explicit, local argument. For #37438 For #36460 Updates #40775 Fixes #26977 Change-Id: I4fb6086c01b04de829d98875db19cf0118d40f8c Reviewed-on: https://go-review.googlesource.com/c/go/+/255938 Trust: Bryan C. Mills <bcmills@google.com> Trust: Jay Conrod <jayconrod@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-09-15cmd/go: add modload.NeedRoot mode for commands that need module rootJay Conrod
This makes error reporting a bit more consistent for 'go mod' subcommands. Most of these commands only work in module mode when a go.mod file is present. Setting modload.ForceUseModules reports an error when GO111MODULE=off. Setting modload.RootMode to modload.NeedRoot reports an error when no go.mod file is present. Change-Id: I1daa8d2971cb8658e0c804765839d903734a412e Reviewed-on: https://go-review.googlesource.com/c/go/+/254369 Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
2020-09-11cmd/go: refactor -mod flag parsingJay Conrod
Keep track of whether the -mod flag was set explicitly. When -mod=readonly is the default, we'll want to adjust our error messages if it's set explicitly. Also, register the -mod, -modcacherw, and -modfile flags in functions in internal/base instead of internal/work. 'go mod' commands that don't load packages shouldn't depend on internal/work. For #40728 Change-Id: I272aea9e19908ba37e151baac4ea8630e90f241f Reviewed-on: https://go-review.googlesource.com/c/go/+/253744 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-09-09cmd/go/internal/modload: implement the "all" pattern for lazy loadingBryan C. Mills
The new semantics of the "all" package pattern can be implemented without actually changing module loading per se. This change implements those semantics, so that the change can be decoupled from the changes to the module requirement graph. For #36460 Change-Id: I0ee8b17afa8b728dc470a42a540fcc01764a4442 Reviewed-on: https://go-review.googlesource.com/c/go/+/240623 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Michael Matloob <matloob@golang.org>
2020-08-26cmd/go: add -retracted flag to 'go list'Jay Conrod
The -retracted flag causes 'go list' to load information about retracted module module versions. When -retracted is used with -f or -json, the Retracted field is set to a string containing the reason for the retraction on retracted module versions. The string is based on comments on the retract directive. This field is also populated when the -u flag is used. When -retracted is used with -versions, retracted versions are shown. Normally, they are omitted. For #24031 Change-Id: Ic13d516eddffb1b8404e21034f78cecc9896d1b8 Reviewed-on: https://go-review.googlesource.com/c/go/+/228382 Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-08-20cmd/go: do context propagation for tracing downloadsMichael Matloob
This change does context propagation (and only context propagation) necessary to add context to modfetch.Download and pkg.LoadImport. This was done by adding context to their callers, and then adding context to all call-sites, and then repeating adding context to callers of those enclosing functions and their callers until none were left. In some cases the call graph expansion was pruned by using context.TODOs. The next CL will add a span to Download. I kept it out of this change to avoid making it any larger (and harder to review) than it needs to be. Updates #38714 Change-Id: I7a03416e04a14ca71636d96f2c1bda2c4c30d348 Reviewed-on: https://go-review.googlesource.com/c/go/+/249021 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-08-18cmd/go: revert 3 CLs affecting par.Work, context propagation, tracingDmitri Shuralyov
This reverts the following changes: • cmd/go: add tracing for querying and downloading from the proxy CL 242786, commit 1a3558341860357c2400e37773e5076bb3a51628 • cmd/go: do context propagation for tracing downloads CL 248327, commit c0cf190d226cc3defb71d17c01d0b45bf49a8a85 • cmd/go/internal: remove some users of par.Work CL 248326, commit f30044a03bc7cf107dbec03c02fb6d0072878252 Reason for revert: broke linux 386 and amd64 longtest builders. The problem started with CL 248326, but CL 248327 and CL 242786 are reverted as well due to conflicts. Updates #38714. Fixes #40861. Change-Id: I68496b4e5a27e47a42183553c3a645b288edac83 Reviewed-on: https://go-review.googlesource.com/c/go/+/249017 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-08-17cmd/go: do context propagation for tracing downloadsMichael Matloob
This change does context propagation (and only context propagation) necessary to add context to modfetch.Download and pkg.LoadImport. This was done by adding context to their callers, and then adding context to all call-sites, and then repeating adding context to callers of those enclosing functions and their callers until none were left. In some cases the call graph expansion was pruned by using context.TODOs. The next CL will add a span to Download. I kept it out of this change to avoid making it any larger (and harder to review) than it needs to be. Updates #38714 Change-Id: I5bf2d599aafef67334c384dfccd5e255198c85b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/248327 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-08-17cmd/go: add span for modload.LoadBuildListMichael Matloob
This change adds context, and a span to modload.LoadBuildList and propagates context into modload.BuildList. It's the start of a run of CLs to add trace spans for module operations. Updates #38714 Change-Id: I0d58dd394051526338092dc9a5ec29a9e087e4e4 Reviewed-on: https://go-review.googlesource.com/c/go/+/248325 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-08-12cmd/go: add Context parameter to base.command.RunMichael Matloob
One small step to start propagating the context in cmd/go for tracing purposes. Updates #38714 Change-Id: Ibb6debeb9233f84d55f0e81244487355cbe7b82c Reviewed-on: https://go-review.googlesource.com/c/go/+/237684 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-10-29cmd/go: delete internal packages moved to x/modJay Conrod
This change deletes several internal packages, replaces imports to them with the equivalent golang.org/x/mod packages, updates x/mod, and re-runs 'go mod vendor'. Packages are replaced as follows: cmd/go/internal/modfile → golang.org/x/mod/modfile cmd/go/internal/module → golang.org/x/mod/module cmd/go/internal/semver → golang.org/x/mod/semver cmd/go/internal/sumdb → golang.org/x/mod/sumdb cmd/go/internal/dirhash → golang.org/x/mod/sumdb/dirhash cmd/go/internal/note → golang.org/x/mod/sumdb/note cmd/go/internal/tlog → golang.org/x/mod/sumdb/tlog Updates #31761 Fixes #34924 Change-Id: Ie3bf677bb0be49af969f654a0214243a6547eb57 Reviewed-on: https://go-review.googlesource.com/c/go/+/202698 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-10-22cmd/go: support -modcacherw in 'go mod' subcommandsJay Conrod
The -modcacherw flag is now registered in work.AddModCommonFlags, which is called from work.AddBuildFlags, where it was registered before. 'go mod' subcommands register the flag by calling work.AddModCommonFlags directly. Also, build commands now exit with an error if -modcacherw is set explicitly (not in GOFLAGS) in GOPATH mode. Updates #31481 Change-Id: I461e59a51ed31b006fff4d5c57c2a866be0bbf38 Reviewed-on: https://go-review.googlesource.com/c/go/+/202563 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2018-08-17cmd/go: distinguish patterns from the results of matching themRuss Cox
To date the go command has always just treated the command line package patterns as a []string, expanded by pattern matching into another []string. As a result, the code is not always clear about whether a particular []string contains patterns or results. A few different important bugs are caused by not keeping this distinction clear enough. This CL sets us up well for fixing those, by introducing an explicit search.Match struct holding the results of matching a single pattern. The added clarity here also makes it clear how to avoid duplicate warnings about unmatched packages. Fixes #26925. (Test in followup CL.) Change-Id: Ic2f0606f7ab8b3734a40e22d3cb1e6f58d031061 Reviewed-on: https://go-review.googlesource.com/129058 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
2018-08-10cmd/go: add go mod whyRuss Cox
A very common question is "why is this package or module being kept by go mod vendor or go mod tidy?" go mod why answers that question. Fixes #26620. Change-Id: Iac3b6bbdf703b4784f5eed8e0f69d41325bc6d7f Reviewed-on: https://go-review.googlesource.com/128359 Reviewed-by: Bryan C. Mills <bcmills@google.com>