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>

Should use CMPL instead of CMPQ.

Fixes #20811.

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

t.Sub(u) would be -20 milliseconds.
The right computation is u.Sub(t), but rewrite to be even clearer.

Thanks to Karsten Weiss for catching this.

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

It should be $HOME/go instead of $HOME/work

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

Updates #20821

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

Prior to this change, if the Writer needed to use the PAX format, it would
output a USTAR header with an empty name. This should be okay since the PAX
specification dictates that the PAX record for "path" should override the
semantic meaning of any of the old USTAR fields.

Unfortunately, the implementation of tar on OpenBSD 6.1 is too strict with
their handling of PAX files such that they check for the validity of this
bogus field even though the PAX header is present.

To allow Go's Writer output be parsible by OpenBSD's tar utility,
we write a best-effort (ASCII-only and truncated) version of the original
file name. Note that this still fails in some edge-cases (for example,
a Chinese filename containing all non-ASCII characters). OpenBSD should really
relax their checking, as you honestly can't always expect a sensible path
to be generated when USTAR cannot handle the original path.

Fixes #20707

Change-Id: Id7d77349023d2152d7291d582cd050b6681760e4
Reviewed-on: https://go-review.googlesource.com/46914
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

clang can emit some dwarf.VoidType which are wrapped by multiple
dwarf.TypedefType. We need to unwrap those before further processing.

Fixes #20129

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

Also reword the testing/quick.Config field docs to conform to the
normal subject-first style. Without that style, godoc links
/pkg/testing/quick/#Config.Rand to the wrong line, since it doesn't
recognize the preceding comment as necessarily being attached.

Fixes #20809

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

Fixes #20810

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

If the LHS is unassignable, there's no point in trying to make sure
the RHS can be assigned to it or making sure they're realizable
types. This is consistent with go/types.

In particular, this prevents "1 = 2" from causing a panic when "1"
still ends up with the type "untyped int", which is not realizable.

Fixes #20813.

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

Since Reader.Peek potentially reads from the underlying io.Reader,
discarding previous buffers, UnreadRune and UnreadByte cannot
necessarily work.  Change Peek to invalidate the unread buffers in all
cases (as allowed according to the documentation) and thus prevent
hiding bugs in the caller.

Fixes #18556

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

Test just doesn't work.

Updates #20284

Change-Id: I31c3f771e68dcdc471767594a1467e19fbf5fe88
Reviewed-on: https://go-review.googlesource.com/46830
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@google.com>

After https://golang.org/cl/46421 is landed.
helpdoc.go should be updated that -buildmode=c-shared
requires only one main package.

Fixes #15082

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

Use 2 slashes, space, then tab. This is more consistent, and removes
inadvertent leading space.

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

This panic happens when the test fails due to the returned number of
certificates (r.certs) being less than expected by test case (tc.cns).
When i == len(r.certs) in the for loop, r.certs[i] will cause an index
out of range panic.

Also improve readability, consistency and style of the code. Use the
more common "got x, want y" pattern. See https://golang.org/s/style#useful-test-failures
for reference (and grep codebase for most common occurrences). Add a
comment, and remove blank line separating two blocks that are both
related to verifying that len(r.certs) == len(tc.cns). This should
help with readability.

Remove space after colon in call to t.Fatal, since it adds spaces
between its arguments.

Fixes #20801.

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

Updates #18598

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

Updates #20789

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

mutex profile requires explicit calls to
runtime.SetMutexProfileFraction to enable/disable
profiling (like block profile). It is worth
mentioning in the doc.

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

Fixes #20795
Updates #17895
Updates #20587

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

Add a test and fix for the request body being closed twice.

Fixes #19186

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

Updates #20284

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

We used to do it sometimes as an optimization, but the optimization is
flawed: in all non-contrived cases we need to deep clone the map
anyway. So do it always, which both simplifies the code but also fixes
the X-Forward-For value leaking to the caller's Request, as well as
modifications from the optional Director func.

Fixes #18327

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

When the dedicated mark worker runs, the scheduler won't run on that P
again until GC runs out of mark work. As a result, any goroutines in
that P's local run queue are stranded until another P steals them. In
a normally operating system this may take a long time, and in a 100%
busy system, the scheduler never attempts to steal from another P.

Fix this by draining the local run queue into the global run queue if
the dedicated mark worker has run for long enough. We don't do this
immediately upon scheduling the dedicated mark worker in order to
avoid destroying locality if the mark worker runs for a short time.
Instead, the scheduler delays draining the run queue until the mark
worker gets its first preemption request (and otherwise ignores the
preemption request).

Fixes #20011.

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

Fixes crash when printing a related error message later on.

Fixes #20789.

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

The existing implementation sequentially closes connection in the loop
and until the previous client connections is not closed the next one
would not be processed. Instead, the algorithm modified to spawn the
function that closes single connection in a standalone goroutine, thus
making at least a try to close it.

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

Change-Id: I284ecfab574b3058ba66b75f8f8d2ccdb90a8a0c
Reviewed-on: https://go-review.googlesource.com/46650
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

When Stop is called on a channel, wait until all signals have been
delivered to the channel before returning.

Use atomic operations in sigqueue to communicate more reliably between
the os/signal goroutine and the signal handler.

Fixes #14571

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

"MULBB R1, R2, R3" is encoded to 0xe163f182, which should be
0xe1630182.

This patch fix it.

fix #20764

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

I have no test case for this, but there is one report on the mailing list
(https://groups.google.com/d/msg/golang-dev/sDg-t1_DPw0/-AJmLxgPBQAJ)
in which waitid running on MIPS returns EFAULT.

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

If GOROOT_FINAL was set during the build, the default GOROOT
will not be testGOROOT. Determine the default GOROOT by reading
the right source file instead of guessing. (GOROOT_FINAL may no
longer be set when the test is actually run.)

Also refactor a bit.

Fixes #20284.

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

Maybe there are no Go files at all.
Maybe they are all excluded by build constraints.
Maybe there are only test Go files.
Be specific.

Fixes #17008.
Fixes parts of #20760.

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

We can't follow symlinks for fear of directory cycles and other problems,
but we can at least notice potentially-relevant symlinks that are being
ignored and report them.

Fixes #17662.

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

We already detect this collision when both imports are used
anywhere in a single program. Also detect it when they are in
different targets being processed together.

Fixes #20264.

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