This fixes `go test go/types`.

https://golang.org/cl/23487/ introduced this code which contains
two unused variables (declared and assigned to, but never read).
cmd/compile doesn't report the error due open issue #8560 (the
variables are assigned to in a closure), but go/types does. The
build bot only runs go/types tests in -short mode (which doesn't
typecheck the std lib), hence this doesn't show up on the dashboard
either.

We cannot call b.Fatal and friends in the goroutine. Communicating
the error to the invoking function requires a channel or a mutex.
Unless the channel/sycnhronized variable is tested in each iteration
that follows, the iteration blocks if there's a failure. Testing in
each iteration may affect benchmark times.

One could use a time-out but that time depends on the underlying system.
Panicking seems good enough in this unlikely case; better than hanging
or affecting benchmark times.

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

Test all the weird shifts, like int8 shifted right by uint16.
Increases coverage for shift lowerings in AMD64.rules.

Change-Id: I066fe6ad6bfc05253a8d6a2ee17ff244d3a7652e
Reviewed-on: https://go-review.googlesource.com/23585
Run-TryBot: Todd Neal <todd@tneal.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Todd Neal <todd@tneal.org>

Both compilers and also go/types don't permit duplicate types in
type switches; i.e., this spec change is documenting a status quo
that has existed for some time.

Furthermore, duplicate nils are not accepted by gccgo or go/types;
and more recently started causing a compiler error in gc. Permitting
them is inconsistent with the existing status quo.

Rather than making it an implementation restriction (as we have for
expression switches), this is a hard requirement since it was enforced
from the beginning (except for duplicate nils); it is also a well
specified requirement that does not pose a significant burden for
an implementation.

Fixes #15896.

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

Implemented by using a reflect-based approach to recognize the zero
value of any non-interface type that implements flag.Value.  Interface
types will fall back to the old code.

Fixes #15904.

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

Some of these errors are reported in the wrong places.
That’s issue #15911 and #15912.

Change-Id: Ia09d7f89be4d15f05217a542a61b6ac08090dd87
Reviewed-on: https://go-review.googlesource.com/23588
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

This fixes handling of cgo flags and makes sure packages that are only
implicitly included in the shared library are passed to the link.

Fixes #15885

Change-Id: I1e8a72b5314261973ca903c78834700fb113dde9
Reviewed-on: https://go-review.googlesource.com/23537Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #15856.

Change-Id: Ia8def161642087e4bd92a87298c77a0f9f83dc86
Reviewed-on: https://go-review.googlesource.com/23586
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

When doing a backtrace from a signal that occurs in C code compiled
without using -fasynchronous-unwind-tables, we have to rely on frame
pointers. In order to do that, the traceback function needs the signal
context to reliably pick up the frame pointer.

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

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

The code has moved from code.google.com to github.com.

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

golang.org/issue/15443 complained that a race-enabled PIE binary crashed at
startup, but other ways of linking in tsan (or other sanitizers) such as

 #cgo CFLAGS: -fsanitize=thread
 #cgo LDFLAGS: -fsanitize=thread

have the same problem. Pass -no-pie to the host linker (if supported) if any
-fsanitizer=foo cgo LDFLAG is seen when linking.

Fixes #15887

Change-Id: Id799770f8d045f6f40fa8c463563937a5748d1a8
Reviewed-on: https://go-review.googlesource.com/23535
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #15900

Change-Id: Ieada5f4e3b3b2ae358414e013f3090b4b820569b
Reviewed-on: https://go-review.googlesource.com/23536
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Add TSAN acquire/release calls to runtime/cgo to match the ones
generated by cgo.  This avoids a false positive race around the malloc
memory used in runtime/cgo when other goroutines are simultaneously
calling malloc and free from cgo.

These new calls will only be used when building with CGO_CFLAGS and
CGO_LDFLAGS set to -fsanitize=thread, which becomes a requirement to
avoid all false positives when using TSAN.  These are needed not just
for runtime/cgo, but also for any runtime package that uses cgo (such as
net and os/user).

Add an unused attribute to the _cgo_tsan_acquire and _cgo_tsan_release
functions, in case there are no actual cgo function calls.

Add a test that checks that setting CGO_CFLAGS/CGO_LDFLAGS avoids a
false positive report when using os/user.

Change-Id: I0905c644ff7f003b6718aac782393fa219514c48
Reviewed-on: https://go-review.googlesource.com/23492
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

Fixes #15898.

Change-Id: I66e2ad21f283563c7142aa820f0354711d964768
Reviewed-on: https://go-review.googlesource.com/23573
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>

As rendered on https://tip.golang.org/pkg/compress/flate/, there is an
extra new-line because of the unexported constants in the same block.

<<<
const (
    NoCompression      = 0
    BestSpeed          = 1
    BestCompression    = 9
    DefaultCompression = -1
    HuffmanOnly        = -2 // Disables match search and only does Huffman entropy reduction.

)
>>>

Instead, seperate the exported compression level constants into its own
const block. This is both more readable and also fixes the issue.

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

In order to support pprof for position independent executables, pprof
needs to adjust the PC addresses stored in the profile by the address at
which the program is loaded. The legacy profiling support which we use
already supports recording the GNU/Linux /proc/self/maps data
immediately after the CPU samples, so do that. Also change the pprof
symbolizer to use the information, if available, when looking up
addresses in the Go pcline data.

Fixes #15714.

Change-Id: I4bf679210ef7c51d85cf873c968ce82db8898e3e
Reviewed-on: https://go-review.googlesource.com/23525Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>

The Windows builders run the throughput benchmarks really slowly with a
64kb buffer. Lowering it to 16kb brings the performance back into line
with the other builders.

This is a work-around to get the build green until we can figure out why
the Windows builders are slow with the larger buffer size.

Update #15899

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

This is a correction to CL 22610.  The gbit16 function is called in
StartProcess between fork and exec, and therefore must not split the
stack.  Normally it's inlined so this is not an issue, but on one
occasion I've observed it to be compiled without inlining, and the
result was a panic.  Mark it go:nosplit to be safe.

Change-Id: I0381754397b766431bf406d9767c73598d23b901
Reviewed-on: https://go-review.googlesource.com/23560Reviewed-by: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #15418

Change-Id: Ibc51d602eb28819d0e44e5ca13a5c61573e4111c
Reviewed-on: https://go-review.googlesource.com/23570Reviewed-by: Dmitry Vyukov <dvyukov@google.com>

This is a minimal fix to prevent this and
other possible future infinite recursion.
We can put in a proper fix for UNC in Go 1.8.

Updates #15879

Change-Id: I3653cf5891bab8511adf66fa3c1a1d8912d1a293
Reviewed-on: https://go-review.googlesource.com/23572
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

Updates #15810

Change-Id: I37f14a0ed1f5ac24ea2169a7e65c0469bfddd928
Reviewed-on: https://go-review.googlesource.com/23559Reviewed-by: Michael McGreevy <mcgreevy@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>

forceCloseSockets is just designed as a kingston valve for TestMain
function and is not suitable to keep track of inflight sockets.

Fixes #15525.

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

The original draft mentioned support for json.Marshaler, but that's
not the case.  JSON supports only string keys (not arbitrary JSON)
so only encoding.TextMarshaller is supported.

Change-Id: I7788fc23ac357da88e92aa0ca17b513260840cee
Reviewed-on: https://go-review.googlesource.com/23529Reviewed-by: Andrew Gerrand <adg@golang.org>

Add a bunch of tests for shifts.

Fix triple-shift rules to always take constant shifts as 64 bits.
(Earlier rules always promote shift amounts to 64 bits.)
Add overflow checks.

Increases generic rule coverage to 91%

Change-Id: I6b42d368d19d36ac482dbb8e0d4f67e30ad7145d
Reviewed-on: https://go-review.googlesource.com/23555Reviewed-by: Todd Neal <todd@tneal.org>

Increases generic.rules coverage from 91% to 95%.

Change-Id: I981eb94f3cd10d2f87c836576a43786787a25d83
Reviewed-on: https://go-review.googlesource.com/23556
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Todd Neal <todd@tneal.org>

The documentation previously used C style enumerations: 0, 1, 2.
While this is pretty much universally correct, it does not help a user
become aware of the existence of the SeekStart, SeekCurrent, and SeekEnd
constants. Thus, we should use them in the documentation to direct people's
attention to them.

Updates #6885

Change-Id: I44b5e78d41601c68a0a1c96428c853df53981d52
Reviewed-on: https://go-review.googlesource.com/23551Reviewed-by: Andrew Gerrand <adg@golang.org>

Document the following:
* That the algorithmic changes are still compliant with RFC 1951. I remember
people having questions regarding this issue, and it would be good to re-assure
them that it is still standards compliant.
* io.EOF can now be returned early (c27efce6)
* Use the term "decompress" when referred to as an action. The term "uncompressed"
or "decompressed" are both valid as ways to represent the current state of the data.

Change-Id: Ie29ebce709357359e7c36d3e7f3d53b260eaadfa
Reviewed-on: https://go-review.googlesource.com/23552Reviewed-by: Andrew Gerrand <adg@golang.org>

Fixes #15868

Change-Id: I4e4471e77091309c4ea1d546b2c4f20dfbb4314e
Reviewed-on: https://go-review.googlesource.com/23550Reviewed-by: Andrew Gerrand <adg@golang.org>

Also: Added some test cases for issue #10709.
No impact when debugging output is disabled (default).

For #10709.

Change-Id: I0751befb222c86d46225377a674f6bad2990349e
Reviewed-on: https://go-review.googlesource.com/23442Reviewed-by: Alan Donovan <adonovan@google.com>

Fixes #15689

Change-Id: I56d0103738cc35cd5bc5e77a0e0341c0dd55530e
Reviewed-on: https://go-review.googlesource.com/23440Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>

When we do *p = f(), we might need to copy the return value from
f to p with a write barrier.  The write barrier itself is a call,
so we need to copy the return value of f to a temporary location
before we call the write barrier function.  Otherwise, the call
itself (specifically, marshalling the args to typedmemmove) will
clobber the value we're trying to write.

Fixes #15854

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

For #15840.

Change-Id: I2ecf5c7b00afc2034cf3d7a1fd78636a908beb67
Reviewed-on: https://go-review.googlesource.com/23517
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

Commit fa3543e3 introduced formatting errors.

Change-Id: I4b921f391a9b463cefca4318ad63b70ae6ce6865
Reviewed-on: https://go-review.googlesource.com/23514Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>

Commit 36a80c59 introduced formatting errors.

Change-Id: I6d5b231200cd7abcd5b94c1a3f4e99f10ee11c4f
Reviewed-on: https://go-review.googlesource.com/23513Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>

Fixes #15864.

Change-Id: Ic12aa3654bf0b7e4a26df20ea92d07d7efe7339c
Reviewed-on: https://go-review.googlesource.com/23504Reviewed-by: David Chase <drchase@google.com>

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

Also adds missing copyright notice.

Updates #15603.

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

Currently when the garbage collector frees stacks of dead goroutines
in markrootFreeGStacks, it calls stackfree on a regular user stack.
This is a problem, since stackfree manipulates the stack cache in the
per-P mcache, so if it grows the stack or gets preempted in the middle
of manipulating the stack cache (which are both possible since it's on
a user stack), it can easily corrupt the stack cache.

Fix this by calling markrootFreeGStacks on the system stack, so that
all calls to stackfree happen on the system stack. To prevent this bug
in the future, mark stack functions that manipulate the mcache as
go:systemstack.

Fixes #15853.

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

For #15599.

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

The current code, introduced after Go 1.6 to improve latency on
low-bandwidth connections, sends 1 kB packets until 1 MB has been sent,
and then sends 16 kB packets (the maximum record size).

Unfortunately this decreases throughput for 1-16 MB responses by 20% or so.

Following discussion on #15713, change cutoff to 128 kB sent
and also grow the size allowed for successive packets:
1 kB, 2 kB, 3 kB, ..., 15 kB, 16 kB.
This fixes the throughput problems: the overhead is now closer to 2%.

I hope this still helps with latency but I don't have a great way to test it.
At the least, it's not worse than Go 1.6.

Comparing MaxPacket vs DynamicPacket benchmarks:

name              maxpkt time/op  dyn. time/op delta
Throughput/1MB-8    5.07ms ± 7%   5.21ms ± 7%  +2.73%  (p=0.023 n=16+16)
Throughput/2MB-8   15.7ms ±201%    8.4ms ± 5%    ~     (p=0.604 n=20+16)
Throughput/4MB-8    14.3ms ± 1%   14.5ms ± 1%  +1.53%  (p=0.000 n=16+16)
Throughput/8MB-8    26.6ms ± 1%   26.8ms ± 1%  +0.47%  (p=0.003 n=19+18)
Throughput/16MB-8   51.0ms ± 1%   51.3ms ± 1%  +0.47%  (p=0.000 n=20+20)
Throughput/32MB-8    100ms ± 1%    100ms ± 1%  +0.24%  (p=0.033 n=20+20)
Throughput/64MB-8    197ms ± 0%    198ms ± 0%  +0.56%   (p=0.000 n=18+7)

The small MB runs are bimodal in both cases, probably GC pauses.
But there's clearly no general slowdown anymore.

Fixes #15713.

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