[release-branch.go1.8] go1.8rc3

Change-Id: Ie306bb5355f56113356fc141f3c1a56872b39f9e
Reviewed-on: https://go-review.googlesource.com/35836
Reviewed-by: Chris Broadfoot <cbro@golang.org>

[release-branch.go1.8] all: merge master into release-branch.go1.8

78860b2ad2 cmd/go: don't reject ./... matching top-level file outside GOPATH
2b283cedef database/sql: fix race when canceling queries immediately
1cf08182f9 go/printer: fix format with leading comments in composite literal
b531eb3062 runtime: reorder modules so main.main comes first
165cfbc409 database/sql: let tests wait for db pool to come to expected state
ea73649343 doc: update gccgo docs
1db16711f5 doc: clarify what to do with Go 1.4 when installing from source
3717b429f2 doc: note that plugins are not fully baked
98842cabb6 net/http: don't send body on redirects for 301, 302, 303 when GetBody is set
314180e7f6 net/http: fix a nit
aad06da2b9 cmd/link: mark DWARF function symbols as reachable
be9dcfec29 doc: mention testing.MainStart signature change
a96e117a58 runtime: amd64, use 4-byte ops for memmove of 4 bytes
4cce27a3fa cmd/compile: fix constant propagation through s390x MOVDNE instructions
1be957d703 misc/cgo/test: pass current environment to syscall.Exec
ec654e2251 misc/cgo/test: fix test when using GCC 7
256a605faa cmd/compile: don't use nilcheck information until the next block
e8d5989ed1 cmd/compile: fix compilebench -alloc
ea7d9e6a52 runtime: check for nil g and m in msanread

Change-Id: I61d508d4f0efe4b72e7396645c8ad6088d2bfa6e

cmd/go: don't reject ./... matching top-level file outside GOPATH

This unwinds a small part of CL 31668: we now accept "./." in cleanImport.

Fixes #18778.

Change-Id: Ia7f1fde1cafcea3cc9e0b597a95a0e0bb410a3ed
Reviewed-on: https://go-review.googlesource.com/35646
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

database/sql: fix race when canceling queries immediately

Previously the following could happen, though in practice it would
be rare.

Goroutine 1:
(*Tx).QueryContext begins a query, passing in userContext

Goroutine 2:
(*Tx).awaitDone starts to wait on the context derived from the passed in context

Goroutine 1:
(*Tx).grabConn returns a valid (*driverConn)
The (*driverConn) passes to (*DB).queryConn

Goroutine 3:
userContext is canceled

Goroutine 2:
(*Tx).awaitDone unblocks and calls (*Tx).rollback
(*driverConn).finalClose obtains dc.Mutex
(*driverConn).finalClose sets dc.ci = nil

Goroutine 1:
(*DB).queryConn obtains dc.Mutex in withLock
ctxDriverPrepare accepts dc.ci which is now nil
ctxCriverPrepare panics on the nil ci

The fix for this is to guard the Tx methods with a RWLock
holding it exclusivly when closing the Tx and holding a read lock
when executing a query.

Fixes #18719

Change-Id: I37aa02c37083c9793dabd28f7f934a1c5cbc05ea
Reviewed-on: https://go-review.googlesource.com/35550
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

go/printer: fix format with leading comments in composite literal

This fix is less pervasive than it seems. The only change affecting
formatting is on printer.go:760. The remaining changes have no effect
on formatting since the value of p.level is ignored except on this
specific line.

The remaining changes are:
- renamed adjBlock to funcBody since that's how it is used
- introduced new printer field 'level' tracking the composite
  literal nesting level
- update/restore the composite literal nesting level as needed

Fixes #18782.

Change-Id: Ie833a9b5a559c4ec0f2eef2c5dc97aa263dca53a
Reviewed-on: https://go-review.googlesource.com/35811
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

runtime: reorder modules so main.main comes first

Modules appear in the moduledata linked list in the order they are
loaded by the dynamic loader, with one exception: the
firstmoduledata itself the module that contains the runtime.
This is not always the first module (when using -buildmode=shared,
it is typically libstd.so, the second module).

The order matters for typelinksinit, so we swap the first module
with whatever module contains the main function.

Updates #18729

This fixes the test case extracted with -linkshared, and now

go test -linkshared encoding/...

passes. However the original issue about a plugin failure is not
yet fixed.

Change-Id: I9f399ecc3518e22e6b0a350358e90b0baa44ac96
Reviewed-on: https://go-review.googlesource.com/35644
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

database/sql: let tests wait for db pool to come to expected state

Slower builders were failing TestQueryContext because the cancel
and return to conn pool happens async. TestQueryContext already
uses a wait method for this reason. Use the same method for
other context tests.

Fixes #18759

Change-Id: I84cce697392b867e4ebdfadd38027a06ca14655f
Reviewed-on: https://go-review.googlesource.com/35750
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

doc: update gccgo docs

Update docs on correspondence between Go releases and GCC releases.

Update C type that corresponds to Go type `int`.

Drop out of date comments about Ubuntu and RTEMS.

Change-Id: Ic1b5ce9f242789af23ec3b7e7a64c9d257d6913e
Reviewed-on: https://go-review.googlesource.com/35631
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

doc: clarify what to do with Go 1.4 when installing from source

You have to actually run make.bash (or make.bat).

Update #18771.

Change-Id: Ie6672a4e4abde0150c1ae57cabb1222de2c78716
Reviewed-on: https://go-review.googlesource.com/35632
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

doc: note that plugins are not fully baked

Change-Id: I6341b8cce0b4a9922928f73f8b459cbb9ec25e79
Reviewed-on: https://go-review.googlesource.com/35571
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

net/http: don't send body on redirects for 301, 302, 303 when GetBody is set

The presence of Request.GetBody being set on a request was causing all
redirected requests to have a body, even if the redirect status didn't
warrant one.

This bug came from 307/308 support (https://golang.org/cl/29852) which
removed the line that set req.Body to nil after POST/PUT redirects.

Change-Id: I2a4dd5320f810ae25cfd8ea8ca7c9700e5dbd369
Reviewed-on: https://go-review.googlesource.com/35633
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

net/http: fix a nit

Change-Id: I31fa5f906ad2e8dc475dbbeb91f568f91e16861b
Reviewed-on: https://go-review.googlesource.com/35514
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

cmd/link: mark DWARF function symbols as reachable

Otherwise we don't emit any required ELF relocations when doing an
external link, because elfrelocsect skips unreachable symbols.

Fixes #18745.

Change-Id: Ia3583c41bb6c5ebb7579abd26ed8689370311cd6
Reviewed-on: https://go-review.googlesource.com/35590
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

doc: mention testing.MainStart signature change

Fixes #18766

Change-Id: Ic0f72f3b7bbccd0546692993c4ed414f8c88c1c6
Reviewed-on: https://go-review.googlesource.com/35573
Reviewed-by: Russ Cox <rsc@golang.org>

runtime: amd64, use 4-byte ops for memmove of 4 bytes

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: David Chase <drchase@google.com>

cmd/compile: fix constant propagation through s390x MOVDNE instructions

The constant propagation rules selected the wrong operand to
propagate. So MOVDNE (move if not equal) propagated operands as if
it were a MOVDEQ (move if equal).

Fixes #18735.

Change-Id: I87ac469172f9df7d5aabaf7106e2936ce54ae202
Reviewed-on: https://go-review.googlesource.com/35498
Run-TryBot: Michael Munday <munday@ca.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

misc/cgo/test: pass current environment to syscall.Exec

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: Brad Fitzpatrick <bradfitz@golang.org>

misc/cgo/test: fix test when using GCC 7

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: Brad Fitzpatrick <bradfitz@golang.org>

cmd/compile: don't use nilcheck information until the next block

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/35485
Reviewed-by: Cherry Zhang <cherryyz@google.com>

cmd/compile: fix compilebench -alloc

pprof.WriteHeapProfile is shorthand for
pprof.Lookup("heap").WriteTo(f, 0).
The second parameter is debug.
If it is non-zero, pprof writes legacy-format
pprof output, which compilebench can parse.

Fixes #18641

Change-Id: Ica69adeb9809e9b5933aed943dcf4a07910e43fc
Reviewed-on: https://go-review.googlesource.com/35484
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

runtime: check for nil g and m in msanread

fixes #18707.

Change-Id: Ibc4efef01197799f66d10bfead22faf8ac00473c
Reviewed-on: https://go-review.googlesource.com/35452
Run-TryBot: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

[release-branch.go1.8] go1.8rc2

Change-Id: Ifcf2e13b962aa10280df8ca76cb21b37e3533f8f
Reviewed-on: https://go-review.googlesource.com/35475
Run-TryBot: Chris Broadfoot <cbro@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

[release-branch.go1.8] all: merge master into release-branch.go1.8

6593d8650d go/ast: fix Object's doc comment about Data
c1730ae424 runtime: force workers out before checking mark roots
d10eddcba3 testing: make parallel t.Run safe again
2c8b70eacf crypto/x509: revert SystemCertPool implementation for Windows
fcfd91858b doc/go1.8: document Plan 9 requirements
81a61a96c9 runtime: for plugins, don't add duplicate itabs
f674537cc9 README.md: update and simplify
d8711919db cmd/go: fix bug help message
48d8edb5b2 crypto/tls: disable CBC cipher suites with SHA-256 by default
92ecd78933 cmd/compile: add ZeroWB case in writebarrier
787125abab doc: 2017 is the Year of the Gopher
5b708a6b6a cmd/compile: lvalues are only required for == when calling runtime fns
e83d506714 vendor/golang_org/x/crypto/poly1305: revendor to pick up fix for #18673
76f981c8d8 net/http: skip TestServerHijackGetsBackgroundByte on Plan 9
e395e3246a net/http: skip TestServerHijackGetsBackgroundByte_big on Plan 9
6a3c6c0de8 net/http: add another hijack-after-background-read test
467109bf56 all: test adjustments for the iOS builder
b2a3b54b95 net/http: make sure Hijack's bufio.Reader includes pre-read background byte
593ea3b360 cmd/go, misc: rework cwd handling for iOS tests
0642b8a2f1 syscall: export Fsid.X__val on s390x
4601eae6ba doc/gdb: mention GOTRACEBACK=crash
4c4c5fc7a3 misc/cgo/testplugin: test that types and itabs are unique
22689c4450 reflect: keep makeFuncImpl live across makeFuncStub
9cf06ed6cd cmd/link: only exclude C-only symbols on darwin
9c3630f578 compress/flate: avoid large stack growth in fillDeflate
4f0aac52d9 cmd/go: add comment about SIGUSR2 on iOS
333f764df3 cmd/go, misc: switch from breakpoint to SIGUSR2
39e31d5ec0 doc/go1.8: update timezone database version
08da8201ca misc/cgo/testshared: test that types and itabs are unique
fdde7ba2a2 runtime: avoid clobbering C callee-save register in cgoSigtramp
f65abf6ddc cmd/compile: hide testdclstack behind debug flag
641ef2a733 compress/gzip: skip TestGZIPFilesHaveZeroMTimes on non-builders
0724aa813f crypto/dsa: gofmt
ac05542985 net/http: deflake TestRetryIdempotentRequestsOnError
b842c9aac7 doc: remove inline styles

Change-Id: I642c056732fe1e8081e9d73e086e38ea0b2568cc

go/ast: fix Object's doc comment about Data

The doc comment about the Data field of go/ast.Object reflects its old
behavior, from when the go/types typechecker depended on ast.Objects.

Since when the doc was written, the behavior has changed in
https://golang.org/cl/7058060 and https://golang.org/cl/7096048 .

Fixes #18631

Change-Id: I10fc3e31cfbf7b303eec44150df917f6eb285f90
Reviewed-on: https://go-review.googlesource.com/35075
Reviewed-by: Robert Griesemer <gri@golang.org>

runtime: force workers out before checking mark roots

Currently we check that all roots are marked as soon as gcMarkDone
decides to transition from mark 1 to mark 2. However, issue #16083
indicates that there may be a race where we try to complete mark 1
while a worker is still scanning a stack, causing the root mark check
to fail.

We don't yet understand this race, but as a simple mitigation, move
the root check to after gcMarkDone performs a ragged barrier, which
will force any remaining workers to finish their current job.

Updates #16083. This may "fix" it, but it would be better to
understand and fix the underlying race.

Change-Id: I1af9ce67bd87ade7bc2a067295d79c28cd11abd2
Reviewed-on: https://go-review.googlesource.com/35353
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

testing: make parallel t.Run safe again

Fixes #18603.

Change-Id: I5760c0a9f862200b7e943058a672eb559ac1b9d9
Reviewed-on: https://go-review.googlesource.com/35354
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

crypto/x509: revert SystemCertPool implementation for Windows

Updates #18609

Change-Id: I8306135660f52cf625bed4c7f53f632e527617de
Reviewed-on: https://go-review.googlesource.com/35265
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>

doc/go1.8: document Plan 9 requirements

Fixes #18610.

Change-Id: I19da4d59a1b6293c9a4722aa696e2cb58d982a15
Reviewed-on: https://go-review.googlesource.com/35333
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

runtime: for plugins, don't add duplicate itabs

We already do this for shared libraries. Do it for plugins also.
Suggestions on how to test this would be welcome.

I'd like to get this in for 1.8.  It could lead to mysterious
hangs when using plugins.

Fixes #18676

Change-Id: I03209b096149090b9ba171c834c5e59087ed0f92
Reviewed-on: https://go-review.googlesource.com/35117
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

README.md: update and simplify

Fixes #18675

Change-Id: I82e63e8ee3fe4a998b01d9397c3045912588e2f5
Reviewed-on: https://go-review.googlesource.com/35183
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

cmd/go: fix bug help message

The bug subcommand opens up the browser instead of printing information.
Fixes help message to reflect that.

Fixes #18630.

Change-Id: I660c94bc65ef1994292cfd72d08a544699545701
Reviewed-on: https://go-review.googlesource.com/35150
Reviewed-by: Russ Cox <rsc@golang.org>

crypto/tls: disable CBC cipher suites with SHA-256 by default

As is, they were fully vulnerable to the Lucky13 attack. The SHA1
variants implement limited countermeasures (see f28cf8346c4) but the
SHA256 ones are apparently used rarely enough (see 8741504888b) that
it's not worth the extra code.

Instead, disable them by default and update the warning.

Updates #13385
Updates #15487

Change-Id: I45b8b716001e2fa0811b17e25be76e2512e5abb2
Reviewed-on: https://go-review.googlesource.com/35290
Reviewed-by: Adam Langley <alangley@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cmd/compile: add ZeroWB case in writebarrier

It looks like it should be there, although I couldn't find a test
case that fails without it. ZeroWB is probably never generated now:
zeroing an initialized heap object is done by making an autotmp on
stack, zeroing it, and copying (typedmemmove) to heap.

Passes "toolstash -cmp" on std.

Change-Id: I702a59759e33fb8cc2a34a3b3029e7540aca080a
Reviewed-on: https://go-review.googlesource.com/35250
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

doc: 2017 is the Year of the Gopher

Change-Id: Iac713ae1f322f893c92b3fc47fe9b5719052f9eb
Reviewed-on: https://go-review.googlesource.com/35240
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: David Symonds <dsymonds@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>

cmd/compile: lvalues are only required for == when calling runtime fns

Fixes #18661.

Change-Id: I865802a9b88ab22560c9914a70901d1924242bdc
Reviewed-on: https://go-review.googlesource.com/35236
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

vendor/golang_org/x/crypto/poly1305: revendor to pick up fix for #18673

Fixes #18673.

Change-Id: Ic827c16ad414733392c348da1c9ed9b308879fef
Reviewed-on: https://go-review.googlesource.com/35260
Run-TryBot: Minux Ma <minux@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

net/http: skip TestServerHijackGetsBackgroundByte on Plan 9

CL 5232 added TestServerHijackGetsBackgroundByte, which is failing
on Plan 9, because CloseWrite is not implemented on Plan 9 yet.

Updates #17906.
Updates #18657.

Change-Id: I3c2f73760b0f767f3f9ed2698c855372170e0481
Reviewed-on: https://go-review.googlesource.com/35178
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

net/http: skip TestServerHijackGetsBackgroundByte_big on Plan 9

CL 35234 added TestServerHijackGetsBackgroundByte_big, which is failing
on Plan 9, because CloseWrite is not implemented on Plan 9 yet.

Updates #17906.
Updates #18658.

Change-Id: Icaf3fe3600d586515ecd92aca874104ea81ce6b9
Reviewed-on: https://go-review.googlesource.com/35179
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

net/http: add another hijack-after-background-read test

Follow-up test from Ian's comments in https://golang.org/cl/35232
after submit.

Change-Id: Ifa504bd8d09e555c3c7738376199dfc9b99130cf
Reviewed-on: https://go-review.googlesource.com/35234
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

all: test adjustments for the iOS builder

The working directory is now adjusted to match the typical Go test
working directory in main, as the old trick for adjusting earlier
stopped working with the latest version of LLDB bugs.

That means the small number of places where testdata files are
read before main is called no longer work. This CL adjusts those
reads to happen after main is called. (This has the bonus effect of
not reading some benchmark testdata files in all.bash.)

Fixes compress/bzip2, go/doc, go/parser, os, and time package
tests on the iOS builder.

Change-Id: If60f026aa7848b37511c36ac5e3985469ec25209
Reviewed-on: https://go-review.googlesource.com/35255
Run-TryBot: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

net/http: make sure Hijack's bufio.Reader includes pre-read background byte

Previously, if the Hijack called stopped the background read call
which read a byte, that byte was sitting in memory, buffered, ready to
be Read by Hijack's returned bufio.Reader, but it wasn't yet in the
bufio.Reader's buffer itself, so bufio.Reader.Buffered() reported 1
byte fewer.

This matters for callers who wanted to stitch together any buffered
data (with bufio.Reader.Peek(bufio.Reader.Buffered())) with Hijack's
returned net.Conn. Otherwise there was no way for callers to know a
byte was read.

Change-Id: Id7cb0a0a33fe2f33d79250e13dbaa9c0f7abba13
Reviewed-on: https://go-review.googlesource.com/35232
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

cmd/go, misc: rework cwd handling for iOS tests

Another change in behvaior (bug) in LLDB. Despite the fact that
LLDB can dump the symtab of our test binaries and show the function
addresses, it can no longer call the functions. This means the chdir
trick on signal is failing.

This CL uses a new trick. For iOS, the exec script passes the change
in directory as an argument, and it is processed early by the test
harness generated by cmd/go.

For the iOS builders.

Change-Id: I8f5d0f831fe18de99f097761f89c5184d5bf2afb
Reviewed-on: https://go-review.googlesource.com/35152
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

syscall: export Fsid.X__val on s390x

mkpost.go replaces all variables prefixed with 'X_' with '_' on s390x
because most of them do not need to be exposed. X__val is being used
by a third party library so it turns out we do need to expose it on
s390x (it is already exposed on all other Linux architectures).

Fixes #17298 and updates #18632.

Change-Id: Ic03463229a5f75ca41a4a4b50300da4b4d892d45
Reviewed-on: https://go-review.googlesource.com/30130
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

doc/gdb: mention GOTRACEBACK=crash

Also fix a couple of other errors.

Fixes #6877

Change-Id: I94c81c5847cc7b0adab19418e71687bc2ee7fe94
Reviewed-on: https://go-review.googlesource.com/34960
Reviewed-by: Ian Lance Taylor <iant@golang.org>

misc/cgo/testplugin: test that types and itabs are unique

Make sure that the same type and itab generated in two
different plugins are actually the same thing.

See also CL 35115

Change-Id: I0c1ecb039d7e2bf5a601d58dfa162a435ae4ef76
Reviewed-on: https://go-review.googlesource.com/35116
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Crawshaw <crawshaw@golang.org>

reflect: keep makeFuncImpl live across makeFuncStub

When traceback sees reflect.makeFuncStub (or reflect.methodValueCall)
on the stack, it expects to be able to get the *reflect.makeFuncImpl
(or *reflect.methodValue) for that call from the first outgoing
argument slot of makeFuncStub/methodValueCall.

However, currently this object isn't necessarily kept live across
makeFuncStub. This means it may get garbage collected while in a
reflect call and reused for something else. If we then try to
traceback, the runtime will see a corrupted makeFuncImpl object and
panic. This was not a problem in previous releases because we always
kept arguments live across the whole function. This became a problem
when we stopped doing this.

Fix this by using reflect.KeepAlive to keep the
makeFuncImpl/methodValue live across all of callReflect/callMethod,
which in turn keeps it live as long as makeFuncStub/methodValueCall
are on the stack.

Fixes #18635.

Change-Id: I91853efcf17912390fddedfb0230648391c33936
Reviewed-on: https://go-review.googlesource.com/35151
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cmd/link: only exclude C-only symbols on darwin

C-only symbols are excluded from pclntab because of a quirk of darwin,
where functions are referred to by an exported symbol so dynamic
relocations de-duplicate to the host binary module and break unwinding.

This doesn't happen on ELF systems because the linker always refers to
unexported module-local symbols, so we don't need this condition.
And the current logic for excluding some functions breaks the module
verification code in moduledataverify1. So disable this for plugins
on linux.

(In 1.9, it will probably be necessary to introduce a module-local
symbol reference system on darwin to fix a different bug, so all of
this onlycsymbol code made be short-lived.)

With this CL, the tests in CL 35116 pass.

Change-Id: I517d7ca4427241fa0a91276c462827efb9383be9
Reviewed-on: https://go-review.googlesource.com/35190
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

compress/flate: avoid large stack growth in fillDeflate

Ranging over an array causes the array to be copied over to the
stack, which cause large re-growths. Instead, we should iterate
over slices of the array.

Also, assigning a large struct literal uses the stack even
though the actual fields being populated are small in comparison
to the entirety of the struct (see #18636).

Fixing the stack growth does not alter CPU-time performance much
since the stack-growth and copying was such a tiny portion of the
compression work:

name                         old time/op    new time/op    delta
Encode/Digits/Default/1e4-8     332µs ± 1%     332µs ± 1%   ~     (p=0.796 n=10+10)
Encode/Digits/Default/1e5-8    5.07ms ± 2%    5.05ms ± 1%   ~       (p=0.815 n=9+8)
Encode/Digits/Default/1e6-8    53.7ms ± 1%    53.9ms ± 1%   ~     (p=0.075 n=10+10)
Encode/Twain/Default/1e4-8      380µs ± 1%     380µs ± 1%   ~     (p=0.684 n=10+10)
Encode/Twain/Default/1e5-8     5.79ms ± 2%    5.79ms ± 1%   ~      (p=0.497 n=9+10)
Encode/Twain/Default/1e6-8     61.5ms ± 1%    61.8ms ± 1%   ~     (p=0.247 n=10+10)

name                         old speed      new speed      delta
Encode/Digits/Default/1e4-8  30.1MB/s ± 1%  30.1MB/s ± 1%   ~     (p=0.753 n=10+10)
Encode/Digits/Default/1e5-8  19.7MB/s ± 2%  19.8MB/s ± 1%   ~       (p=0.795 n=9+8)
Encode/Digits/Default/1e6-8  18.6MB/s ± 1%  18.5MB/s ± 1%   ~     (p=0.072 n=10+10)
Encode/Twain/Default/1e4-8   26.3MB/s ± 1%  26.3MB/s ± 1%   ~     (p=0.616 n=10+10)
Encode/Twain/Default/1e5-8   17.3MB/s ± 2%  17.3MB/s ± 1%   ~      (p=0.484 n=9+10)
Encode/Twain/Default/1e6-8   16.3MB/s ± 1%  16.2MB/s ± 1%   ~     (p=0.238 n=10+10)

Updates #18636
Fixes #18625

Change-Id: I471b20339bf675f63dc56d38b3acdd824fe23328
Reviewed-on: https://go-review.googlesource.com/35122
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cmd/go: add comment about SIGUSR2 on iOS

Missing from CL 34926.

Change-Id: I4a046440c30811f26da53bee0e853dae3b0ac57a
Reviewed-on: https://go-review.googlesource.com/35123
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

cmd/go, misc: switch from breakpoint to SIGUSR2

The iOS test harness has set a breakpoint early in the life of Go
programs so that it can change the current working directory using
information only available from the host debugger. Somewhere in the
upgrade to iOS 10 / XCode 8.2, breakpoints stopped working. This
may be an LLDB bug, or a bug in the ios-deploy LLDB scripts, it's
not clear.

Work around the problem by giving up on breakpoints. Instead, early
in the life of every test binary built for iOS, send (and ignore) a
SIGUSR2 signal. The debugger will catch this, giving the script
go_darwin_arm_exec a chance to change the working directory.

For the iOS builders.

Change-Id: I7476531985217d0c76bc176904c48379210576c2
Reviewed-on: https://go-review.googlesource.com/34926
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

doc/go1.8: update timezone database version

Fixes #18623.

Change-Id: Ic965f5f7088c3270adbca7162226be486d1b9b4e
Reviewed-on: https://go-review.googlesource.com/35130
Reviewed-by: Ian Lance Taylor <iant@golang.org>

misc/cgo/testshared: test that types and itabs are unique

Make sure that the same type and itab generated in two
different shared library are actually the same thing.

Change-Id: Ica45862d65ff8bc7ad04d59a41f57223f71224cd
Reviewed-on: https://go-review.googlesource.com/35115
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

runtime: avoid clobbering C callee-save register in cgoSigtramp

Use R11 (a caller-saved temp register) instead of RBX (a callee-saved
register).

I believe this only affects linux/amd64, since it is the only platform
with a non-trivial cgoSigtramp implementation.

Updates #18328.

Change-Id: I3d35c4512624184d5a8ece653fa09ddf50e079a2
Reviewed-on: https://go-review.googlesource.com/35068
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cmd/compile: hide testdclstack behind debug flag

This reduces compilation time for the program
in #18602 from 7 hours to 30 min.

Updates #14781
Updates #18602

Change-Id: I3c4af878a08920e6373d3b3b0c4453ee002e32eb
Reviewed-on: https://go-review.googlesource.com/35113
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

compress/gzip: skip TestGZIPFilesHaveZeroMTimes on non-builders

Fixes #18604

Change-Id: I89221d5e632042167dfced068e1dc14e932cd618
Reviewed-on: https://go-review.googlesource.com/35111
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

crypto/dsa: gofmt

Somehow this file didn't get gofmted after the last change, which
interferes with merges.

Change-Id: I965cfdbf27a01124a6ed300be9687ff84f68f9a1
Reviewed-on: https://go-review.googlesource.com/35064
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Adam Langley <agl@chromium.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

net/http: deflake TestRetryIdempotentRequestsOnError

The test was previously an integration test, relying on luck and many
goroutines and lots of time to hit the path to be tested.

Instead, rewrite the test to exactly hit the path to be tested, in one
try, in one goroutine.

Fixes #18205

Change-Id: I63cd513316344bfd7375dcc452c1c396dec0e49f
Reviewed-on: https://go-review.googlesource.com/35107
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

doc: remove inline styles

Change-Id: I7ca7e9a2d4cf97cf33c60a9a4d0ba5fb0ca6e44c
Reviewed-on: https://go-review.googlesource.com/35098
Reviewed-by: Chris Broadfoot <cbro@golang.org>

[release-branch.go1.8] go1.8rc1

Change-Id: I68a99a4d750357dd59eb48f7c05b4dc08c64c92d
Reviewed-on: https://go-review.googlesource.com/35097
Run-TryBot: Chris Broadfoot <cbro@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

cmd/compile: disable flaky test

The test is inherently racy and vulnerable to starvation,
and within all.bash on some platforms that means it flakes.
Test is kept because it can be useful standalone to verify
behavior of GOEXPERIMENT=preeemptibleloops, and there is
likely to be further development of this feature in the
future.

There's also some question as to why it is flaking, because
though technically this is permitted, it's very odd in this
simple case.

Fixes #18589.

Change-Id: Ia0dd9037285c4a03122da4012c96981c9cc43b60
Reviewed-on: https://go-review.googlesource.com/35051
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

runtime: debug prints for spanBytesAlloc underflow

Updates #18043.

Change-Id: I24e687fdd5521c48b672987f15f0d5de9f308884
Reviewed-on: https://go-review.googlesource.com/34612
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cmd/compile: insert scheduling checks on loop backedges

Loop breaking with a counter.  Benchmarked (see comments),
eyeball checked for sanity on popular loops.  This code
ought to handle loops in general, and properly inserts phi
functions in cases where the earlier version might not have.

Includes test, plus modifications to test/run.go to deal with
timeout and killing looping test.  Tests broken by the addition
of extra code (branch frequency and live vars) for added
checks turn the check insertion off.

If GOEXPERIMENT=preemptibleloops, the compiler inserts reschedule
checks on every backedge of every reducible loop.  Alternately,
specifying GO_GCFLAGS=-d=ssa/insert_resched_checks/on will
enable it for a single compilation, but because the core Go
libraries contain some loops that may run long, this is less
likely to have the desired effect.

This is intended as a tool to help in the study and diagnosis
of GC and other latency problems, now that goal STW GC latency
is on the order of 100 microseconds or less.

Updates #17831.
Updates #10958.

Change-Id: I6206c163a5b0248e3f21eb4fc65f73a179e1f639
Reviewed-on: https://go-review.googlesource.com/33910
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

cmd/compile: file line number for //go:xxx directives

Minimally invasive; fixes a regression from 1.7.

Fixes #18459.

Change-Id: I93b3b5c05706eaff8ae97a237f770838c1f8778c
Reviewed-on: https://go-review.googlesource.com/34721
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

net/http: preserve original HTTP method when possible

In Go1.7, a 301, 302, or 303 redirect on a HEAD method, would still
cause the following redirects to still use a HEAD.
In CL/29852 this behavior was changed such that those codes always
caused a redirect with the GET method. Fix this such that both
GET and HEAD will preserve the method.

Fixes #18570

Change-Id: I4bfe69872a30799419e3fad9178f907fe439b449
Reviewed-on: https://go-review.googlesource.com/34981
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

runtime: add table of size classes in a comment

Change-Id: I52fae67c9aeceaa23e70f2ef0468745b354f8c75
Reviewed-on: https://go-review.googlesource.com/34932
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

go/types: fix typo

Fixes #18562

Change-Id: Ic195a8606f09876e2667e4ef720b84a07d316f4a
Reviewed-on: https://go-review.googlesource.com/34939
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

os/user: document the difference between Username and Name

Fixes #18261.

Change-Id: I4bd7363aac4e62461f61fd95b3c7a18063412182
Reviewed-on: https://go-review.googlesource.com/34241
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

all: fix misspellings

Change-Id: I429637ca91f7db4144f17621de851a548dc1ce76
Reviewed-on: https://go-review.googlesource.com/34923
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

net/http: don't do a background read if we've already done one

Fixes #18535

Change-Id: I9e49d33ce357a534529a6b0fcdbc09ff4fa98622
Reviewed-on: https://go-review.googlesource.com/34920
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

cmd/go: add link to env varible guide to set custom GOPATH

Also moves the GOPATH env variable guide to
golang.org/wiki/SettingGOPATH.

Fixes #18294.

Change-Id: I88a2ce550df7466f8d2388d86bc8476dcf3c2ad6
Reviewed-on: https://go-review.googlesource.com/34918
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

vendor: update golang.org/x/crypto/chacha20poly1305

Updates golang.org/x/crypto/chacha20poly1305 to rev cb497ae for:
- chacha20poly1305: fix detection of BMI on amd64 (https://golang.org/cl/34852)
- chacha20poly1305: fix typos (https://golang.org/cl/34536)
- chacha20poly1305: fix typos (https://golang.org/cl/33855)
- chacha20poly1305: fix build constraints (https://golang.org/cl/32391)

Change-Id: I3a608b5e21b3a72b5aaa5d0afe6c6cffbb1d6fc1
Reviewed-on: https://go-review.googlesource.com/34871
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

doc: update CONTRIBUTING.md a bit, mention proposal process

Fixes #18550

Change-Id: Ia08d0ef6964216fcc14fa63c2ba378d68daa2c02
Reviewed-on: https://go-review.googlesource.com/34917
Reviewed-by: Chris Broadfoot <cbro@golang.org>

net: disable RFC 6724 Rule 9 for IPv4 addresses

Rule 9 arguably doesn't make sense for IPv4 addresses, and so far it
has only caused problems (#13283, #18518). Disable it until we hear
from users that actually want/need it.

Fixes #18518.

Change-Id: I7b0dd75d03819cab8e0cd4c29f0c1dc8d2e9c179
Reviewed-on: https://go-review.googlesource.com/34914
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cmd/compile: rewrite literal.method to ensure full initialization

CALLPART of STRUCTLIT did not check for incomplete initialization
of struct; modify PTRLIT treatment to force zeroing.

Test for structlit, believe this might have also failed for
arraylit.

Fixes #18410.

Change-Id: I511abf8ef850e300996d40568944665714efe1fc
Reviewed-on: https://go-review.googlesource.com/34622
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

doc: explain how to set GOPATH to a custom value

Updates #18294.

Change-Id: Ib6b84243a15ed921cc8960e5fa355fd7594181e6
Reviewed-on: https://go-review.googlesource.com/34821
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

runtime: fix corruption crash/race between select and stack growth

To implement the blocking of a select, a goroutine builds a list of
offers to communicate (pseudo-g's, aka sudog), one for each case,
queues them on the corresponding channels, and waits for another
goroutine to complete one of those cases and wake it up. Obviously it
is not OK for two other goroutines to complete multiple cases and both
wake the goroutine blocked in select. To make sure that only one
branch of the select is chosen, all the sudogs contain a pointer to a
shared (single) 'done uint32', which is atomically cas'ed by any
interested goroutines. The goroutine that wins the cas race gets to
wake up the select. A complication is that 'done uint32' is stored on
the stack of the goroutine running the select, and that stack can move
during the select due to stack growth or stack shrinking.

The relevant ordering to block and unblock in select is:

1. Lock all channels.
2. Create list of sudogs and queue sudogs on all channels.
3. Switch to system stack, mark goroutine as asleep,
   unlock all channels.
4. Sleep until woken.
5. Wake up on goroutine stack.
6. Lock all channels.
7. Dequeue sudogs from all channels.
8. Free list of sudogs.
9. Unlock all channels.

There are two kinds of stack moves: stack growth and stack shrinking.
Stack growth happens while the original goroutine is running.
Stack shrinking happens asynchronously, during garbage collection.

While a channel listing a sudog is locked by select in this process,
no other goroutine can attempt to complete communication on that
channel, because that other goroutine doesn't hold the lock and can't
find the sudog. If the stack moves while all the channel locks are
held or when the sudogs are not yet or no longer queued in the
channels, no problem, because no goroutine can get to the sudogs and
therefore to selectdone. We only need to worry about the stack (and
'done uint32') moving with the sudogs queued in unlocked channels.

Stack shrinking can happen any time the goroutine is stopped.
That code already acquires all the channel locks before doing the
stack move, so it avoids this problem.

Stack growth can happen essentially any time the original goroutine is
running on its own stack (not the system stack). In the first half of
the select, all the channels are locked before any sudogs are queued,
and the channels are not unlocked until the goroutine has stopped
executing on its own stack and is asleep, so that part is OK. In the
second half of the select, the goroutine wakes up on its own goroutine
stack and immediately locks all channels. But the actual call to lock
might grow the stack, before acquiring any locks. In that case, the
stack is moving with the sudogs queued in unlocked channels. Not good.
One goroutine has already won a cas on the old stack (that goroutine
woke up the selecting goroutine, moving it out of step 4), and the
fact that done = 1 now should prevent any other goroutines from
completing any other select cases. During the stack move, however,
sudog.selectdone is moved from pointing to the old done variable on
the old stack to a new memory location on the new stack. Another
goroutine might observe the moved pointer before the new memory
location has been initialized. If the new memory word happens to be
zero, that goroutine might win a cas on the new location, thinking it
can now complete the select (again). It will then complete a second
communication (reading from or writing to the goroutine stack
incorrectly) and then attempt to wake up the selecting goroutine,
which is already awake.

The scribbling over the goroutine stack unexpectedly is already bad,
but likely to go unnoticed, at least immediately. As for the second
wakeup, there are a variety of ways it might play out.

* The goroutine might not be asleep.
That will produce a runtime crash (throw) like in #17007:

runtime: gp: gp=0xc0422dcb60, goid=2299, gp->atomicstatus=8
runtime:  g:  g=0xa5cfe0, goid=0,  g->atomicstatus=0
fatal error: bad g->status in ready

Here, atomicstatus=8 is copystack; the second, incorrect wakeup is
observing that the selecting goroutine is in state "Gcopystack"
instead of "Gwaiting".

* The goroutine might be sleeping in a send on a nil chan.
If it wakes up, it will crash with 'fatal error: unreachable'.

* The goroutine might be sleeping in a send on a non-nil chan.
If it wakes up, it will crash with 'fatal error: chansend:
spurious wakeup'.

* The goroutine might be sleeping in a receive on a nil chan.
If it wakes up, it will crash with 'fatal error: unreachable'.

* The goroutine might be sleeping in a receive on a non-nil chan.
If it wakes up, it will silently (incorrectly!) continue as if it
received a zero value from a closed channel, leaving a sudog queued on
the channel pointing at that zero vaue on the goroutine's stack; that
space will be reused as the goroutine executes, and when some other
goroutine finally completes the receive, it will do a stray write into
the goroutine's stack memory, which may cause problems. Then it will
attempt the real wakeup of the goroutine, leading recursively to any
of the cases in this list.

* The goroutine might have been running a select in a finalizer
(I hope not!) and might now be sleeping waiting for more things to
finalize. If it wakes up, as long as it goes back to sleep quickly
(before the real GC code tries to wake it), the spurious wakeup does
no harm (but the stack was still scribbled on).

* The goroutine might be sleeping in gcParkAssist.
If it wakes up, that will let the goroutine continue executing a bit
earlier than we would have liked. Eventually the GC will attempt the
real wakeup of the goroutine, leading recursively to any of the cases
in this list.

* The goroutine cannot be sleeping in bgsweep, because the background
sweepers never use select.

* The goroutine might be sleeping in netpollblock.
If it wakes up, it will crash with 'fatal error: netpollblock:
corrupted state'.

* The goroutine might be sleeping in main as another thread crashes.
If it wakes up, it will exit(0) instead of letting the other thread
crash with a non-zero exit status.

* The goroutine cannot be sleeping in forcegchelper,
because forcegchelper never uses select.

* The goroutine might be sleeping in an empty select - select {}.
If it wakes up, it will return to the next line in the program!

* The goroutine might be sleeping in a non-empty select (again).
In this case, it will wake up spuriously, with gp.param == nil (no
reason for wakeup), but that was fortuitously overloaded for handling
wakeup due to a closing channel and the way it is handled is to rerun
the select, which (accidentally) handles the spurious wakeup
correctly:

if cas == nil {
// This can happen if we were woken up by a close().
// TODO: figure that out explicitly so we don't need this loop.
goto loop
}

Before looping, it will dequeue all the sudogs on all the channels
involved, so that no other goroutine will attempt to wake it.
Since the goroutine was blocked in select before, being blocked in
select again when the spurious wakeup arrives may be quite likely.
In this case, the spurious wakeup does no harm (but the stack was
still scribbled on).

* The goroutine might be sleeping in semacquire (mutex slow path).
If it wakes up, that is taken as a signal to try for the semaphore
again, not a signal that the semaphore is now held, but the next
iteration around the loop will queue the sudog a second time, causing
a cycle in the wakeup list for the given address. If that sudog is the
only one in the list, when it is eventually dequeued, it will
(due to the precise way the code is written) leave the sudog on the
queue inactive with the sudog broken. But the sudog will also be in
the free list, and that will eventually cause confusion.

* The goroutine might be sleeping in notifyListWait, for sync.Cond.
If it wakes up, (*Cond).Wait returns. The docs say "Unlike in other
systems, Wait cannot return unless awoken by Broadcast or Signal,"
so the spurious wakeup is incorrect behavior, but most callers do not
depend on that fact. Eventually the condition will happen, attempting
the real wakeup of the goroutine and leading recursively to any of the
cases in this list.

* The goroutine might be sleeping in timeSleep aka time.Sleep.
If it wakes up, it will continue running, leaving a timer ticking.
When that time bomb goes off, it will try to ready the goroutine
again, leading to any one of the cases in this list.

* The goroutine cannot be sleeping in timerproc,
because timerproc never uses select.

* The goroutine might be sleeping in ReadTrace.
If it wakes up, it will print 'runtime: spurious wakeup of trace
reader' and return nil. All future calls to ReadTrace will print
'runtime: ReadTrace called from multiple goroutines simultaneously'.
Eventually, when trace data is available, a true wakeup will be
attempted, leading to any one of the cases in this list.

None of these fatal errors appear in any of the trybot or dashboard
logs. The 'bad g->status in ready' that happens if the goroutine is
running (the most likely scenario anyway) has happened once on the
dashboard and eight times in trybot logs. Of the eight, five were
atomicstatus=8 during net/http tests, so almost certainly this bug.
The other three were atomicstatus=2, all near code in select,
but in a draft CL by Dmitry that was rewriting select and may or may
not have had its own bugs.

This bug has existed since Go 1.4. Until then the select code was
implemented in C, 'done uint32' was a C stack variable 'uint32 done',
and C stacks never moved. I believe it has become more common recently
because of Brad's work to run more and more tests in net/http in
parallel, which lengthens race windows.

The fix is to run step 6 on the system stack,
avoiding possibility of stack growth.

Fixes #17007 and possibly other mysterious failures.

Change-Id: I9d6575a51ac96ae9d67ec24da670426a4a45a317
Reviewed-on: https://go-review.googlesource.com/34835
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

runtime: expand HACKING.md

This adds high-level descriptions of the scheduler structures, the
user and system stacks, error handling, and synchronization.

Change-Id: I1eed97c6dd4a6e3d351279e967b11c6e64898356
Reviewed-on: https://go-review.googlesource.com/34290
Reviewed-by: Rick Hudson <rlh@golang.org>

runtime: update big mgc.go comment

The comment describing the overall GC algorithm at the top of mgc.go
has gotten woefully out-of-date (and was possibly never
correct/complete). Update it to reflect the current workings of the
GC and the set of phases that we now divide it into.

Change-Id: I02143c0ebefe9d4cd7753349dab8045f0973bf95
Reviewed-on: https://go-review.googlesource.com/34711
Reviewed-by: Rick Hudson <rlh@golang.org>

net/http: better failure in TestTransportPersistConnLeak

If one of the c.Get(ts.URL) results in an error, the child goroutine
calls t.Errorf, but the test goroutine gets stuck waiting for <-gotReqCh,
so the test hangs and the program is eventually killed (after 10 minutes!).
Whatever might have been printed to t.Errorf is never seen.
Adjust test so that the test fails cleanly in this case.

Still trying to debug why c.Get might fail.
It seems to have something to do with occasional connection
failures on macOS Sierra.

Change-Id: Ia797787bd51ea7cd6deb1192aec89c331c4f2c48
Reviewed-on: https://go-review.googlesource.com/34836
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

runtime: use 4K as the boundary of legal pointers

Currently, the check for legal pointers in stack copying uses
_PageSize (8K) as the minimum legal pointer. By default, Linux won't
let you map under 64K, but

1) it's less clear what other OSes allow or will allow in the future;

2) while mapping the first page is a terrible idea, mapping anywhere
above that is arguably more justifiable;

3) the compiler only assumes the first physical page (4K) is never
mapped.

Make the runtime consistent with the compiler and more robust by
changing the bad pointer check to use 4K as the minimum legal pointer.

This came out of discussions on CLs 34663 and 34719.

Change-Id: Idf721a788bd9699fb348f47bdd083cf8fa8bd3e5
Reviewed-on: https://go-review.googlesource.com/34890
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

net: Fix grammar error

Change-Id: I1c2e17b25ca91be37a18c47e70678c3753070fb8
Reviewed-on: https://go-review.googlesource.com/34827
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>

net: display the complete BUGS section on every platform

We cannot assume that the platform running documentation service is
the target platform.

Change-Id: I241ed6f8778169faac9ef49e11dcd40f7422cccc
Reviewed-on: https://go-review.googlesource.com/34750
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

cmd/compile: avoid n.Right nil dereference on non-existent interface methods

Fixes #18392.

Avoid nil dereferencing n.Right when dealing with non-existent
self referenced interface methods e.g.
type A interface{
  Fn(A.Fn)
}

Instead, infer the symbol name from n.Sym itself.

Change-Id: I60d5f8988e7318693e5c8da031285d8d7347b771
Reviewed-on: https://go-review.googlesource.com/34817
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

doc: add go get -insecure change to go1.8.html

Change-Id: I184c86edaaaa71c26bc7360c8b995015f30fe137
Reviewed-on: https://go-review.googlesource.com/34819
Reviewed-by: Russ Cox <rsc@golang.org>

cmd/go: use ProxyFromEnvironment in -insecure mode also

Be consistent on whether the http proxy environment variables are
respected regardless of whether -insecure is used.

Updates #18519

Change-Id: Ib157eaacfd342dd3bfcd03e64da18c98c609cae3
Reviewed-on: https://go-review.googlesource.com/34818
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

x/crypto/chacha20poly1305: fix detection of BMI on AMD64

This change uses runtime.support_bmi2 as an additional condition
to examine the usability of AVX2 version algorithm, fixes
the crash on the platfrom which supports AVX2 but not support BMI2.

Fixes #18512

Change-Id: I408c0844ae2eb242dacf70cb9e8cec1b8f3bd941
Reviewed-on: https://go-review.googlesource.com/34851
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

crypto: detect BMI usability on AMD64 for sha1 and sha256

The existing implementations on AMD64 only detects AVX2 usability,
when they also contains BMI (bit-manipulation instructions).
These instructions crash the running program as 'unknown instructions'
on the architecture, e.g. i3-4000M, which supports AVX2 but not
support BMI.

This change added the detections for BMI1 and BMI2 to AMD64 runtime with
two flags as the result, `support_bmi1` and `support_bmi2`,
in runtime/runtime2.go. It also completed the condition to run AVX2 version
in packages crypto/sha1 and crypto/sha256.

Fixes #18512

Change-Id: I917bf0de365237740999de3e049d2e8f2a4385ad
Reviewed-on: https://go-review.googlesource.com/34850
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

.gitignore: fix attempt at rooted paths

When I wrote the lines

bin/
pkg/

I was trying to match just the top-level bin and pkg directories, and I put the
final slash in because 'git help gitignore' says:

       o   If the pattern does not contain a slash /, Git treats it as a shell
           glob pattern and checks for a match against the pathname relative
           to the location of the .gitignore file (relative to the toplevel of
           the work tree if not from a .gitignore file).

       o   Otherwise, Git treats the pattern as a shell glob suitable for
           consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in
           the pattern will not match a / in the pathname. For example,
           "Documentation/*.html" matches "Documentation/git.html" but not
           "Documentation/ppc/ppc.html" or
           "tools/perf/Documentation/perf.html".

Putting a trailing slash was my way of opting in to the "rooted path" semantics
without looking different from the surrounding rooted paths like "src/go/build/zcgo.go".

But HA HA GIT FOOLED YOU! above those two bullets the docs say:

       o   If the pattern ends with a slash, it is removed for the purpose of
           the following description, ...

Change all the patterns to use a leading slash for "rooted" behavior.

This bit me earlier today because I had a perfectly reasonable source
code directory go/src/cmd/go/testdata/src/empty/pkg that was
not added by 'git add empty'.

Change-Id: I6f8685b3c5be22029c33de9ccd735487089a1c03
Reviewed-on: https://go-review.googlesource.com/34832
Reviewed-by: Ian Lance Taylor <iant@golang.org>

lib/time: update tzdata to 2016j

Fixes #18500

Change-Id: I4dddd1b99aecf86b9431b0c14f452152dff9b95a
Reviewed-on: https://go-review.googlesource.com/34816
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

cmd/go: retain test binary when go test is run with -mutexprofile

Fixes #18494

Change-Id: I8a190acae6d5f1d20d4e4e4547d84e10e8a7fe68
Reviewed-on: https://go-review.googlesource.com/34793
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>

net/http/httputil: make DumpRequest and DumpRequestOut recognize http.NoBody

Fixes #18506

Change-Id: I6b0b107296311178938609e878e1ef47a30a463f
Reviewed-on: https://go-review.googlesource.com/34814
Reviewed-by: Ian Lance Taylor <iant@golang.org>

net/http: make Server cancel its ReadTimeout between requests

Fixes #18447

Change-Id: I5d60c3632a5ce625d3bac9d85533ce689e301707
Reviewed-on: https://go-review.googlesource.com/34813
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

testing: add missing newlines to error messages

No test because in practice these errors never occur.

Change-Id: I11c77893ae931fc621c98920cba656790d18ed93
Reviewed-on: https://go-review.googlesource.com/34811
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

cmd/go: add sync/atomic dependency when needed by test coverage

Fixes #18486.

Change-Id: I359dc4169e04b4123bd41679ea939b06fa754ac2
Reviewed-on: https://go-review.googlesource.com/34830
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

doc: in Go 1.8 notes, mention lack of RWMutex in contention profile

For #18496.

Change-Id: I50ced7c9f0fe5d9c627eef1f59a7f73be742e04c
Reviewed-on: https://go-review.googlesource.com/34831
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

cmd/link: use 64k segment alignment on linux/arm

Otherwise 64k pages don't map correctly.

Fixes #18408.

Change-Id: I85f56682531566d1ff5c655640cd58509514aee8
Reviewed-on: https://go-review.googlesource.com/34629
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

runtime: check sched_getaffinity return value

Android on ChromeOS uses a restrictive seccomp filter that blocks
sched_getaffinity, leading this code to index a slice by -errno.

Change-Id: Iec09a4f79dfbc17884e24f39bcfdad305de75b37
Reviewed-on: https://go-review.googlesource.com/34794
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>

cmd/vet: include function name or value in copylock message

Given
var t struct{ lock sync.Mutex }
var fntab []func(t)
f(a(), b(&t), c(), fntab[0](t))

Before:
function call copies lock value: struct{lock sync.Mutex} contains sync.Mutex

After:
call of fntab[0] copies lock value: struct{lock sync.Mutex} contains sync.Mutex

This will make diagnosis easier when there are multiple function calls per line.

Change-Id: I9881713c5671b847b84a0df0115f57e7cba17d72
Reviewed-on: https://go-review.googlesource.com/34730
Reviewed-by: Ian Lance Taylor <iant@golang.org>

cmd/dist: enable extLink tests for s390x

Change-Id: Ia97d770cd942a49a34c733643ced7490fc31c736
Reviewed-on: https://go-review.googlesource.com/34795
Run-TryBot: Michael Munday <munday@ca.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

cmd/dist: enable extLink tests for mips{,le}

Change-Id: I9e37aece5ace374e89bee70962a19f76ae3266bc
Reviewed-on: https://go-review.googlesource.com/34646
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>