| Age | Commit message (Collapse) | Author |
|---|
|
In loadModFile with -mod=vendor, load the vendor list and use it to
initialize the module graph before calling updateRoots.
In updateLazyRoots with any mode other than "mod", return the original
*Requirements if no roots needed to be upgraded, even if there are
inconsistencies. This means 'go list -m -mod=readonly' and -mod=vendor
may succeed if there are duplicate requirements or requirements on
versions of the main module.
Fixes #47565
Change-Id: I4640dffc4a7359367cc910da0d29e3538bfd1ca4
Reviewed-on: https://go-review.googlesource.com/c/go/+/340252
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
For #46366
Change-Id: I8417e6e4dbb8cb56ff7afc16893a01b7bb938217
Reviewed-on: https://go-review.googlesource.com/c/go/+/329529
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>
|
|
I needed to also update TestScript/mod_sumdb_golang.
It had been relying on 'go list -mod=mod' to add both the go.mod and
go.sum entries for the named package, but when 'go get' actually adds
all of the needed dependencies, lazy loading kicks in and 'go list'
doesn't end up needing the checksums for go.mod files.
We didn't detect the skew before because the 'go list' command was
(unexpectedly) also adding the missing dependencies, which triggered a
deep scan of the complete module graph.
For #45979
Change-Id: Ica917dee22c83ffa71c6ad0f2e189f911b73edf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/328231
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>
|
|
explicitly
Fixes #46078
Change-Id: I8044dac717459f1eeae1d8381a6503f22f9f51ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/319009
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
when loading packages from them
For #36460
Change-Id: I725ef5445b2bac7af827fb38373e8cd6dbad2d09
Reviewed-on: https://go-review.googlesource.com/c/go/+/316249
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>
|
|
GODEBUG=lazymod=log causes the go command to log a stack dump whenever
the full module graph is loaded in a lazy module.
GODEBUG=lazymod=strict does the same, but also terminates the command
with a nonzero exit code.
For #36460
Change-Id: Ia5a4c46069044bcc157b285f64c2392990d70bd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/315411
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>
|
|
This change adds two possible upgrade paths for lazy loading:
1. Run 'go mod tidy -go=1.17'.
2. Starting in a module with no existing 'go' directive,
run any 'go' command that updates the go.mod file.
In the latter case, commands other than 'go mod tidy'
may leave the go.mod file *very* untidy if it had non-trivial
dependencies. (The 'go' invocation will promote all
implicit eager dependencies to explicit lazy ones,
which preserves the original module graph — most of which is
not actually relevant.)
'go mod tidy -go=1.17' can be used to enable lazy loading without
accidentally downgrading existing transitive dependencies.
'go mod tidy -go=1.16' can be used to disable lazy loading and clear
away redundant roots in a single step (if reducing the go version), or
to prune away dependencies of tests-of-external-tests (if increasing
the go version).
'go mod tidy -go=1.15' can be used to add dependencies of
tests-of-external-tests, although there isn't much point to that.
DO NOT MERGE
This change still needs an explicit test and a release note.
Fixes #45094
For #36460
Change-Id: I68f057e39489dfd6a667cd11dc1e320c1ee1aec1
Reviewed-on: https://go-review.googlesource.com/c/go/+/315210
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>
|
|
lazy module
For #36460
Change-Id: Ib4b1baea35826c3e359456f8dba09a49283e7fee
Reviewed-on: https://go-review.googlesource.com/c/go/+/315069
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 #36460
Updates #41297
Change-Id: I1b82176a45df499e52f1a3a0ffe23eab2a1ca86e
Reviewed-on: https://go-review.googlesource.com/c/go/+/265777
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>
|
|
• 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>
|
|
requirement graph
For #36460
Change-Id: Ic87d7e25402bb938d2872d33d26c4bf397776d1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/308517
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>
|
|
to add modules for missing packages
editRequirements does a lot of work in order to respect the upper
bounds of mustSelect, and as a result it doesn't provide many promises
about conserving other things (like root dependencies).
When we add modules for missing packages, we aren't dealing with upper
bounds at all, so we would rather avoid the upper-bound overhead and
preserve the root-dependency invariants instead.
(*loader).updateRequirements does exactly that; it just needs to be
told about the additional dependencies to add.
For #36460
Change-Id: Ie0f2bc0dde18026bbd23e51357bb1d725d201680
Reviewed-on: https://go-review.googlesource.com/c/go/+/310791
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
The comment for the Requirements.rootModules field requires that it be
"sorted and capped to length". I noticed that we were not capping it
correctly — we were capping the local variable (the rorotModules
argument itself) but not the struct field. That prompted me to
question whether we were also at some point failing to sort it
correctly, so I decided to add an explicit check.
With the explicit check, all tests continue to pass.
For #36460
Change-Id: I6687de8ef8ecc5129fa8810d678e5673752fd27b
Reviewed-on: https://go-review.googlesource.com/c/go/+/310790
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>
|
|
updating and tidying
In CL 293689, I fused the mvs.Reqs calls that were formerly in MinReqs
and TidyBuildList into a single function, updateRoots, in the hope
that it expressed a fundamental operation. As I have been working on
the lazy equivalents, I have come to realize that these functions are
deeply related but fundamentally different.
In order to help me reason about the two different roles, I am making
the two functions separate once more, but leaving them colocated in
the code.
For #36460
Change-Id: I851d6d81fbfd84f39411e0d076ee72a9909c60ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/310629
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 eliminates some awkwardly-stateful outside calls to
modload.{Disallow,Allow,}WriteGoMod.
Perhaps more importantly, it gives the loader the opportunity to
reload packages and revise dependencies after the tidied requirements
are computed. With lazy loading, dropping an irrelevant requirement
from the main module's go.mod file may (rarely) cause other test
dependencies for packages outside the main module to become
unresolved, which may require the loader to re-resolve those
dependencies, which may in turn add new roots and increase the
selected versions of modules providing other packages.
This refactoring allows the loader to iterate between tidying the
build list and reloading packages as needed, making the exact
sequencing of loading and tidying an implementation detail of the
modload package.
For #36460
For #40775
Change-Id: Ib6da3672f32153d5bd7d653d85e3672ab96cbe36
Reviewed-on: https://go-review.googlesource.com/c/go/+/310181
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>
|
|
build list
The mvsReqs implementation has always been a bit ambivalent about
whether the root requirements return the full build list, just the
direct requirements, or some hybrid of the two.
However, a full build list always requires the Target module as the
first entry, and it's easer to remove a redundant leading element from
a slice than to add one. Changing the mvsReqs field to contain
arbitrary roots instead of a full build list eliminates the need to
add redundant elements, at the cost of needing to remove redundant
elements in more places.
For #36460
Change-Id: Idd4c2d6bc7b66f67680037dab1fb9c2d1b40ab93
Reviewed-on: https://go-review.googlesource.com/c/go/+/308811
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
A module is deprecated if its author adds a comment containing a
paragraph starting with "Deprecated:" to its go.mod file. The comment
must appear immediately before the "module" directive or as a suffix
on the same line. The deprecation message runs from just after
"Deprecated:" to the end of the paragraph. This is implemented in
CL 301089.
'go list -m -u' loads deprecation messages from the latest version of
each module, not considering retractions (i.e., deprecations and
retractions are loaded from the same version). By default, deprecated
modules are printed with a "(deprecated)" suffix. The full deprecation
message is available in the -f and -json output.
'go get' prints deprecation warnings for modules named on the command
line. It also prints warnings for modules needed to build packages
named on the command line if those modules are direct dependencies of
the main module.
For #40357
Change-Id: Id81fb2b24710681b025becd6cd74f746f4378e78
Reviewed-on: https://go-review.googlesource.com/c/go/+/306334
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
This was missed in CL 308515, and didn't show up in testing because so
few codepaths (and tests) actually depend on this behavior so far.
For #36460
Change-Id: I98b1962eb64d371884e15a3356c95f7ea80c7d21
Reviewed-on: https://go-review.googlesource.com/c/go/+/308810
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
This change adds the depth constants 'lazy' and 'eager', but leaves
the go117EnableLazyLoading constant set to false so that the depth in
effect is still always 'eager'.
The go117EnableLazyLoading constant can be toggled to true once the
module loader has been updated to maintain the lazy-loading invariants
in the go.mod file. In the meantime, this will allow me to
progressively replace uses of go117LazyTODO with real conditions and
locally toggle lazy-mode on to see which tests are still failing
(or which behaviors are missing test coverage).
For #36460
Change-Id: Ifd358265a3903a5000003c2072f28171f336e15c
Reviewed-on: https://go-review.googlesource.com/c/go/+/308515
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>
|
|
This significantly simplifies the implementation of editRequirements
in preparation for making it lazy. It should have no effect on which
version combinations are rejected by 'go get', nor on which solutions
are found if downgrades are needed.
This change results in a small but observable change in error logging.
Before, we were reporting an error line for each argument that would
have exceeded its specified version, attributing it to one arbitrary
cause. Now, we are reporting an error line for each argument that
would cause any other argument to exceed its specified version. As a
result, if one argument would cause two others to exceed their
versions, we will now report one line instead of two; if two arguments
would independently cause one other to exceed its version, we will now
report two lines instead of one.
This change may result in a small performance improvement. Because we
are now scanning and rejecting incompatible requirements earlier, we
may waste less time computing upgrades and downgrades that ultimately
won't matter due to conflicting constraints.
For #36460
Change-Id: I125aa09b4be749dc5bacef23a859333991960e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/305009
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
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>
|
|
was changed
For #36460
Change-Id: I8dd6e6f998a217a4287212815ce61209df6f007f
Reviewed-on: https://go-review.googlesource.com/c/go/+/296609
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>
|
|
Previosly, EditBuildList performed an mvs.Upgrade followed by an
mvs.Downgrade, with the Downgrade building on the result of the
Upgrade. Unfortunately, that approach potentially folds in irrelevant
dependencies from the first Upgrade, which are then preserved
unnecessarily by the Downgrade (see mod_get_downup_artifact.txt).
Now, we use the initial Upgrade only to compute the maximum allowed
versions of transitive dependencies, and apply the module upgrades and
downgrades together in a single operation.
For #36460
Change-Id: I7590c137111fed4a3b06531c88d90efd49e6943a
Reviewed-on: https://go-review.googlesource.com/c/go/+/290770
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>
|
|
'go get pkg@vers' will now add an explicit requirement for the module
providing pkg if that version was already indirectly required.
'go get mod@vers' will do the same if mod is a module path but not a
package.
Requirements promoted this way will be marked "// indirect" because
'go get' doesn't know whether they're needed to build packages in the
main module. So users should prefer to run 'go get ./pkg' (where ./pkg
is a package in the main module) to promote requirements.
Fixes #43131
Change-Id: Ifbb65b71274b3cc752a7a593d6ddd875f7de23b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/278812
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
For #36460
Updates #37438
Change-Id: I1626d40e78b110035a893b1b80dbd2279bf50ffe
Reviewed-on: https://go-review.googlesource.com/c/go/+/272128
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>
|
|
As of CL 271646, all external callers have been eliminated. Replace
the remaining internal caller with a direct reference to the buildList
variable and remove the exported function to prevent backsliding.
For #36460
Change-Id: Iea82df1e3e604ada602dda3e830c06d441eee2a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/271647
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
For the last remaining call site (in cmd/go/internal/work, added for
the new 'go install pkg@version' codepath in CL 254365), use
EditBuildList instead.
SetBuildList assumes that the caller has enough information to produce
a complete, coherent build list. With lazy loading, producing a
complete, coherent build list is no longer quite so trivial.
In CL 263267, I rewrote the main caller of SetBuildList (the 'go get'
command), and in the process added a more targeted modload hook
(EditBuildList). That hook also suffices for 'go install pkg@version'.
The resulting error messages are perhaps not as smooth as they ought
to be, but if they are too awkward we should probably fix them for
'go get' too, and the commands can continue to share the edit hook.
For #36460
Updates #40276
Change-Id: I698a9dcd2efe6378a4d91f21362880aa8e50001b
Reviewed-on: https://go-review.googlesource.com/c/go/+/270980
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>
|
|
Previously, we resolved each argument to 'go get' to a package path or
module path based on what was in the build list at existing versions,
even if the argument specified a different version explicitly. That
resulted in bugs like #37438, in which we variously resolved the wrong
version or guessed the wrong argument type for what is unambiguously a
package argument at the requested version.
We were also using a two-step upgrade/downgrade algorithm, which could
not only upgrade more that is strictly necessary, but could also
unintentionally upgrade *above* the requested versions during the
downgrade step.
This change instead uses an iterative approach, with an explicit
disambiguation step for the (rare) cases where an argument could match
the same package path in multiple modules. We use a hook in the
package loader to halt package loading as soon as an incorrect version
is found — preventing over-resolving — and verify that the result
after applying downgrades successfully obtained the requested versions
of all modules.
Making 'go get' be correct and usable is especially important now that
we are defaulting to read-only mode (#40728), for which we are
recommending 'go get' more heavily.
While I'm in here refactoring, I'm also reworking the API boundary
between the modget and modload packages. Previously, the modget
package edited the build list directly, and the modload package
accepted the edited build list without validation. For lazy loading
(#36460), the modload package will need to maintain additional
metadata about the requirement graph, so it needs tighter control over
the changes to the build list.
As of this change, modget no longer invokes MVS directly, but instead
goes through the modload package. The resulting API gives clearer
reasons in case of updates, which we can use to emit more useful
errors.
Fixes #37438
Updates #36460
Updates #40728
Change-Id: I596f0020f3795870dec258147e6fc26a3292c93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/263267
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: Russ Cox <rsc@golang.org>
|
|
Instead of duplicating PackageOpts fields in the loaderParams struct,
embed the PackageOpts directly. Many of the fields are duplicated, and
further fields that would also be duplicated will be added in
subsequent changes.
For #36460
Change-Id: I3b0770d162e901d23ec1643183eb07c413d51e0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/263138
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>
|
|
InitMod is split into two functions. LoadModFile parses an existing
go.mod file and loads the build list (or checks vendor/modules.txt for
consistency in vendor mode). CreateModFile creates a new go.mod file,
possibly inferring the module path and importing a vendor
configuration file.
Some logic is moved from runInit to CreateModFile. init-specific logic
is removed from other functions.
This CL shouldn't cause substantial differences in behavior, though
some error messages are slightly different.
For #41712
Change-Id: Ia684945cfcf5beca30bbb81e7144fc246c4f27ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/264621
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>
|
|
The Query function allows the caller to specify the current version of
the requested module, but the QueryPattern function is missing that
parameter: instead, it always assumes that the current version is the
one selected from the global build list.
This change removes that assumption, instead adding a callback
function to determine the current version. (The callback is currently
invoked once per candidate module, regardless of whether that module
exists, but in a future change we can refactor it to invoke the
callback only when needed.)
For #36460
For #40775
Change-Id: I001a4a8ab24f5b4fcc66a670d9bd305b47e948ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/261640
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>
|
|
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>
|
|
With lazy loading, the “build list” can be refined as packages are loaded.
Rename functions that return the build list to more precisely describe
the set of modules returned by the call.
Also eliminate a redundant call to LoadBuildList (right before
ListModules, which itself begins with the same call).
For #36460
Change-Id: I0fc4f9dd7602e0df5e166e329ee5d516d810ca53
Reviewed-on: https://go-review.googlesource.com/c/go/+/249878
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>
|
|
one file
Change-Id: I310c37c7f0ce5581f07cf6e27d1f6361d03b92ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/244077
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>
|
