Skip to content

G
golang
Switch branch/tag
  1. 09 Feb, 2017 1 commit
    • Daniel Theophanes's avatar
      [release-branch.go1.8] database/sql: record the context error in Rows if canceled · 3ade5406
      Daniel Theophanes authored 
      Previously it was intended that Rows.Scan would return
an error and Rows.Err would return nil. This was problematic
because drivers could not differentiate between a normal
Rows.Close or a context cancel close.

The alternative is to require drivers to return a Scan to return
an error if the driver is closed while there are still rows to be read.
This is currently not how several drivers currently work and may be
difficult to detect when there are additional rows.

At the same time guard the the Rows.lasterr and prevent a close
while a Rows operation is active.

For the drivers that do not have Context methods, do not check for
context cancelation after the operation, but before for any operation
that may modify the database state.

Fixes #18961

Change-Id: I49a25318ecd9f97a35d5b50540ecd850c01cfa5e
Reviewed-on: https://go-review.googlesource.com/36485Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/36614Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      3ade5406
  3. 08 Feb, 2017 1 commit
    • Russ Cox's avatar
      [release-branch.go1.8] crypto/x509: check for new tls-ca-bundle.pem last · 0545006b
      Russ Cox authored 
      We added CentOS 7's /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
to the list in response to #17549 - not being able to find any certs otherwise.

Now we have #18813, where CentOS 6 apparently has both that file
and /etc/pki/tls/certs/ca-bundle.crt, and the latter is complete while
the former is not.

Moving the new CentOS 7 file to the bottom of the list should fix both
problems: the CentOS 7 system that didn't have any of the other files
in the list will still find the new one, and existing systems will still
keep using what they were using instead of preferring the new path
that may or may not be complete on some systems.

Fixes #18813.

Change-Id: I5275ab67424b95e7210e14938d3e986c8caee0ba
Reviewed-on: https://go-review.googlesource.com/36429
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: 's avatarAdam Langley <agl@golang.org>
Reviewed-on: https://go-review.googlesource.com/36530
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      0545006b
  5. 07 Feb, 2017 6 commits
  7. 06 Feb, 2017 3 commits
  9. 02 Feb, 2017 1 commit
  11. 01 Feb, 2017 1 commit
  13. 31 Jan, 2017 1 commit
    • Russ Cox's avatar
      [release-branch.go1.8] all: final merge of master into Go 1.8 release branch · d8d2f036
      Russ Cox authored 
      After this, we will merge some of the dev work like
type aliases and inlining into master, so any additional
changes for the Go 1.8 release will need to be cherry-picked,
not merged.

3e55059f cmd/dist: really skip the testsanitizers tests on Android
09496599 runtime: add explicit (void) in C to avoid GCC 7 problem
4cffe2b6 cmd/dist: use the target GOOS to skip the test for issue 18153
6bdb0c11 doc: update go1.8 release notes after TxOptions change
09096bd3 cmd/go: update alldocs after CL 35150
96ea0918 cmd/compile: use CMPWU for 32-bit or smaller unsigned Geq on ppc64{,le}
21a8db1c doc: document go1.7.5

Change-Id: I9e6a30c3fac43d4d4d15e93054ac00964c3ee958
      d8d2f036
  15. 30 Jan, 2017 2 commits
  17. 29 Jan, 2017 2 commits
  19. 28 Jan, 2017 1 commit
  21. 27 Jan, 2017 1 commit
  23. 26 Jan, 2017 6 commits
  25. 25 Jan, 2017 2 commits
  27. 24 Jan, 2017 7 commits
  29. 23 Jan, 2017 1 commit
    • Keith Randall's avatar
      runtime: amd64, use 4-byte ops for memmove of 4 bytes · a96e117a
      Keith Randall authored 
      memmove used to use 2 2-byte load/store pairs to move 4 bytes.
When the result is loaded with a single 4-byte load, it caused
a store to load fowarding stall.  To avoid the stall,
special case memmove to use 4 byte ops for the 4 byte copy case.

We already have a special case for 8-byte copies.
386 already specializes 4-byte copies.
I'll do 2-byte copies also, but not for 1.8.

benchmark                 old ns/op     new ns/op     delta
BenchmarkIssue18740-8     7567          4799          -36.58%

3-byte copies get a bit slower.  Other copies are unchanged.
name         old time/op   new time/op   delta
Memmove/3-8   4.76ns ± 5%   5.26ns ± 3%  +10.50%  (p=0.000 n=10+10)

Fixes #18740

Change-Id: Iec82cbac0ecfee80fa3c8fc83828f9a1819c3c74
Reviewed-on: https://go-review.googlesource.com/35567
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarDavid Chase <drchase@google.com>
      a96e117a
  31. 21 Jan, 2017 1 commit
  33. 20 Jan, 2017 3 commits
    • Ian Lance Taylor's avatar
      misc/cgo/test: pass current environment to syscall.Exec · 1be957d7
      Ian Lance Taylor authored 
      This is needed for typical tests with gccgo, as it passes the
LD_LIBRARY_PATH environment variable to the new program.

Change-Id: I9bf4b0dbdff63f5449c7fcb8124eaeab10ed7f34
Reviewed-on: https://go-review.googlesource.com/35481
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      1be957d7
    • Ian Lance Taylor's avatar
      misc/cgo/test: fix test when using GCC 7 · ec654e22
      Ian Lance Taylor authored 
      With GCC 7 (not yet released), cgo fails with errors like

./sigaltstack.go:65:8: call of non-function C.restoreSignalStack

I do not know precisely why. Explicitly declaring that there are no
arguments to the static function is a simple fix for the debug info.

Change-Id: Id96e1cb1e55ee37a9f1f5ad243d7ee33e71584ac
Reviewed-on: https://go-review.googlesource.com/35480
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      ec654e22
    • Keith Randall's avatar
      cmd/compile: don't use nilcheck information until the next block · 256a605f
      Keith Randall authored 
      When nilcheck runs, the values in a block are not in any particular
order.  So any facts derived from examining the blocks shouldn't be
used until we reach the next block.

This is suboptimal as it won't eliminate nil checks within a block.
But it's probably a better fix for now as it is a much smaller change
than other strategies for fixing this bug.

nilptr3.go changes are mostly because for this pattern:
  _ = *p
  _ = *p
either nil check is fine to keep, and this CL changes which one
the compiler tends to keep.
There are a few regressions from code like this:
  _ = *p
  f()
  _ = *p
For this pattern, after this CL we issue 2 nil checks instead of one.
(For the curious, this happens because intra-block nil check
 elimination now falls to CSE, not nilcheck proper.  The former
 pattern has two nil checks with the same store argument.  The latter
 pattern has two nil checks with different store arguments.)

Fixes #18725

Change-Id: I3721b494c8bc9ba1142dc5c4361ea55c66920ac8
Reviewed-on: https://go-review.googlesource.com/35485Reviewed-by: 's avatarCherry Zhang <cherryyz@google.com>
      256a605f