Skip to content

G
golang
Switch branch/tag
  1. 20 Aug, 2018 7 commits
  3. 18 Aug, 2018 8 commits
    • Russ Cox's avatar
      cmd/go: fix module get -insecure · bf80e3b5
      Russ Cox authored 
      Need to actually use the flag for it to take effect.

Fixes #27049.

Change-Id: I57227b45f46f9dd67ecbf87c11bb2d08124bcfa0
Reviewed-on: https://go-review.googlesource.com/129801
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      bf80e3b5
    • Russ Cox's avatar
      cmd/go/internal/modconv: fix TestConvertLegacyConfig expectations · c5046bca
      Russ Cox authored 
      It was a bug to find that commit in the Masterminds/semver repo.
It's not part of the main repo but only part of an unmerged pull request.
The code was updated to try not to look at unmerged pull requests,
but the test was not. Worse, whether the code succeeds at not looking
at unmerged pull requests apparently depends on the git version.
Sigh.

Fixes #26754.
Fixes #27043.

Change-Id: Ib9e07f565906de4f1169244911a258396688f14d
Reviewed-on: https://go-review.googlesource.com/129800
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      c5046bca
    • Russ Cox's avatar
      cmd/go: fix go mod tidy crash on empty module · 5d750db0
      Russ Cox authored 
      Fixes #27066.

Change-Id: Iede4385ad86b42d7d90814965b161a7e64d29833
Reviewed-on: https://go-review.googlesource.com/129799
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      5d750db0
    • Russ Cox's avatar
      cmd/go: allow 'go run x.go' to use nearby internal imports in module mode · cc880de4
      Russ Cox authored 
      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: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      cc880de4
    • Russ Cox's avatar
      cmd/go: fix and reenable TestAccidentalGitCheckout · 239b8f2e
      Russ Cox authored 
      This is an important security problem so we shouldn't disable the test.
The second half was failing on case-sensitive file systems but the
first half is still good.

Fixes #22983.

Change-Id: I437bb4c9f78eb3177aa8b619e2357b2539566ca9
Reviewed-on: https://go-review.googlesource.com/129797
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      239b8f2e
    • Russ Cox's avatar
      cmd/go: update TestGoGetUpdateWithWildcard expected behavior · 714c141c
      Russ Cox authored 
      If you run

	go get -u github.com/rsc/foo/bar...

then the go get command has always worked hard to make sure
that it applies the wildcard after downloading rsc/foo.
(If it applied the wildcard only before downloading rsc/foo,
it would match nothing if you had an empty GOPATH before,
and you'd still have an empty afterward, which is clearly useless.)

The goal has always been that if you run the same go get
command twice, the second command doesn't find anything
new to do.

CL 19892 worked around an "internal error" failure but broke
the rule about the first command doing everything the second
command would. Suppose you had github.com/rsc/foo already,
with just github.com/rsc/foo/bar, and you run

	go get -u github.com/rsc/...

The wildcard first matches github.com/rsc/foo/bar, but suppose
updating the repo pulls down github.com/rsc/foo/baz, which
in turn depends on the non-existent package github.com/rsc/quux.
We need to reevaluate the wildcard after the download.

The new pattern match refactoring makes this easier and happened
to have corrected the behavior, but we missed a long test that
expected the old behavior.

Fix that long test.

Change-Id: I088473e7a90925e5c0f9697da9554a11456ddd08
Reviewed-on: https://go-review.googlesource.com/129796
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      714c141c
    • Russ Cox's avatar
      cmd/go: treat VCS errors as hard errors in module search · 850c964b
      Russ Cox authored 
      If we're looking for a module for a/b/c/d/e,
we check for a module named a/b/c/d/e,
then a/b/c/d, then a/b/c, then a/b, then a.
If we know the source repo for a/b/c and that
fails, we should report that error instead of
continuing the loop: a/b and a are useless,
and the error from a/b/c contains important
information.

The errors are now a bit more verbose than
I'd like but they will suffice for Go 1.11.

$ go get github.com/bradfitz/private/sonos
go get github.com/bradfitz/private/sonos: git ls-remote -q origin in /Users/rsc/pkg/mod/cache/vcs/61e3c76780847e514802ec6af8f940f641c6017f711444f05c59cb17ac46d456: exit status 128:
	remote: Repository not found.
	fatal: repository 'https://github.com/bradfitz/private/' not found
$ go list launchpad.net/gocheck
can't load package: package launchpad.net/gocheck: unknown import path "launchpad.net/gocheck": bzr branch --use-existing-dir https://launchpad.net/~niemeyer/gocheck/trunk . in /Users/rsc/pkg/mod/cache/vcs/f46ce2ae80d31f9b0a29099baa203e3b6d269dace4e5357a2cf74bd109e13339: exec: "bzr": executable file not found in $PATH
$

Fixes #26885.
Fixes #26982.

Change-Id: I2f9cf1853d2d68af18adad668c80513b6ba220d6
Reviewed-on: https://go-review.googlesource.com/129683
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      850c964b
    • Russ Cox's avatar
      cmd/go: remove go mod fix, add go help go.mod · 4864decf
      Russ Cox authored 
      "go mod fix" does work already done by nearly every other go command.
It was also confusing why we had both "go mod fix" and "go mod tidy".
Delete "go mod fix".

The main reason we kept "go mod fix" this long was for the discussion
of automatic go.mod updates in its documentation, which is now moved
into a new "go help go.mod".

Fixes #26831.

Change-Id: Ic95ca8918449ab79791d27998e02eb3377ac7972
Reviewed-on: https://go-review.googlesource.com/129682
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      4864decf
  5. 17 Aug, 2018 14 commits
    • Russ Cox's avatar
      cmd/go/internal/modfetch: correct TestCodeRepo expectation · 16a72125
      Russ Cox authored 
      The proxy protocol was simplified to only send
(and only receive) the Path and Version fields
in the JSON blob, not Name and Short.
(Those make sense when querying a VCS repo directly,
but not when talking about extracted modules.)
So don't expect them in the test.

Fixes #27042.

Change-Id: I3daacd668126e2227dcc8e6b89ee0cf0e3c8497c
Reviewed-on: https://go-review.googlesource.com/129684
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      16a72125
    • David du Colombier's avatar
      os: handle TMPDIR in TempDir on Plan 9 · 0a842d55
      David du Colombier authored 
      CL 129063 added a test in TestScript/mod_enabled,
which was failing on Plan 9.

The test was failing because the Init function
of the cmd/go/internal/modload package was
expecting ModRoot to be part of os.TempDir.

However, ModRoot was set to TMPDIR, while
os.TempDir is returning /tmp on Plan 9.

This change fixes the implementation of
os.TempDir on Plan 9 to handle the TMPDIR
environment variable, similarly to Unix.

Fixes #27065.

Change-Id: Id6ff926c5c379f63cab2dfc378fa6c15293fd453
Reviewed-on: https://go-review.googlesource.com/129775Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      0a842d55
    • Russ Cox's avatar
      cmd/go: do not turn list ./nonexist into a network lookup · 64fae252
      Russ Cox authored 
      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: 's avatarAlan Donovan <adonovan@google.com>
      64fae252
    • Russ Cox's avatar
      cmd/go: report which patterns match each package in list · 8dd27b18
      Russ Cox authored 
      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: 's avatarAlan Donovan <adonovan@google.com>
      8dd27b18
    • Russ Cox's avatar
      cmd/go: fix -gcflags, -ldflags not applying to current directory · 2ce6da0b
      Russ Cox authored 
      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: 's avatarAlan Donovan <adonovan@google.com>
      2ce6da0b
    • Russ Cox's avatar
      cmd/go: distinguish patterns from the results of matching them · d46587c4
      Russ Cox authored 
      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: 's avatarAlan Donovan <adonovan@google.com>
      d46587c4
    • Alan Donovan's avatar
      doc: describe golang.org/x/go/packages in go1.11 release notes · 08d10f9a
      Alan Donovan authored 
      Also, rename an HTML element ID to avoid duplicate.

Fixes golang/go#27038

Change-Id: Icc064a1cc86ddc794fc085d98b4cde3effff8ad0
Reviewed-on: https://go-review.googlesource.com/129635Reviewed-by: 's avatarAndrew Bonventre <andybons@golang.org>
Reviewed-by: 's avatarIan Cottrell <iancottrell@google.com>
      08d10f9a
    • Russ Cox's avatar
      go/doc: allow interior dot in heading, as in "go.mod" · c81d216d
      Russ Cox authored 
      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: 's avatarIan Lance Taylor <iant@golang.org>
      c81d216d
    • Russ Cox's avatar
      doc/code: drop mentions of GOPATH/pkg directory · 3e0f5f93
      Russ Cox authored 
      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/129679Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      3e0f5f93
    • Daniel Martí's avatar
      cmd/vet: don't suggest ... if it breaks a program · 2482451f
      Daniel Martí authored 
      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: 's avatarRuss Cox <rsc@golang.org>
      2482451f
    • Dan Johnson's avatar
      cmd/compile: make duplicate anonymous interface output deterministic · 876c6d1f
      Dan Johnson authored 
      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/129515Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      876c6d1f
    • Russ Cox's avatar
      cmd/go: document import "C" check from CL 129062 · 751ea936
      Russ Cox authored 
      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: 's avatarRuss Cox <rsc@golang.org>
      751ea936
    • Russ Cox's avatar
      cmd/go: ignore import "C" files in module loader in non-cgo mode · 974d5364
      Russ Cox authored 
      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: 's avatarBryan C. Mills <bcmills@google.com>
Reviewed-by: 's avatarDavid du Colombier <0intro@gmail.com>
      974d5364
    • Russ Cox's avatar
      cmd/go: ignore /tmp/go.mod · c265c893
      Russ Cox authored 
      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: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      c265c893
  7. 16 Aug, 2018 3 commits
  9. 14 Aug, 2018 4 commits
  11. 13 Aug, 2018 3 commits
  13. 12 Aug, 2018 1 commit