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>
A flag setting like -gcflags=-e applies only to the packages
named on the command line, not to their dependencies.
The way we used to implement this was to remember the
command line arguments, reinterpret them as pattern matches
instead of package argument generators (globs), and apply them
during package load. The reason for this complexity was to
address a command-line like:
go build -gcflags=-e fmt runtime
The load of fmt will load dependencies, including runtime,
and the load of runtime will reuse the result of the earlier load.
Because we were computing the effective -gcflags for each
package during the load, we had to have a way to tell, when
encountering runtime during the load of fmt, that runtime had
been named on the command line, even though we hadn't
gotten that far. That would be easy if the only possible
arguments were import paths, but we also need to handle
go build -gcflags=-e fmt runt...
go build -gcflags=-e fmt $GOROOT/src/runtime
go build -gcflags=-e fmt $GOROOT/src/runt...
and so on.
The match predicates usually did their job well, but not
always. In particular, thanks to symlinks and case-insensitive
file systems and unusual ways to spell file paths, it's always
been possible in various corner cases to give an argument
that evalutes to the runtime package during loading but
failed to match it when reused to determine "was this package
named on the command line?"
CL 109235 fixed one instance of this problem by making
a directory pattern match case-insensitive on Windows, but that
is incorrect in some other cases and doesn't address the root problem,
namely that there will probably always be odd corner cases
where pattern matching and pattern globbing are not exactly aligned.
This CL eliminates the assumption that pattern matching
and pattern globbing are always completely in agreement,
by simply marking the packages named on the command line
after the package load returns them. This means delaying
the computation of tool flags until after the load too,
for a few different ways packages are loaded.
The different load entry points add some complexity,
which is why the original approach seemed more attractive,
but the original approach had complexity that we simply
didn't recognize at the time.
This CL then rolls back the CL 109235 pattern-matching change,
but it keeps the test introduced in that CL. That test still passes.
In addition to fixing ambiguity due to case-sensitive file systems,
this new approach also very likely fixes various ambiguities that
might arise from abuse of symbolic links.
Fixes#24232.
Fixes#24456.
Fixes#24750.
Fixes#25046.
Fixes#25878.
Change-Id: I0b09825785dfb5112fb11494cff8527ebf57966f
Reviewed-on: https://go-review.googlesource.com/129059
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
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>
Also, rename an HTML element ID to avoid duplicate.
Fixesgolang/go#27038
Change-Id: Icc064a1cc86ddc794fc085d98b4cde3effff8ad0
Reviewed-on: https://go-review.googlesource.com/129635
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Only the expected headings are affected.
Diffing the output of "go run headscan.go" before and after:
$ diff head1 head2
26a27,28
> Edit go.mod from tools or scripts
> Make go.mod semantically consistent
168c170
< 141 headings found
---
> 143 headings found
$
Fixes#26938.
Change-Id: I204fd982a60773aa26880cd19eed890c373b8ab6
Reviewed-on: https://go-review.googlesource.com/129677
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It's already half gone and later will be all gone.
It's not worth explaining in an introduction doc.
Fixes#24506
Updates #4719
Change-Id: Ie48128b3aa090d84e0e734aa45f14a4480292913
Reviewed-on: https://go-review.googlesource.com/129679
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is possible to write a function that seems to wrap a print/printf
call, but then doesn't. For example, if the string parameter we thought
was the format is used as another argument.
One option would be to make vet's print analysis smarter, to detect when
format strings are indeed used like we initially suspected.
However, I've opted for a simpler solution - check if the print/printf
call is already using more than one variadic argument, in which case
using an ellipsis in the last one would break the program:
// too many arguments in call to fmt.Printf
fmt.Printf(format, arg0, args...)
Fixes#26979.
Change-Id: I39371f1cec8483cfd2770a91670c1e80cbb9efdf
Reviewed-on: https://go-review.googlesource.com/129575
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Ranging through a map is non-deterministic and there can be duplicate
entries in the set (with the same name) which don't have identical
definitions in some cases.
Fixes#27013
Change-Id: I378c48bc359c10b25b9238e0c663b498455b19fd
Reviewed-on: https://go-review.googlesource.com/129515
Reviewed-by: Russ Cox <rsc@golang.org>
Added this locally but then broke the first rule of Gerrit
and clicked Submit instead of running "git submit".
Change-Id: I83c28d9151c566e9b2092e2613d67731a5d64beb
Reviewed-on: https://go-review.googlesource.com/129678
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Obviously, including files that import "C" when cgo is disabled is wrong.
The package load step correctly excludes them and finds no files at all,
which then causes a failure.
Fixes#26927.
Change-Id: I00e6d6450e783d467d20bde99e91240ecb0db837
Reviewed-on: https://go-review.googlesource.com/129062
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: David du Colombier <0intro@gmail.com>
Two different people have created /tmp/go.mod for experimentation
and then had other tests that create fresh work directories
below /tmp fail unexpectedly because the go command finds
/tmp/go.mod. Refuse to use /tmp/go.mod. /tmp/anything/go.mod is fine.
Fixes#26708.
Change-Id: I2a4f61ea63099cff59fbf9e8798e5dcefefd5557
Reviewed-on: https://go-review.googlesource.com/129063
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
the function libc_errno returns a pointer to a signed-32 bit quantity,
not a 64-bit quantity.
Fixes#27004
Change-Id: I0623835ee34fd9655532251f096022a5accb58cd
Reviewed-on: https://go-review.googlesource.com/129475
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
mkalldocs.sh was run and it also picked up a doc change introduced in
CL 128935, where it wasn't run.
Fixes#27030
Change-Id: Ie13fdb71cd7d5481366a02eb711ca48f094026fd
Reviewed-on: https://go-review.googlesource.com/129576
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In previous versions of Go including 1.10, an empty line would break the
alignment of elements within an expression list.
golang.org/cl/104755 changed the heuristic, with the side effect that
empty lines no longer broke the table alignment.
A prior fix (https://go-review.googlesource.com/c/go/+/125260, reverted)
introduced another regression (#26930) which this change doesn't produce.
Added test cases for both #26352 and #26930.
Fixes#26352.
Updates #26930.
Change-Id: I371f48e6f3620ebbab53f2128ec5e58bcd4a62f1
Reviewed-on: https://go-review.googlesource.com/129256
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Alan Donovan <adonovan@google.com>
This reverts commit c116265eb3.
The change, while addressing issue #26352, introduced another
regression (#26930), which is worse. Reverting this change in
favor of a better fix for the original issue.
Updates #26352.
Fixes#26930.
Change-Id: I71ad12a8212992cce5c1e73907d1f7460f98d9e8
Reviewed-on: https://go-review.googlesource.com/129255
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This commit adds an explicit nil check for closure calls on wasm,
so calling a nil func causes a proper panic instead of crashing on the
WebAssembly level.
Change-Id: I6246844f316677976cdd420618be5664444c25ae
Reviewed-on: https://go-review.googlesource.com/127759
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The default WASM RoundTripper is implemented using
the browser Fetch API. Some options don't readily map to
existing http.Request options, so we use the precedent
set by the TrailerPrefix constant to allow a user to configure
the "mode" and "credentials" options by supplying them
as headers in the http.Request.
Updates #26769
Change-Id: If42d24418c4ffb17211f57e36708cf460fb4c579
GitHub-Last-Rev: b230502084
GitHub-Pull-Request: golang/go#26784
Reviewed-on: https://go-review.googlesource.com/127718
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
GOROOT/src/cmd uses GOROOT/src/cmd/vendor, which module
mode simply cannot handle.
Exposed by making ... match the standard library, which it still should.
But for now it's fine to just exclude commands.
Change-Id: I2201b94445f11239022de8a2473aa3b573f405c0
Reviewed-on: https://go-review.googlesource.com/129055
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Tools using go list -compiled expect to see an Imports list
that includes all the imports in CompiledGoFiles.
Make sure the list includes the cgo-generated imports.
Fixes#26136.
Change-Id: I6cfe14063f8edfe65a7af37522c7551272115b82
Reviewed-on: https://go-review.googlesource.com/128935
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
We used to try a git fetch --depth=1 of a specific hash and
distinguish between an error meaning
"that's not a hash I can give you directly"
(in which case we fall through and pull the whole repo)
and some other error like connection failure, bad ssh key
(in which case we give up).
We've had repeated problems trying to understand the
error meanings so just stop doing that, and fall back to
trying a full fetch on any error at all. If the error really
was some kind of network or auth or i/o problem, then
it will happen the second time and we can report it then.
Fixes#26894.
Change-Id: If1eaaddb87e8bfeff7a3894cce4ecef39802198c
Reviewed-on: https://go-review.googlesource.com/128904
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
CL 77110 arranged for caching and redisplaying compiler output
when reusing a compile artifact from the build cache.
It neglected to redisplay compiler and linker output when avoiding
the compile and link steps by reusing the target output binary
as a cached result. It also neglected to redisplay compiler and linker
output when avoiding the compile and link (and test) steps by reusing
cached test output.
This CL brings back the compiler and linker output in those two cases,
provided it can be found in the build cache. If it can't be found in the
build cache, then the go command still reuses the binaries and avoids
the compile/link/test steps. (It's not worth doing all that work again
just to repeat diagnostic output.)
Fixes#23877.
Change-Id: I25bc054d93a88c039bcb8c5683fe4ac5cb1ee544
Reviewed-on: https://go-review.googlesource.com/128903
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
After running mkalldocs.sh this also adds some previously missing parts
to alldocs.go
Change-Id: Ifa624c54543fd31d699a0d4bb5df7b1969bf941c
Reviewed-on: https://go-review.googlesource.com/128915
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When we added v2.0.0+incompatible we generalized the API
enough to make it easy to also accepting these gopkg-specific
v2-unstable suffixes. Do that.
Fixes#23989.
Change-Id: Ieabed11a5250c2999d73450c10b20f4c645ad445
Reviewed-on: https://go-review.googlesource.com/128901
Reviewed-by: Bryan C. Mills <bcmills@google.com>
For a package in the module root, using the containing directory name
might mean the directory in the module cache, in which case the
executable has a final @v1.2.3 in it, which is no good. Fix that.
While we're here, change go install example.com/cmd/foo/v2 to
install foo instead of the less useful "v2".
Fixes#24667.
Fixes#26869.
Change-Id: Ie40ca1bc9e27955441f1cdb7abd3a1f69034c9f5
Reviewed-on: https://go-review.googlesource.com/128900
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If we're using -mod=vendor then we effectively load
a fake build list from vendor/modules.txt.
Do not write it back to go.mod.
Fixes#26704.
Change-Id: Ie79f2103dc16d0b7fe0c884e77ba726c7e04f2e4
Reviewed-on: https://go-review.googlesource.com/128899
Reviewed-by: Bryan C. Mills <bcmills@google.com>
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>
go list all was not behaving as documented - it did not pick up
test dependencies except when running in "go test" and "go vet".
It should pick them up always.
Also the module loader was ignoring tests when using "go list -test",
which led to load failures.
Fixing all required adjustments to mod_patterns test.
Removed error-prone exact listings.
Fixes#26279.
Fixes#26906.
Change-Id: I9c5acaf2275be20fd2349859589502190d3e7a78
Reviewed-on: https://go-review.googlesource.com/128358
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When a test variant of a package is created, the two versions cannot
share memory for the fields that contain information about their
imports, as these will be different between the two packagse.
Both the Internal.Imports and the Imports fields must be able to be
updated in the test variant without affecting the values of the
original.
Fixesgolang/go#26880
Change-Id: Id61fad7d976e179c6c7711a394ce43ec8302fd7a
Reviewed-on: https://go-review.googlesource.com/128836
Reviewed-by: Russ Cox <rsc@golang.org>
go mod download provides a way to force downloading
of a particular module version into the download cache
and also to locate its cached files.
Forcing downloads is useful for warming caches, such as
in base docker images.
Finding the cached files allows caching proxies to use
go mod download as the way to obtain module files
on cache miss.
Fixes#26577.
Fixes#26610.
Change-Id: Ib8065bcce07c9f5105868ec1d87887ef4871f07e
Reviewed-on: https://go-review.googlesource.com/128355
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
See the added comment for the reasoning behind the workaround.
Fixes#26868.
Change-Id: Idede020ec88a49595dc233d9a1346b12691186f4
Reviewed-on: https://go-review.googlesource.com/128815
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Recent versions of Delve pay attention to the debugging changes
for 1.11, which causes different (better!) debugging behavior.
Update the reference data to reflect this.
Change-Id: I2efa165aa71769ace9f7885b4ce3420cd9b2d3a3
Reviewed-on: https://go-review.googlesource.com/128697
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
No test because testing this would require building a new toolchain
with a different experiment.
Fixes#26883
Change-Id: Iadd513d0920ef12463006dd2a61e94370dd13f68
Reviewed-on: https://go-review.googlesource.com/128735
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
modload.Import contains a loop that looks for the module containing a package.
Because we overload Import to locate both packages and modules, that loop
contains a bunch of special-cases for modules with empty roots.
In this change, we factor out the loop into a new function (QueryPackage) and
use that directly in modget.getQuery. That restores the invariant that
the paths passed to modload.Import must be importable packages, and fixes 'go
get' lookups for packages that have moved between a module and submodules with
the same path prefix.
Updates #26602.
Change-Id: I8bc8340c17f2df062d03ce720f4dc18b2ba406b2
Reviewed-on: https://go-review.googlesource.com/128136
Reviewed-by: Russ Cox <rsc@golang.org>
Previously, we reported errors directly in (*loader).load via base.Errorf.
Unfortunately, (*loader).load can be called from contexts in which such errors
should not be considered fatal, such as by load.PackagesAndErrors.
Instead, we save the errors in pkg.err and modify Lookup to return that error.
This change is a bit awkward: we end up suppressing a "no Go files" error for
packages at the root of newly-imported modules, even if they really do contain
source files. I believe that that's due to a special-case lookup for modules in
the build list, which allows us to "validate" imports for modules in the build
list even though we haven't actually downloaded their sources (or verified that
they actually contain the requested package). The fix for that issue is in the
change that follows this one.
Fixes#26602.
Change-Id: I16f00ceb143fbb797cfc3cb07fd08aeb6154575b
Reviewed-on: https://go-review.googlesource.com/127936
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In my previous change, I didn't use the correct functions for continuing
to record type informations after errors. Change to using the correct
functions, and add a comment to clarify in expr.go.
Updates #22467
Change-Id: I66ebb636ceb2b994db652343430f0551db0050c3
Reviewed-on: https://go-review.googlesource.com/128835
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This test passes, but it encodes several behaviors that I think are bugs.
I suggest that we check it in as-is, and we can update it as the bugs are fixed.
Change-Id: Icb073de9cb13036dbccadb4ff2cb3169ffb56236
Reviewed-on: https://go-review.googlesource.com/128137
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Fixes#26713.
Tested with Git 2.7.4. Older Gits may or may not work.
Change-Id: Ib72d751388dfbb50030191ae40f788d1402834b2
Reviewed-on: https://go-review.googlesource.com/126956
Reviewed-by: Russ Cox <rsc@golang.org>
In previous versions of Go including 1.10, an empty line would break the
alignment of elements within an expression list.
golang.org/cl/104755 changed the heuristic, with the side effect that
empty lines no longer broke the table alignment.
Reintroduce the behavior and add a regression test for it.
Fixes#26352.
Change-Id: I410bcff4cba25c7f8497d46bd7890a2c7ee11d46
Reviewed-on: https://go-review.googlesource.com/125260
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
