| Age | Commit message (Collapse) | Author |
|---|
|
Don't associate command-line-arguments with a module. Even though the
sources in the command-line-arguments package may exist within the
module's packages, the command-line-arguments package is distinct from
the package in the module. It has its own identity, and further, even if
all the same sources are listed, build tag filtering is not applied for
command-line-arguments.
For #45713
Change-Id: I555752021d58ea25e65699b4959f787ea5fa2cda
Reviewed-on: https://go-review.googlesource.com/c/go/+/339170
Trust: Michael Matloob <matloob@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
mainPackagesOnly now includes non-main packages matched by literal
arguments in the returned slice, since their errors must be reported.
GoFilesPackages attaches the same error to its package if
opts.MainOnly is true. This changes the error output of 'go run'
slightly, but it seems like an imporovement.
For #42088
Change-Id: I8f2942470383af5d4c9763022bc94338f5314b07
Reviewed-on: https://go-review.googlesource.com/c/go/+/310829
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>
|
|
will be written
Then, write the 'go.mod' file with that version before further
processing. That way, if the command errors out due to a change in
behavior, the reason for the change in behavior will be visible in the
file diffs.
If the 'go.mod' file cannot be written (due to -mod=readonly or
-mod=vendor), assume Go 1.11 instead of the current Go release.
(cmd/go has added 'go' directives automatically, including in 'go mod
init', since Go 1.12.)
For #44976
Change-Id: If9d4af557366f134f40ce4c5638688ba3bab8380
Reviewed-on: https://go-review.googlesource.com/c/go/+/302051
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>
|
|
Fixes #44803
Change-Id: Ie6ee2e3bca1809c91ecedec75d2c6620da914b29
Reviewed-on: https://go-review.googlesource.com/c/go/+/298752
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>
|
|
The new error message tells the user what was wrong (no go.mod found)
and directs them to 'go help modules', which links to tutorials.
Fixes #44745
Change-Id: I98f31fec4a8757eb1792b45491519da4c552cb0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/298650
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>
|
|
Change-Id: Ib689e5793d9cb372e759c4f34af71f004010c822
GitHub-Last-Rev: d63798388e5dcccb984689b0ae39b87453b97393
GitHub-Pull-Request: golang/go#44259
Reviewed-on: https://go-review.googlesource.com/c/go/+/291949
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
|
|
If 'go install' is invoked in module mode outside a module with a
package that could only be loaded from a module, it will now suggest
running 'go install pkg@latest'.
'go install' will still work outside a module on packages in std and
cmd, as well as .go files specified on the command line.
Fixes #42638
Change-Id: Ib0963935f028b7656178bc04a279b1114de35fbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/277355
Run-TryBot: Jay Conrod <jayconrod@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@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>
|
|
Previously, ImportMissingError said
"cannot find module providing package …"
even when we didn't even attempt to find such a module.
Now, we write "no module requirement provides package …"
when we did not attempt to identify a suitable module,
and suggest either 'go mod tidy' or 'go get -d' as appropriate.
Fixes #41576
Change-Id: I979bb999da4066828c54d99a310ea66bb31032ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/258298
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>
|
|
Since CL 254369, 'go mod graph' now reports an error when invoked
outside a module. This broke the mod_outside test, which expected
'go mod graph' to succeed with no output.
Change-Id: Ic30ee68f1f4c4d33795bdf7df70a7631fb9395e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/255017
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>
|
|
With this change, 'go install' will install executables in module mode
without using or modifying the module in the current directory, if
there is one.
For #40276
Change-Id: I922e71719b3a4e0c779ce7a30429355fc29930bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/254365
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
|
|
Previously, we just reported an error for "all". Now we report an
error for any pattern that matches modules in the build list. The
build list can only contain the module "command-line-arguments", so
these patterns are not meaningful.
Fixes #35728
Change-Id: Ibc736491ec9164588f9657c09d1b9683b33cf1de
Reviewed-on: https://go-review.googlesource.com/c/go/+/208222
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
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>
|
|
Also, test that 'go mod download' without arguments reports an error.
Fixes #32027
Change-Id: I873fc59fba4c78ee2b4f49f0d846ee2ac0eee4db
Reviewed-on: https://go-review.googlesource.com/c/go/+/202697
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Also, in cmd/doc, avoid calling 'go list -m all' when in module mode
outside a module since it's now an error.
Fixes #32027
Change-Id: I7224c7fdf7e950bce6c058ab2a5837c27ba3b899
Reviewed-on: https://go-review.googlesource.com/c/go/+/200297
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
When in module mode outside of any module, 'go build' and most other
commands will now report an error instead of resolving a package path
to a module.
Previously, most commands would attempt to find the latest version of
a module providing the package. This could be very slow if many
packages needed to be resolved this way. Since there is no go.mod file
where module requirements can be saved, it's a repeatedly slow and
confusing experience.
After this change, 'go build' and other commands may still be used
outside of a module on packages in std and source files (.go
arguments) that only import packages in std. Listing any other package
on the command line or importing a package outside std will cause an
error.
'go get' is exempted from the new behavior, since it's expected that
'go get' resolves paths to modules at new versions.
Updates #32027
Change-Id: Ia9d3a3b4ad738ca5423472e17818d62b96a2c959
Reviewed-on: https://go-review.googlesource.com/c/go/+/198778
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
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>
|
|
Was 50 seconds on unloaded Mac laptop; now 27.
Still longer than I would like, but every little bit helps.
For #26473.
Change-Id: Id4be016ee1555cbc3512eca0ae10236d7f06bd02
Reviewed-on: https://go-review.googlesource.com/c/go/+/177398
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Use the actual loader result in findModule instead of making
assumptions about nesting in the build list.
As a side-effect, this produces much clearer error messages for
packages that (for one reason or another) failed to load.
Adjust the package and module path outside a module to
"command-line-arguments". That string already appears in the output of
a number of (module-mode and GOPATH-mode) commands for file arguments,
and as far as I can tell operation outside a module is currently the
only case in which the module path of a package is not actually a
prefix of the import path.
Fixes #28011
Fixes #27099
Fixes #28943
Updates #27102
Updates #28459
Updates #27063
Change-Id: I61d5556df7b1b7d1efdaffa892f0e3e95b612d87
Reviewed-on: https://go-review.googlesource.com/c/153459
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
Since CL 148517, several commands (including list and get) work when
GO111MODULE=on even when no go.mod file is present. This broke an
assumption made by "fix" and "generate" which caused panics when run
with a list of .go files (whether or not the command was run inside a
module).
This change fixes those assumptions and adds test cases for other
commands run outside modules.
Fixes #29097
Change-Id: I7927559769c5d4617d73eb63f3b17e2f26d8c219
Reviewed-on: https://go-review.googlesource.com/c/153158
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
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>
|
