| Age | Commit message (Collapse) | Author |
|---|
|
targets
This change replaces the Target variable that represents the main module
and the pathPrefix and inGorootSrc which provide other information about
the main module with a single MainModules value that represents multiple
main modules and holds their path prefixes, module roots, and whether
they are in GOROOT/src. In cases where the code checks Target or its
previously associated variables, the code now checks or iterates over
MainModules. In some cases, the code still assumes a single main module
by calling MainModules.MustGetSingleMainModule. Some of those cases are
correct: for instance, there is always only one main module for
mod=vendor. Other cases are accompanied with TODOs and will have to be
fixed in future CLs to properly support multiple main modules.
This CL (and other cls on top of it) are planned to be checked into a
branch to allow for those evaluating the workspaces proposal to try it
hands on.
For #45713
Change-Id: I3b699e1d5cad8c76d62dc567b8460de8c73a87ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/334932
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>
|
|
Previously, mvs.Downgrade could introduce spurious dependencies if the
downgrade computed for one module lands on a “hidden” version (such as
a pseudo-version) due to a requirement introduced by the downgrade for
another module.
To eliminate those spurious dependencies, we can add one more call to
BuildList to recompute the “actual” downgraded versions, and then
including only those actual versions in the final call to BuildList.
For #36460
Change-Id: Icc6b54aa004907221b2bcbbae74598b0e4100776
Reviewed-on: https://go-review.googlesource.com/c/go/+/294294
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>
|
|
versions
For #36460
Change-Id: I889c4ece0d2caff7528cf437f89f7446dbd83955
Reviewed-on: https://go-review.googlesource.com/c/go/+/294292
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>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
mvs.Downgrade is pretty clearly intended to match Algorithm 4 from the
MVS blog post (https://research.swtch.com/vgo-mvs#algorithm_4).
Per the blog post:
“Downgrading one module may require downgrading other modules, but we
want to downgrade as few other modules as possible. … To avoid an
unnecessary downgrade to E 1.1, we must also add a new requirement on
E 1.2. We can apply Algorithm R to find the minimal set of new
requirements to write to go.mod.”
mvs.Downgrade does not match that behavior today: it fails to retain
the selected versions of transitive dependencies that are not implied
by downgraded direct dependencies of the target (module E in the
post). This bug is currently masked by the fact that we only call
Downgrade today with a *modload.mvsReqs, for which the Required method
happens to return the complete build list — rather than only the
direct dependencies as documented for the mvs.Reqs interface.
For #36460
Change-Id: If9c8f413b156b5f67c02787d9359394e169951b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/287633
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
For #36460
Change-Id: I5a8be8f36fb8825ffa08ed1427cb1e15b106b31a
Reviewed-on: https://go-review.googlesource.com/c/go/+/287732
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>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
Req is supposed to return “a minimal requirement list”
that includes each of the module paths listed in base.
Currently, if base contains duplicates Req emits duplicates,
and a list containing duplicates is certainly not minimal.
That, in turn, requires callers to be careful to deduplicate the base
slice, and there are multiple callers that are already quite
complicated to reason about even without the added complication of
deduplicating slices.
For #36460
Change-Id: I391a1dc0641fe1dd424c16b7a1082da0d00c7292
Reviewed-on: https://go-review.googlesource.com/c/go/+/287632
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>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
This has no impact on the resulting build list, but provides clearer
diagnostics if reqs.Required returns an error for one of the upgraded
modules.
For #37438
Change-Id: I5cd8f72a9b7b9a0b185e1a728f46fefbd2f09b4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/266897
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>
|
|
itself
Also clean up the test assertions, and add a check for assertions
missing function invocations (there was one).
For #37438
Change-Id: Iafbfeae2c25217eac894181e01480b25b7cffbd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/266859
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>
|
|
For #37438
Change-Id: Icb28035ae4027aa09d8959d4ac2f4b94a6c843a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/266339
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
|
|
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>
|
|
modload.MinReqs was passing modload.buildList to mvs.Reqs explicitly,
apparently as an optimization. However, we do not always have the
invariant that modload.buildList is complete: in particular, 'go mod
tidy' begins by reducing modload.buildList to only the set of modules
that provide packages to the build, which may be substantially smaller
than the final build list.
Other operations, such as 'go mod graph', do not load the entire
import graph, and therefore call Reqs with the unreduced build list.
Since Reqs retains modules according to a post-order traversal of the
list, an incomplete list may produce a different traversal order — and
therefore a different minimal solution, when multiple minimal
solutions exist. That caused 'go mod tidy' to produce different output
from other 'go' subcommands when certain patterns of dependencies are
present.
Since passing in the build list is only an optimization anyway, remove
the parameter and recompute the actual (complete) list at the
beginning of mvs.Reqs itself. That way, it is guaranteed to be
complete and in canonical order.
Fixes #34086
Change-Id: I3101bb81a1853c4a5e773010da3e44d2d90a570c
Reviewed-on: https://go-review.googlesource.com/c/go/+/193397
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
versions already in the graph
Fixes #31248
Change-Id: Ia54f2098c3b85549681198a487a31e8ce8fc59eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/186557
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
Fixes #29773
Updates #31248
Change-Id: Ic1923119c8cf3a60c586df1b270c3af0c9095f29
Reviewed-on: https://go-review.googlesource.com/c/go/+/186537
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
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>
|
|
This CL corresponds to CL 123361, the final manual CL in that repo,
making this the final manual sync.
All future commits will happen in this repo (the main Go repo),
and we'll update x/vgo automatically with a fixed patch+script.
Change-Id: I572243309c1809727604fd704705a23c30e85d1a
Reviewed-on: https://go-review.googlesource.com/123576
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
This CL corresponds to golang.org/cl/118096 (7fbc8df48a7)
in the vgo repo.
It copies the bulk of the code from vgo back into the main repo,
but completely disabled - vgo.Init is a no-op and vgo.Enabled
returns false unconditionally.
The point of this CL is to make the two trees easier to diff and
to make future syncs smaller.
Change-Id: Ic34fd5ddd8272a70c5a3b3437b5169e967d0ed03
Reviewed-on: https://go-review.googlesource.com/118095
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
