LGTM=gri, iant
R=gri, iant
CC=golang-codereviews
https://golang.org/cl/75920044

Breaks all builds.

««« original CL description
cmd/gc: Add tests for self-referential array types.

LGTM=gri, iant
R=gri, iant
CC=golang-codereviews
https://golang.org/cl/77050045
»»»

TBR=cmang
R=cmang
CC=golang-codereviews
https://golang.org/cl/77210043

The original test would open a local port and then immediately close it
and use the port number in subsequent tests. Between the port being closed
and reused by the later process, it could be opened by some other program
on the machine.

Changed the test to run the server process directly and have it save the
assigned port to a text file to be used by client processes.

Fixes #5564.

LGTM=adg
R=golang-codereviews, gobot, adg
CC=golang-codereviews
https://golang.org/cl/72290043

LGTM=gri, iant
R=gri, iant
CC=golang-codereviews
https://golang.org/cl/77050045

%q quotes each element of a string slice; this was never explained in the docs.
Fixes #7015.

LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews
https://golang.org/cl/77140044

Fixes #7521.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/76320043

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/77120044

Request ID reuse is allowed by the FastCGI spec [1]. In particular nginx uses
the same request ID, 1, for all requests on a given connection. Because
serveRequest does not remove the request from conn.requests, this causes it to
treat the second request as a duplicate and drops the connection immediately
after beginRequest. This manifests with nginx option 'fastcgi_keep_conn on' as
the following message in nginx error log:

2014/03/17 01:39:13 [error] 730#0: *109 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: x.x.x.x, server: example.org, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "example.org"

Because handleRecord and serveRequest run in different goroutines, access to
conn.requests must now be synchronized.

[1] http://www.fastcgi.com/drupal/node/6?q=node/22#S3.3

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/76800043

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/76400044

I believe the original author of this code just forgot to check for error here.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/76760043

"env" is a valid go command. This patch is to make bash to autocomplete it.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/74660045

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/76930044

Smooth out the setup process for new contributors.

* Remove references $GOROOT (often not defined).
* Add a note for contributing to subrepositories.
* Emphasize that hg mail also uploads the latest copy.

LGTM=adg
R=golang-codereviews, iant, adg
CC=golang-codereviews
https://golang.org/cl/74370043

LGTM=minux.ma
R=golang-codereviews, minux.ma
CC=golang-codereviews
https://golang.org/cl/76270043

See testing.FailNow for further information.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/75900043

It was using the wrong offset and returned random values
making "runoutput" compiler tests crash.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/76250043

They were rejected by NaCl due to AES instructions and
accesses to %gs:0x8, caused by wrong tlsoffset value.

LGTM=iant
R=rsc, dave, iant
CC=golang-codereviews
https://golang.org/cl/76050044

It's possible that bgsweep constantly does not catch up for some reason,
in this case runfinq was not woken at all.

R=rsc
CC=golang-codereviews
https://golang.org/cl/75940043

The problem was that spans end up in wrong lists after split
(e.g. in h->busy instead of h->central->empty).
Also the span can be non-swept before split,
I don't know what it can cause, but it's safer to operate on swept spans.
Fixes #7544.

R=golang-codereviews, rsc
CC=golang-codereviews, khr
https://golang.org/cl/76160043

LGTM=rsc
R=rsc, dave, iant, khr
CC=golang-codereviews
https://golang.org/cl/75820044

Currently processes crash with obscure message.
Say that it's "out of memory".

LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/75820045

See the comment for description.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/75670044

LGTM=rsc
R=golang-codereviews
CC=golang-codereviews, khr, rsc
https://golang.org/cl/76070043

Fixes #7262

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/76110043

Fixes #6405

LGTM=rsc
R=rsc, iant
CC=golang-codereviews
https://golang.org/cl/72920046

Old versions of DTrace (as those shipped in OS X and FreeBSD)
don't support unicode characters in symbol names.  Replace '·'
to '.' to make DTrace happy.

Fixes #7493

LGTM=aram, rsc
R=aram, rsc, gobot, iant
CC=golang-codereviews
https://golang.org/cl/72280043

The Solaris network poller uses event ports, which are
level-triggered. As such, it has to re-arm itself after each
wakeup. The arming mechanism (which runs in its own thread) raced
with the closing of a file descriptor happening in a different
thread. When a network file descriptor is about to be closed,
the network poller is awaken to give it a chance to remove its
association with the file descriptor. Because the poller always
re-armed itself, it raced with code that closed the descriptor.

This change makes the network poller check before re-arming if
the file descriptor is about to be closed, in which case it will
ignore the re-arming request. It uses the per-PollDesc lock in
order to serialize access to the PollDesc.

This change also adds extensive documentation describing the
Solaris implementation of the network poller.

Fixes #7410.

LGTM=dvyukov, iant
R=golang-codereviews, bradfitz, iant, dvyukov, aram.h, gobot
CC=golang-codereviews
https://golang.org/cl/69190044

debug/elf does the same thing, use []byte{} for
any missing sections.

Fixes #7510

LGTM=rsc
R=golang-codereviews, iant
CC=golang-codereviews, rsc
https://golang.org/cl/75230043

LGTM=rsc
R=rsc, 0intro, aram, jeremyjackins, iant
CC=golang-codereviews, lucio.dere, minux.ma, paurea, r
https://golang.org/cl/9796043

Mark free memory blocks as unused.
On amd64 it allows the process to eat all 128 GB of heap
without killing the machine.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/74070043

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/75350043

This check would allowed to easily prevent issue 7511.
Update #7511

LGTM=rsc
R=rsc, aram
CC=golang-codereviews
https://golang.org/cl/75260043

This is especially important for SetPanicOnCrash,
but also useful for e.g. nil deref in mallocgc.
Panics on such crashes can't lead to anything useful,
only to deadlocks, hangs and obscure crashes.
This is a copy of broken but already LGTMed
https://golang.org/cl/68540043/

TBR=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/75320043

When we copy stack, we check only new size of the top segment.
This is incorrect, because we can have other segments below it.

LGTM=khr
R=golang-codereviews, khr
CC=golang-codereviews, rsc
https://golang.org/cl/73980045

Calling runtime·cgocall could trigger a GC in the child while
gclock was held by the parent.

Fixes #7511

LGTM=bradfitz, dvyukov, dave
R=golang-codereviews, bradfitz, dvyukov, dave
CC=golang-codereviews, rsc
https://golang.org/cl/75210044

The lowering to runtime calls introduces hidden pointers to the
arguments of select clauses. When implicit conversions were
involved it could end up with incompatible pointers. Since the
pointed-to types have the same representation, we can introduce a
forced conversion.

Fixes #6847.

LGTM=rsc
R=rsc, iant, khr
CC=golang-codereviews
https://golang.org/cl/72380043

It was using a REP STOSQ but putting in CX the number of 32-bit
words to clear.

LGTM=dave
R=rsc, dave
CC=golang-codereviews
https://golang.org/cl/75240043

Fixes #7528.

LGTM=jsing
R=jsing
CC=golang-codereviews
https://golang.org/cl/75140045

Under some circumstances, gccgoToolchain's ld can pass the path of
build outputs that have been deleted to the link command.

Fixes #7303.

LGTM=rsc
R=golang-codereviews, dave, michael.hudson, rsc
CC=golang-codereviews
https://golang.org/cl/61970044

Otherwise, we won't get a stack trace in some of the early init.

Here's one example:

        http://build.golang.org/log/a96d10f6aee1fa3e3ae51f41da46d414a7ab02de

After walking the stack by hand in acid, I was able to determine
that the stackalloc inside mpreinit was causing the throw.

LGTM=rsc
R=rsc, dvyukov
CC=golang-codereviews
https://golang.org/cl/72450044