Skip to content

G
golang
Switch branch/tag
  1. 09 Nov, 2017 5 commits
    • 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
    • Russ Cox's avatar
      cmd/go: move cfg.ExternalLinkingForced to internal/load · 98f1bfbb
      Russ Cox authored 
      It needs to refer to packages, so it can no longer be in cfg.
No semantic changes here.

Can now be unexported, so that was a net win anyway.

Change-Id: I58bf6cdcd435e6e019291bb8dcd5d5b7f1ac03a3
Reviewed-on: https://go-review.googlesource.com/76550
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarDavid Crawshaw <crawshaw@golang.org>
      98f1bfbb
  3. 08 Nov, 2017 8 commits
  5. 07 Nov, 2017 16 commits
  7. 06 Nov, 2017 11 commits