1. 13 Nov, 2017 7 commits
  2. 12 Nov, 2017 2 commits
  3. 11 Nov, 2017 2 commits
  4. 10 Nov, 2017 21 commits
  5. 09 Nov, 2017 8 commits
    • Than McIntosh's avatar
      cmd/go: avoid crashing on 'go test -n' · 95322a3a
      Than McIntosh authored
      Fix a buglet in the go command support for 'go test -n': check for
      nil output buffer in action routine.
      
      Fixes #22644
      
      Change-Id: I2566e3bb3d53d0324c4ddd6fec5d30224bf290df
      Reviewed-on: https://go-review.googlesource.com/76710
      Run-TryBot: Than McIntosh <thanm@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      95322a3a
    • Ariel Mashraki's avatar
      text/template: remove unused lexer field · 2f53fb58
      Ariel Mashraki authored
      The lastPos field used in the past to track the line number of a token.
      it's irrelevant anymore, and we can remove it.
      
      Change-Id: I42c0bf55e884b79574a7da4926489f2d77618cd0
      Reviewed-on: https://go-review.googlesource.com/49591Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      2f53fb58
    • Cherry Zhang's avatar
      cmd/compile: remove unnecessary tmpdir in ssa_test · 1c322524
      Cherry Zhang authored
      I added this in CL 76024 in order to do compile+link+run. This
      is no longer necessary after CL 76551, which changed it back to
      "go run". Remove it.
      
      Change-Id: Ifa744d4b2f73f33cad056b24051821e43638cc7f
      Reviewed-on: https://go-review.googlesource.com/76690
      Run-TryBot: Cherry Zhang <cherryyz@google.com>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      1c322524
    • Jeff R. Allen's avatar
      cmd/compile: do not write slices/strings > 2g · d7ac9bb9
      Jeff R. Allen authored
      The linker will refuse to work on objects larger than
      2e9 bytes (see issue #9862 for why).
      
      With this change, the compiler gives a useful error
      message explaining this, instead of leaving it to the
      linker to give a cryptic message later.
      
      Fixes #1700.
      
      Change-Id: I3933ce08ef846721ece7405bdba81dff644cb004
      Reviewed-on: https://go-review.googlesource.com/74330Reviewed-by: 's avatarRobert Griesemer <gri@golang.org>
      Run-TryBot: Robert Griesemer <gri@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      d7ac9bb9
    • Alberto Donizetti's avatar
      cmd/vendor/github.com/google/pprof: fix iOS builders · 8fc64a30
      Alberto Donizetti authored
      The recent vendored pprof update broke the iOS builders. The issue was
      reported and patched upstream. Re-vendor the internal pprof copy.
      
      Updates vendored pprof to commit 9e20b5b106e946f4cd1df94c1f6fe3f88456628d
      from github.com/google/pprof (2017-11-08).
      
      Fixes #22612
      
      Change-Id: I74c46c75e92ce401e605c55e27d8545c0d66082c
      Reviewed-on: https://go-review.googlesource.com/76651Reviewed-by: 's avatarElias Naur <elias.naur@gmail.com>
      8fc64a30
    • Russ Cox's avatar
      cmd/go: always update mtime during go install / go build -o / go test -c · 18361604
      Russ Cox authored
      Even if the go command can see that the target is up-to-date
      an mtime-based build system invoking the go command may not
      be able to tell. Update the mtime to make clear that the target is
      up-to-date, and also to hide exactly how smart the go command
      is or is not. This keeps users (and programs) from depending on
      the exact details of the go command's staleness determination.
      
      Without this I believe we will get a stream of (completely reasonable)
      bug reports that "go install (or go test -c) did not update the binary
      after I trivially changed the source code or touched a source file".
      
      Change-Id: I920e4aaed2a57319e3c0c37717f872bc059e484e
      Reviewed-on: https://go-review.googlesource.com/76590
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
      18361604
    • Russ Cox's avatar
      cmd/go: treat cached test results as satisfying any timeout · 48f2a55a
      Russ Cox authored
      We want test caching to work even for people with scripts
      that set a non-default test timeout. But then that raises the
      question of what to do about runs with different timeouts:
      is a cached success with one timeout available for use when
      asked to run the test with a different timeout?
      
      This CL answers that question by saying that the timeout applies
      to the overall execution of either running the test or displaying
      the cached result, and displaying a cached result takes no time.
      So it's always OK to record a cached result, regardless of timeout,
      and it's always OK to display a cached result, again regardless of timeout.
      
      Fixes #22633.
      
      Change-Id: Iaef3602710e3be107602267bbc6dba9a2250796c
      Reviewed-on: https://go-review.googlesource.com/76552
      Run-TryBot: Russ Cox <rsc@golang.org>
      TryBot-Result: Gobot Gobot <gobot@golang.org>
      Reviewed-by: 's avatarroger peppe <rogpeppe@gmail.com>
      Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
      48f2a55a
    • Russ Cox's avatar
      cmd/go: implement per-package asmflags, gcflags, ldflags, gccgoflags · 5993251c
      Russ Cox authored
      It has always been problematic that there was no way to specify
      tool flags that applied only to the build of certain packages;
      it was only to specify flags for all packages being built.
      The usual workaround was to install all dependencies of something,
      then build just that one thing with different flags. Since the
      dependencies appeared to be up-to-date, they were not rebuilt
      with the different flags. The new content-based staleness
      (up-to-date) checks see through this trick, because they detect
      changes in flags. This forces us to address the underlying problem
      of providing a way to specify per-package flags.
      
      The solution is to allow -gcflags=pattern=flags, which means
      that flags apply to packages matching pattern, in addition to the
      usual -gcflags=flags, which is now redefined to apply only to
      the packages named on the command line.
      
      See #22527 for discussion and rationale.
      
      Fixes #22527.
      
      Change-Id: I6716bed69edc324767f707b5bbf3aaa90e8e7302
      Reviewed-on: https://go-review.googlesource.com/76551
      Run-TryBot: Russ Cox <rsc@golang.org>
      Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
      5993251c