aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/go/internal/modload/load.go
AgeCommit message (Collapse)Author
2021-06-02[release-branch.go1.15] cmd/go: error out of 'go mod tidy' if the go version ↵Bryan C. Mills
is newer than supported This backports the test from CL 319669, but — because of extensive changes to the module loader during the Go 1.16 and 1.17 cycles — the implementation is entirely different. (This implementation is based on the addGoStmt function already present in init.go.) Fixes #46143 Updates #46142 Change-Id: Ib7a0a159e53cbe476be6aa9a050add10cc750dec Reviewed-on: https://go-review.googlesource.com/c/go/+/319710 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-03-10[release-branch.go1.15] cmd/go: don't report missing std import errors for ↵Jay Conrod
tidy and vendor 'go mod tidy' and 'go mod vendor' normally report errors when a package can't be imported, even if the import appears in a file that wouldn't be compiled by the current version of Go. These errors are common for packages introduced in higher versions of Go, like "embed" in 1.16. This change causes 'go mod tidy' and 'go mod vendor' to ignore missing package errors if the import path appears to come from the standard library because it lacks a dot in the first path element. NOTE: This change is not a clean cherry-pick of CL 298749 because parts of modload were substantially rewritten after 1.15. Fixes #44792 Updates #27063 Change-Id: I61d6443e77ab95fd8c0d1514f57ef4c8885a77cc Reviewed-on: https://go-review.googlesource.com/c/go/+/298749 Trust: Jay Conrod <jayconrod@google.com> Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> (cherry picked from commit 56d52e661114be60fb1893b034ac0c5976b622af) Reviewed-on: https://go-review.googlesource.com/c/go/+/298950
2020-05-13cmd/go: do not ignore permission errors when matching patternsBryan C. Mills
While reviewing CL 228784, I noticed that various filepath.WalkFunc implementations within cmd/go were dropping non-nil errors. Those errors turn out to be significant, at least in some cases: for example, they can cause packages to appear to be missing when any parent of the directory had the wrong permissions set. (This also turned up a bug in the existing list_dedup_packages test, which was accidentally passing a nonexistent directory instead of the intended duplicate path.) Change-Id: Ia09a0a33aa7a966d9f132d3747d6c674a5370b2d Reviewed-on: https://go-review.googlesource.com/c/go/+/232579 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-05-06cmd/go: add positions for load errors in call to loadMichael Matloob
This CL sets positions for errors from cals to load within the load call itself, similar to how the rest of the code in pkg.go sets positions right after the error is set on the package. This allows the code to ensure that we only add positions either for ImportPathErrors, or if an error was passed into load, and was set using setLoadPackageDataError. (Though I'm wondering if the call to setLoadPackageDataError should be done before the call to load). Fixes #38034 Change-Id: I0748866933b4c1a329954b4b96640bef702a4644 Reviewed-on: https://go-review.googlesource.com/c/go/+/228784 Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com>
2020-03-09cmd/go/internal/modload: factor smaller files out of load.go and init.goBryan C. Mills
No semantic changes intended: just structural cleanup. Updates #36460 Change-Id: I405bc2572d3ff00f595dae645e673a11e01621ca Reviewed-on: https://go-review.googlesource.com/c/go/+/222340 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-02-28cmd/go: avoid matching wildcards rooted outside of available modulesBryan C. Mills
To avoid confusion, also distinguish between packages and dirs in search.Match results. No test because this is technically only a performance optimization: it would be very difficult to write such a test so that it would not be flaky. (However, tested the change manually.) Fixes #37521 Change-Id: I17b443699ce6a8f3a63805a7ef0be806f695a4b3 Reviewed-on: https://go-review.googlesource.com/c/go/+/221544 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-02-28cmd/go: rationalize errors in internal/load and internal/modloadBryan C. Mills
This change is a non-minimal fix for #32917, but incidentally fixes several other bugs and makes the error messages much more ergonomic. Updates #32917 Updates #27122 Updates #28459 Updates #29280 Updates #30590 Updates #37214 Updates #36173 Updates #36587 Fixes #36008 Fixes #30992 Change-Id: Iedb26d2e0963697c130df5d0f72e7f83ec2dcf06 Reviewed-on: https://go-review.googlesource.com/c/go/+/185345 Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-02-28cmd/go/internal/search: consolidate package-pattern predicates into Match ↵Bryan C. Mills
methods This change consolidates predicates currently scattered throughout various parts of the package and module loader into methods on the search.Match type. That not only makes them more concise, but also encourages consistency, both in the code and in reasoning about the kinds of patterns that need to be handled. (For example, the IsLocal predicate was previously two different calls, either of which could be easily forgotten at a given call site.) Factored out from CL 185344 and CL 185345. Updates #32917 Change-Id: Ifa450ffaf6101f673e0ed69ced001a487d6f9335 Reviewed-on: https://go-review.googlesource.com/c/go/+/221458 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-02-28cmd/go/internal/search: record errors in the Match structBryan C. Mills
Previously, we would either invoke base.Fatalf (which is too aggressive), or log.Print (which is too passive). Updates #32917 Change-Id: I5475e873e76948de7df65dca08bc0ce67a7fc827 Reviewed-on: https://go-review.googlesource.com/c/go/+/185344 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-02-25cmd/go: emit an error for extraneous files in GOROOT/src in module modeMichael Matloob
If there's a go file immediately in GOROOT/src, it was probably accidentally added by the user. Since that package shouldn't exist, return an error if a user tries to list it. We're only making this change for GOPATH mode because we don't want to break cases where users have been doing this historically, but want to fix this case for the future. This also leaves open the weird cases where files are placed directly in vendor directories. Fixes #36587 Change-Id: I9738e47b1e89fd5048cbb8dd28e44648834b8ea7 Reviewed-on: https://go-review.googlesource.com/c/go/+/216381 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-02-21cmd/go: print a "found" line for each package found instead of each module addedBryan C. Mills
We currently print a "go: finding" line for each missing package during import resolution. However, we are only printing a "go: found" line for each module: if a given module provides multiple packages, we don't indicate the module that we found for the second and later packages. Before this change: $ GO111MODULE=on go get golang.org/x/tools/cmd/html2article@78f9822548c13e2c41cc8039d1492a111240db07 go: found golang.org/x/tools/cmd/html2article in golang.org/x/tools v0.0.0-20190214195451-78f9822548c1 go: finding module for package golang.org/x/net/html go: finding module for package golang.org/x/net/html/atom go: downloading golang.org/x/net v0.0.0-20200202094626-16171245cfb2 go: found golang.org/x/net/html in golang.org/x/net v0.0.0-20200202094626-16171245cfb2 After: $ GO111MODULE=on go get golang.org/x/tools/cmd/html2article@78f9822548c13e2c41cc8039d1492a111240db07 go: found golang.org/x/tools/cmd/html2article in golang.org/x/tools v0.0.0-20190214195451-78f9822548c1 go: finding module for package golang.org/x/net/html/atom go: finding module for package golang.org/x/net/html go: found golang.org/x/net/html in golang.org/x/net v0.0.0-20200202094626-16171245cfb2 go: found golang.org/x/net/html/atom in golang.org/x/net v0.0.0-20200202094626-16171245cfb2 Updates #26152 Updates #33284 Change-Id: I221548749e36bfd6a79efe5edc3645dc5319fd6f Reviewed-on: https://go-review.googlesource.com/c/go/+/219437 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>
2019-12-20cmd/go: diagnose missing replacement directoriesBryan C. Mills
I noticed the missing diagnostic when writing a regression test for #33795. Change-Id: Ic3249436a6109d71f9ff720b7096f9b872f6a94b Reviewed-on: https://go-review.googlesource.com/c/go/+/212201 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-11-13cmd/go: fix error for empty packages referenced with relative pathsJay Conrod
'go build' now reports a more useful error when a relative path on the command line points to a directory that doesn't exist or a directory without .go files. Errors are generated by go/build.Context.ImportDir instead of a vague call to base.Fatalf in modload. Fixes #35414 Change-Id: I2642230c5e409107b98bb6d6c3a484d8d25b4147 Reviewed-on: https://go-review.googlesource.com/c/go/+/206902 Run-TryBot: Jay Conrod <jayconrod@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-11-06cmd/go: make commands other than 'tidy' prune go.mod less agressivelyBryan C. Mills
Updates #31870 Updates #33326 Fixes #34822 Change-Id: I1337f171133c20800eacc6b0955ede5a394ea7eb Reviewed-on: https://go-review.googlesource.com/c/go/+/204878 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-11-05cmd/go: make 'go mod why' require a main moduleBryan C. Mills
Updates #32027 Change-Id: Ifc9427f35188c3fd356917d8510f3e01866ebca8 Reviewed-on: https://go-review.googlesource.com/c/go/+/205065 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-11-01cmd/go: adjust module-related loggingBryan C. Mills
Suppress “finding” messages unless they are unusually slow, and “extracting” messages always (they almost always occur conjunction with “downloading”, which is already logged). Log “found” messages for module dependencies added to satisfy missing import paths. Log top-level version changes in 'go get' when the selected version is not identical to the version requested on the command line. Updates #26152 Updates #33284 Change-Id: I4d0de60fab58d7cc7df8a2aff05c8b5b2220e626 Reviewed-on: https://go-review.googlesource.com/c/go/+/204777 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@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-24cmd/go/internal/modload: remove cwd globalJay Conrod
base.Cwd should be used instead. Change-Id: I3dbdecf745b0823160984cc942c883dc04c91d7b Reviewed-on: https://go-review.googlesource.com/c/go/+/203037 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/internal/modcmd: error out if one module with two different pathsBaokun Lee
If a single module is imported via two different paths, go mod tidy should have reported this error instead of deferring it until go build. Fixes #34650. Change-Id: I9d09df1551b3e2083ed9f0bc77f2989073057717 Reviewed-on: https://go-review.googlesource.com/c/go/+/199598 Run-TryBot: Baokun Lee <nototon@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-10-09cmd/go: automatically check and use vendored packagesBryan C. Mills
This implements the proposal described in https://golang.org/issue/33848#issuecomment-537222782. Fixes #33848 Change-Id: Ia34d6500ca396b6aa644b920233716c6b83ef729 Reviewed-on: https://go-review.googlesource.com/c/go/+/198319 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-09-25cmd/go/internal/modload: annotate replacements in PackageNotInModuleErrorBryan C. Mills
Fixes #34085 Change-Id: I3111f5997466ad33f51e80c71f5fb2ccebdcc6e4 Reviewed-on: https://go-review.googlesource.com/c/go/+/193617 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-08-27cmd/go/internal/modload: fix swapped paths in error messageBryan C. Mills
Updates #33879 Change-Id: Ifc91490b1cb791fdf5ffe69ef81c0ec0e6cbecc3 Reviewed-on: https://go-review.googlesource.com/c/go/+/191997 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Alexander Rakoczy <alex@golang.org>
2019-08-02cmd/go: report loading errors from 'go mod tidy' and 'go mod vendor'Bryan C. Mills
Fixes #27063 Change-Id: Iedd14fd614a3d79d1387b923a0f123c2bc9e0b33 Reviewed-on: https://go-review.googlesource.com/c/go/+/188763 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-07-16cmd/go: tweak wording of module path mismatch error messageJay Conrod
Changes "was loaded as" to "was required as". This is slightly more precise, since it hints at a requirement edge in the module version graph. Updates #28489 Change-Id: I636268c33f1ea9858c214fe275f271538186ed6d Reviewed-on: https://go-review.googlesource.com/c/go/+/186377 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-07-16cmd/go: clarify error text for module path mismatchJay Conrod
This error occurs when a module is loaded with one name (for example, github.com/golang/lint) but declares a different path in its go.mod (golang.org/x/lint). The current text "unexpected module path" is confusing. It doesn't explain why the path was unexpected, and it's not clear what was expected. With this change, the error text includes the module and version containing the go.mod file with the error, the declared module path, and the loaded module path. The paths are vertically aligned so differences are visually obvious. As with other module version errors, the shortest chain of requirements is printed. This change supercedes CL 158477. Fixes #28489 Change-Id: Ieb07d00bcae182376d7be6aad111c84fbf784354 Reviewed-on: https://go-review.googlesource.com/c/go/+/185985 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-07-15cmd/go: check for source files in relative paths before attempting to ↵Bryan C. Mills
determine the package path This is a more minimial fix for the immediate symptom of 32917 and 30590, but does not improve 'list -e' behavior or error messages resulting from other package loading issues. Fixes #32917 Fixes #30590 Change-Id: I6088d14d864410159ebf228d9392d186322fd2a5 Reviewed-on: https://go-review.googlesource.com/c/go/+/185417 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-07-10cmd/go/internal/modload: remove unused warnPattern functionBryan C. Mills
Change-Id: I6cf66870952d4c652912dd50a0b9af41bdc79dce Reviewed-on: https://go-review.googlesource.com/c/go/+/185346 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-06-21cmd/go: validate pseudo-versions against module paths and revision metadataBryan C. Mills
Previously, most operations involving pseudo-versions allowed any arbitrary combination of version string and date, and would resolve to the underlying revision (typically a Git commit hash) as long as that revision existed. There are a number of problems with that approach: • The pseudo-version participates in minimal version selection. If its version prefix is inaccurate, the pseudo-version may appear to have higher precedence that the releases that follow it, effectively “pinning” the module to that commit. For release tags, module authors are the ones who make the decision about release tagging; they should also have control over the pseudo-version precedence within their module. • The commit date within the pseudo-version provides a total order among pseudo-versions. If it is not accurate, the pseudo-version will sort into the wrong place relative to other commits with the same version prefix. To address those problems, this change restricts the pseudo-versions that the 'go' command accepts, rendering some previously accepted-but-not-canonical versions invalid. A pseudo-version is now valid only if all of: 1. The tag from which the pseudo-version derives points to the named revision or one of its ancestors as reported by the underlying VCS tool, or the pseudo-version is not derived from any tag (that is, has a "vX.0.0-" prefix before the date string and uses the lowest major version appropriate to the module path). 2. The date string within the pseudo-version matches the UTC timestamp of the revision as reported by the underlying VCS tool. 3. The short name of the revision within the pseudo-version (such as a Git hash prefix) is the same as the short name reported by the underlying cmd/go/internal/modfetch/codehost.Repo. Specifically, if the short name is a SHA-1 prefix, it must use the same number of hex digits (12) as codehost.ShortenSHA1. 4. The pseudo-version includes a '+incompatible' suffix only if it is needed for the corresponding major version, and only if the underlying module does not have a go.mod file. We believe that all releases of the 'go' tool have generated pseudo-versions that meet these constraints. However, a few pseudo-versions edited by hand or generated by third-party tools do not. If we discover invalid-but-benign pseudo-versions in widely-used existing dependencies, we may choose to add a whitelist for those specific path/version combinations. ― To work around invalid dependencies in leaf modules, users may add a 'replace' directive from the invalid version to its valid equivalent. Note that the go command's go.mod parser automatically resolves commit hashes found in 'replace' directives to the appropriate pseudo-versions, so in most cases one can write something like: replace github.com/docker/docker v1.14.0-0.20190319215453-e7b5f7dbe98c => github.com/docker/docker e7b5f7dbe98c and then run any 'go' command (such as 'go list' or 'go mod tidy') to resolve it to an appropriate pseudo-version. Note that the invalid version will still be used in minimal version selection, so this use of 'replace' directives is an incomplete workaround. ― One of the common use cases for higher-than-tagged pseudo-versions is for projects that do parallel development on release branches. For example, if a project cuts a 'v1.2' release branch at v1.2.0, they may want future commits on the main branch to show up as pre-releases for v1.3.0 rather than for v1.2.1 — especially if v1.2.1 is already tagged on the release branch. (On the other hand, a backport of a patch to the v1.2 branch should not show up as a pre-release for v1.3.0.) To address this use-case, module authors can make use of our existing support for pseudo-versions derived from pre-release tags: if the author adds an explicit pre-release tag (such as 'v1.3.0-devel') to the first commit after the branch, then the pseudo-versions for that commit and its descendents will be derived from that tag and will sort appropriately in version selection. ― Updates #27171 Fixes #29262 Fixes #27173 Fixes #32662 Fixes #32695 Change-Id: I0d50a538b6fdb0d3080aca9c9c3df1040da1b329 Reviewed-on: https://go-review.googlesource.com/c/go/+/181881 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-05-31cmd/go: ignore build tags when 'go get' modifies build listJay Conrod
In module mode, 'go get' should not consider build constraints when loading packages in order to modify the module graph. With this change, 'go get' considers all build tags to be true except for "ignore" and malformed build constraint expressions. When 'go get' builds packages, it still applies build constraints for the target platform. Fixes #32345 Change-Id: I6dceae6f10a5185870537de730b36292271ad124 Reviewed-on: https://go-review.googlesource.com/c/go/+/179898 Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-05-30cmd/go: remove support for the 'go get -m' flagJay Conrod
Fixes #32038 Change-Id: Ib4981f76572405363f404ee5038a45cb1752a2ad Reviewed-on: https://go-review.googlesource.com/c/go/+/177879 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-05-24cmd/go: when resolving packages, try all module paths before falling back to ↵Bryan C. Mills
the next proxy Since we're mucking with error-propagation in modload.Query* anyway, simplify the classification logic. Ensure that “module not found” errors are reported as such in various places, since non-“not found” errors terminate the module search. Fixes #31785 Change-Id: Ie3ca5f4eec10a5f2a6037ec7e1c2cf47bd37a232 Reviewed-on: https://go-review.googlesource.com/c/go/+/177958 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2019-05-20cmd/go: make 'go get -t' consider test dependencies in module modeJay Conrod
Fixes #32037 Change-Id: I696fe2029e383746252f37fe8d30df71b5ac8a6c Reviewed-on: https://go-review.googlesource.com/c/go/+/177677 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-04-30cmd/go: make get -u upgrade only modules providing packagesJay Conrod
Currently, 'go get -u' upgrades modules matching command line arguments and any modules they transitively require. 'go get -u' with no positional arguments upgrades all modules transitively required by the main module. This usually adds a large number of indirect requirements, which is surprising to users. With this change, 'go get' will load packages specified by its arguments using a similar process to other commands ('go build', etc). Only modules providing packages will be upgraded. 'go get -u' now upgrades modules providing packages transitively imported by the command-line arguments. 'go get -u' without arguments will only upgrade modules needed by the package in the current directory. 'go get -m' will load all packages within a module. 'go get -m -u' without arguments will upgrade modules needed by the main module. It is equivalent to 'go get -u all'. Neither command will upgrade modules that are required but not used. Note that 'go get -m' and 'go get -d' both download modules in order to load packages. Fixes #26902 Change-Id: I2bad686b3ca8c9de985a81fb42b16a36bb4cc3ea Reviewed-on: https://go-review.googlesource.com/c/go/+/174099 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2019-04-16cmd/go: print package import chains for some build list errorsJay Conrod
When we construct the build list by loading packages (e.g., in "go build", "go list", or "go test"), we may load additional modules not mentioned in the original build list. If we encounter an error loading one of these modules, mvs.BuildList currently returns a BuildListError with a chain of requirments. Unfortunately, this is not helpful, since the graph is structured such that these missing modules are direct requirements of the main module. With this change, loader.load keeps track of the package that caused each "missing" module to be added. If an error occurs in a missing module, the chain of package imports is printed instead of the module requirements. Fixes #31475 Change-Id: Ie484814af42ceea3e85fedc38e705ba3a38cd495 Reviewed-on: https://go-review.googlesource.com/c/go/+/171859 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-04-03cmd/go: print require chains in build list errorsJay Conrod
mvs.BuildList and functions that invoke it directly (UpgradeAll) now return an *mvs.BuildListError when there is an error retrieving the requirements for a module. This new error prints the chain of requirements from the main module to the module where the error occurred. These errors come up most commonly when a go.mod file has an unexpected module path or can't be parsed for some other reason. It's currently difficult to debug these errors because it's not clear where the "bad" module is required from. Tools like "go list -m" and "go mod why" don't work without the build graph. Fixes #30661 Change-Id: I3c9d4683dcd9a5d7c259e5e4cc7e1ee209700b10 Reviewed-on: https://go-review.googlesource.com/c/go/+/166984 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-04-03cmd/go/internal/modload: fix aliasing bug in (*mvsReqs).Required with ↵Bryan C. Mills
-mod=vendor (*mvsReqs).Required assumes that it is safe to mutate the slice returned by (*mvsReqs).required. In most cases, that was true, but in the case of -mod=vendor it resulted in unsynchronized (and potentially interfering) writes to the global vendorList. Fixes #30550 Change-Id: I99bcc2037e0182418b7dfda1002f8b540dbf3a1d Reviewed-on: https://go-review.googlesource.com/c/go/+/170598 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-04-01cmd/go/internal/modget: support the suffix '@patch' in 'go get'Bryan C. Mills
As of this change, an explicit '@patch' suffix is to '-u=patch' as '@latest' is to '-u'. RELNOTE='go get' in module mode now supports the version suffix '@patch'. Fixes #26812 Change-Id: Ib5eee40de640440f7470d37a574b311ef8a67f67 Reviewed-on: https://go-review.googlesource.com/c/go/+/167747 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-03-29cmd/go: clarify error when package is removed in a moduleJay Conrod
If no module in the build list provides an imported package, we try to upgrade to the "@latest" version. If there is a requirement on a version of the module which is newer than the "@latest" version (e.g., a prerelease or pseudoversion), we cannot upgrade further. We previously reported "looping trying to add package" when we saw the package in "@latest" but it was removed later. The meaning of this is unclear for users, so with this change, we explain the package was removed. Fixes #30394 Change-Id: I1b7fec2c37e762fb600e66ee8a4df4aeaf13e67a Reviewed-on: https://go-review.googlesource.com/c/go/+/169720 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-03-15cmd/go: list directories in module cache replacementsJay Conrod
"go list" has allowed listing directory paths to packages in the module cache since CL 126715. This is sometimes necessary for tools gathering package information about source files in imported packages. With this change, we only allow directories in the module cache for modules in the build list after replacements are applied. Previously, we ignored replacements when expanding file system path patterns while constructing the build list. Fixes #29548 Change-Id: Ic7f89122c4656c8967c14545cb7117f98e89e721 Reviewed-on: https://go-review.googlesource.com/c/go/+/165381 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-03-12cmd/go/internal/modload: treat a 'std' module outside GOROOT/src as an ↵Bryan C. Mills
ordinary module Fixes #30756 Change-Id: I046d43df56faac8fc09d53dc1e87a014dd6d530b Reviewed-on: https://go-review.googlesource.com/c/go/+/167080 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-03-11cmd/go: resolve non-standard imports from within GOROOT/src using vendor ↵Bryan C. Mills
directories Updates #30228 Fixes #26924 Change-Id: Ie625c64721559c7633396342320536396cd1fcf5 Reviewed-on: https://go-review.googlesource.com/c/go/+/164621 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2019-02-15cmd/go: only generate a go.mod file during 'go mod init'Bryan C. Mills
In the general case, we do not know the correct module path for a new module unless we have checked its VCS tags for a major version. If we do not know the correct path, then we should not synthesize a go.mod file automatically from it. On the other hand, we don't want to run VCS commands in the working directory without an explicit request by the user to do so: 'go mod init' can reasonably invoke a VCS command, but 'go build' should not. Therefore, we should only create a go.mod file during 'go mod init'. This change removes the previous behavior of synthesizing a file automatically, and instead suggests a command that the user can opt to run explicitly. Updates #29433 Updates #27009 Updates #30228 Change-Id: I8c4554969db17156e97428df220b129a4d361040 Reviewed-on: https://go-review.googlesource.com/c/162699 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>
2018-12-04cmd/go: emit go list error for local non-existant packagesJay Conrod
In CL 129061, a check was added for patterns that reference nonexistent local directories. While this prevented unnecessary network lookups (fixing #26874), it caused "go list -e" to exit with an error instead of listing packages with error messages. This change avoids the network lookup and does not exit for these kinds of packages. Errors are still reported by internal/load.LoadImport for packages that don't exist. Fixes #28023 Change-Id: I0a648269e437aed3a95bfb05461a397264f3793f Reviewed-on: https://go-review.googlesource.com/c/151800 Run-TryBot: Jay Conrod <jayconrod@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2018-11-29cmd/go: enable module mode without a main module when GO111MODULE=onBryan C. Mills
This is as minimal a change as I could comfortably make to enable 'go get' outside of a module for 1.12. In general, commands invoked in module mode while outside of a module operate as though they are in a module with an initially-empty go.mod file. ('go env GOMOD' reports os.DevNull.) Commands that operate on the current directory (such as 'go list' and 'go get -u' without arguments) fail: without a module definition, we don't know the package path. Likewise, commands whose sole purpose is to write files within the main module (such as 'go mod edit' and 'go mod vendor') fail, since we don't know where to write their output. Since the go.sum file for the main module is authoritative, we do not check go.sum files when operating outside of a module. I plan to revisit that when the tree opens for 1.13. We may also want to revisit the behavior of 'go list': it would be useful to be able to query individual packages (and dependencies of those packages) within versioned modules, but today we only allow versioned paths in conjunction with the '-m' flag. Fixes #24250 RELNOTE=yes Change-Id: I028c323ddea27693a92ad0aa4a6a55d5e3f43f2c Reviewed-on: https://go-review.googlesource.com/c/148517 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2018-10-09cmd/go: check that package paths are invariantly non-emptyBryan C. Mills
The empty string is never a valid package path. Passing an empty string to a function that expects a package path indicates some missing validation step further up the call chain — typically (and most easily) a missed error check. Change-Id: I78a2403d95b473bacb0d40814cd9d477ecfd5351 Reviewed-on: https://go-review.googlesource.com/c/140857 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-08-23all: fix typos detected by github.com/client9/misspellKazuhiro Sera
Change-Id: Iadb3c5de8ae9ea45855013997ed70f7929a88661 GitHub-Last-Rev: ae85bcf82be8fee533e2b9901c6133921382c70a GitHub-Pull-Request: golang/go#26920 Reviewed-on: https://go-review.googlesource.com/128955 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-08-21cmd/go: fix modload response for std-vendored packagesRuss Cox
This fixes a failure when using Go 1.11 to build App Engine code. Change-Id: I008e8cf5ad4c568676d904deddff031a166f2d5d Reviewed-on: https://go-review.googlesource.com/130138 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-08-18cmd/go: allow 'go run x.go' to use nearby internal imports in module modeRuss Cox
In GOPATH mode the rule has always been that 'go run x.go' can import whatever the package in x.go's directory would be able to import. Apply the same rule here. The bad import path was triggering other mysterious errors during 'go run' in other circumstances. Setting it correctly fixes those too. Fixes #26046. Fixes #27022. Change-Id: I0a9b0a154a20f48add5a199da85572e7ffe0cde4 Reviewed-on: https://go-review.googlesource.com/129798 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-08-17cmd/go: do not turn list ./nonexist into a network lookupRuss Cox
If you're in a directory corresponding to x/y and you run go list ./z, we do at some point want to turn that into x/y/z. But if ./z does not exist that will make the go command check the network to see if it can find x/y/z. That's clearly wrong: ./z means that directory, nothing else. And it turns a typo into a long delay, which is even worse. Fixes #26874. Change-Id: Iec15fa7b359af11b6a4fc6cb082e593658fb6e41 Reviewed-on: https://go-review.googlesource.com/129061 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
2018-08-17cmd/go: report which patterns match each package in listRuss Cox
It's important for some uses of go/packages, as well as for some of go/packages's internal use, to be able to tell which results from go list output correspond to which patterns, keeping in mind that a single package might have been matched by multiple patterns. Also adds test for #26925. Change-Id: I708ac162f65d9946fe6afb244b08dc7b04d2b530 Reviewed-on: https://go-review.googlesource.com/129060 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com>
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion