Go 1.9 beta 2 is already out.
It's too late to break code with a change like this.
This can be rolled forward for Go 1.10.

This reverts commit ae238688.

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

The name LabelList was changed to LabelSet during the development of the
proposal [1], except in one function comment. This commit fixes that.

Fixes #20905.

[1] https://github.com/golang/go/issues/17280

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

Change-Id: Idf89559c9945c5a8743539658fe92e860fcc6a92
Reviewed-on: https://go-review.googlesource.com/47362Reviewed-by: Matt Layher <mdlayher@gmail.com>

mheap.allocLarge just calls bestFitTreap and is the only caller of
bestFitTreap. Flatten these into a single function. Also fix their
comments: allocLarge claims to return exactly npages but can in fact
return a larger span, and h.freelarge is not in fact indexed by span
start address.

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

The Server struct has exported fields, which allows users to manually
create a Server object without using using NewServer or NewTLSServer
and directly call Start or StartTLS on their object.

In order to ensure that manual creation of Server works, the
NewUnstartedServer function should not initialize Server in any way
that the user was not able to do themselves. For example, the setting
of a unexported filed, client, is not something a user can do.
Thus, rather than setting the client field in NewUnstartedServer,
we lazily initialize it when Start or StartTLS is called.

Otherwise, the Server logic can nil panic later when it assumes that this
field has been initialized.

Fixes #20871

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

The Func type has allowed calling the Func.Name method on a nil pointer
since Go1.2, where it returned an empty string. A regression caused by
CL/37331 caused this behavior to change. This breaks code that lazily
does runtime.FuncForPC(myPtr).Name() without first checking that myPtr
is actually non-nil.

Fixes #20872

Change-Id: Iae9a2ebabca5e9d1f5a2cdaf2f30e9c6198fec4f
Reviewed-on: https://go-review.googlesource.com/47354Reviewed-by: Marvin Stenger <marvin.stenger94@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

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

Wrong instructions "MOVW 8(F0), R1" and "MOVW R0<<0(F1), R1"
are silently accepted, and all Fx are treated as Rx.

The patch checks all those illegal base registers.

fixes #20724

Change-Id: I05d41bb43fe774b023205163b7daf4a846e9dc88
Reviewed-on: https://go-review.googlesource.com/46132
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

If a retryable error such as EAGAIN/EINTR is encountered during a call
to sendfile(), we should not assume that a partial write occurred.
Instead, just like any other platform, we should always try again even
if 0 bytes were written.

Fixes #20857

Change-Id: I9aa48d193c27c6794c550320da4d3f7544041f37
Reviewed-on: https://go-review.googlesource.com/47351
Run-TryBot: Shawn Walker-Salas <shawn.walker@oracle.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

The current code calculates register number incorrectly.

The fix corrects the register number calculation.

Add cases created by decoder to test assembler.

Fixes #20697
Fixes #20723

Change-Id: I73ac153df9ea9f51c43a5104828d7a5389551c92
Reviewed-on: https://go-review.googlesource.com/45850
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

Now that ReadMemStats is fast (CL 34937), CL 36791 is not so
necessary, and causes confusion. See #20863

This was already partially reverted in CL 46612 but missed two of the
spots.

Fixes #20863

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

Fixes #20834.

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

Updates #18581
Updates #20858

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

Fixes #20839.

Change-Id: I125460c5da09b7fa0cf470ff5be436f8d650cde7
Reviewed-on: https://go-review.googlesource.com/47253
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Document that the byte value returned by ReadByte() is meaningless
if its error != nil. Because io.Reader and io.ByteReader are similar in
name, this CL aims to clear up any ambiguity surrounding the returned
values, particularly where io.Reader is allowed to return both a
non-zero number of valid bytes and err == EOF.

Fixes #20825

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

FreeBSD 9.3.
Add Linux arm64. (required second line)
Clarify glibc requirement now that we have second line in notes.
OS X to macOS

Updates #20850

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

This reverts commit df68afd0 (https://golang.org/cl/33276)

Reason for revert: made other benchmarks worse

Fixes #20693 (details)
Updates #17914
Updates #10335

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

Apparently, "all such calls must happen" means that the t.Run call
must *return* before the outer test function returns, or the calls
will cause a data race on t.ran.

Clarify the docs.

Fixes #20339

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

TestInterfaceHardwareAddrWithGetmac was panicing when getmac returned
multiple network cards.

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

Updates #17686
Fixes #20848

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

Apply code review suggestion from CL 46715.

The block is doing more than just checking len(r.certs) == len(tc.cns).
It also verifies that certificate common names match.

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

Updates #20587

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

Fixes #19635

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

Fixes #19794

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

Updates http2 to x/net/http2 git rev d4223d6710a for:

    http2: refund connection flow control on DATA frames received after reset
    https://golang.org/cl/46591

Fixes #46591

Change-Id: I5e6999599e921fed279c6d29ae77439191e99615
Reviewed-on: https://go-review.googlesource.com/47096
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tom Bergan <tombergan@google.com>

And some double space after period cleanup while I'm here.
I guess my previous regexps missed these. My next cleaner should
probably use go/ast instead of perl.

Updates #20221

Change-Id: Idb051e7ac3a7fb1fb86e015f709e32139d065d92
Reviewed-on: https://go-review.googlesource.com/47094Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

Fixes #19713

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

Fixes #20837.

Change-Id: I266519c26c8849da267b77e11abe7734d8275112
Reviewed-on: https://go-review.googlesource.com/47074Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Currently the execLock is a mutex, which has the unfortunate
side-effect of serializing all thread creation. This replaces it with
an rwmutex so threads can be created in parallel, but exec still
blocks thread creation.

Fixes #20738.

Change-Id: Ia8f30a92053c3d28af460b0da71176abe5fd074b
Reviewed-on: https://go-review.googlesource.com/47072
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently runtime.rwmutex is written to block the calling goroutine
rather than the calling thread. However, rwmutex was intended to be
used in the scheduler, which means it needs to be a thread-level
synchronization primitive.

Hence, this modifies rwmutex to synchronize threads instead of
goroutines. This has the consequence of making it write-barrier-free,
which is also important for using it in the scheduler.

The implementation makes three changes: it replaces the "w" semaphore
with a mutex, since this was all it was being used for anyway; it
replaces "writerSem" with a single pending M that parks on its note;
and it replaces "readerSem" with a list of Ms that park on their notes
plus a pass count that together emulate a counting semaphore. I
model-checked the safety and liveness of this implementation through
>1 billion schedules.

For #20738.

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

Prevent possible goroutine rescheduling to another P between
Put and Get calls by locking the goroutine to OS thread.

Inspired by the CL 42770.

Fixes #20198.

Change-Id: I18e24fcad1630658713e6b9d80d90d7941f604be
Reviewed-on: https://go-review.googlesource.com/44310
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

"Forward declaration" suggests that declarations must precede calls.

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

If the only way the user indicates they want alloc stats shown
is via ReportAllocs, we don't know that until benchFunc is run.
Therefore, StopTimer's ReadMemStats will return incorrect data
for single cycle runs since there's no counterpart ReadMemStats from
StartTimer that initializes alloc stats.

It appears that this bug was introduced by CL 46612,
"testing: only call ReadMemStats if necessary when benchmarking"

Fixes #20590

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

Updates #20836
Updates #19339
Updates #19652
Updates #20835
Updates #16511
Updates #10166
Updates #8574

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

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

Updates #20587

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

The test added for issue #18146 exposed a long-existing bug in the
Solaris port; notably, that syscall.Exec uses RawSyscall -- which is not
actually functional for the Solaris port (intentionally) and only exists
as a placebo to satisfy build requirements.

Call syscall.execve instead for Solaris.

Fixes #20832

Change-Id: I327d863f4bbbbbb6e5ecf66b82152c4030825d09
Reviewed-on: https://go-review.googlesource.com/47032
Run-TryBot: Shawn Walker-Salas <shawn.walker@oracle.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

os.Chmod returns an error when passed a long path (>=260) characters on
Windows. CL 32451 fixed most file functions in os. This change applies the
same fix to os.Chmod.

Fixes #20829

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

A common task is trying to get today's date in the local time zone
with zero values for the hour, minute, second, and nanosecond fields.
I tried this recently and incorrectly used Truncate(24*time.Hour),
which truncates based on a UTC clock, and gave me 5pm Pacific time
instead of midnight Pacific.

I thought it would be helpful to show a "correct" way to do this.

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

Fixes #20830.

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