1. 20 Aug, 2018 9 commits
  2. 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
  3. 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
  4. 16 Aug, 2018 3 commits
  5. 14 Aug, 2018 4 commits
  6. 13 Aug, 2018 2 commits