If you write:

        var x = 3

then the compiler arranges for x to be initialized in the linker
with an actual 3 from the data segment, rather than putting
x in the bss and emitting init-time "x = 3" assignment code.

If you write:

        var y = x
        var x = 3

then the compiler is clever and treats this the same as if
the code said 'y = 3': they both end up in the data segment
with no init-time assignments.

If you write

        var y = x
        var x int

then the compiler was treating this the same as if the
code said 'x = 0', making both x and y zero and avoiding
any init-time assignment.

This copying optimization to avoid init-time assignment of y
is incorrect if 'var x int' doesn't mean 'x = 0' but instead means
'x is initialized in C or assembly code'. The program ends up
with 'y = 0' instead of 'y = the value specified for x in that other code'.

Disable the propagation if there is no initializer for x.

This comes up in some uses of cgo, because cgo generates
Go globals that are initialized in accompanying C files.

Fixes #7665.

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

Fixes #7928.

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

If the ... element type contained no pointers,
then the escape analysis did not track the ... itself.
This manifested in an escaping ...byte being treated
as non-escaping.

Fixes #7934.

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

The register allocator decides which variables should be placed into registers by charging for each load/store and crediting for each use, and then selecting an allocation with minimal cost. NOPs will be eliminated, however, so using a variable in a NOP should not generate credit.

Issue 7867 arises from attempted registerization of multi-word variables because they are used in NOPs. By not crediting for that use, they will no longer be considered for registerization.

This fix could theoretically lead to better register allocation, but NOPs are rare relative to other instructions.

Fixes #7867.

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

Fixes #6844.

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

Fixes #7901.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/90930044

TestDialFailPDLeak was created for testing runtime-integrated netwrok
poller stuff and used during Go 1.2 development cycle. Unfortunately
it's still flakey because it depends on MemStats of runtime, not
pollcache directly, and MemStats accounts and revises its own stats
occasionally.

For now the codepaths related to runtime-intergrated network poller
are pretty stable, so removing this test case never suffers us.

Fixes #6553.

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

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

There was confusion in the behavior of json.Indent; This change
attempts to clarify the behavior by providing a bit more verbiage
to the documentation as well as provide an example function.

Fixes #7821.

LGTM=robert.hencke, adg
R=golang-codereviews, minux.ma, bradfitz, aram, robert.hencke, r, adg
CC=golang-codereviews
https://golang.org/cl/97840044

Fixes #7936.

LGTM=alex.brainman, bradfitz, iant
R=golang-codereviews, alex.brainman, bradfitz, iant
CC=golang-codereviews
https://golang.org/cl/100060043

Update #7188
Fixes #7894.

LGTM=alex.brainman, bradfitz, r
R=golang-codereviews, alex.brainman, mikioh.mikioh, gobot, r, bradfitz
CC=golang-codereviews
https://golang.org/cl/95870043

benchmark                 old ns/op     new ns/op     delta
BenchmarkCopyFat512       1307          329           -74.83%
BenchmarkCopyFat256       666           169           -74.62%
BenchmarkCopyFat1024      2617          671           -74.36%
BenchmarkCopyFat128       343           89.0          -74.05%
BenchmarkCopyFat64        182           48.9          -73.13%
BenchmarkCopyFat32        103           28.8          -72.04%
BenchmarkClearFat128      102           46.6          -54.31%
BenchmarkClearFat512      344           167           -51.45%
BenchmarkClearFat64       50.5          26.5          -47.52%
BenchmarkClearFat256      147           87.2          -40.68%
BenchmarkClearFat32       22.7          16.4          -27.75%
BenchmarkClearFat1024     511           662           +29.55%

Fixes #7624

LGTM=rsc
R=golang-codereviews, khr, bradfitz, josharian, dave, rsc
CC=golang-codereviews
https://golang.org/cl/92760044

Existing test TestMaxOpenConns was failing occasionally, especially
with higher values of GOMAXPROCS.

Fixes #7532

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

- A channel may be used between any number of goroutines,
  not just two.
- Replace "passing a value" (which is not further defined)
  by "sending and receiving a value".
- Made syntax production more symmetric.
- Talk about unbuffered channels before buffered channels.
- Clarify what the comma,ok receive values mean (issue 7785).

Not a language change.

Fixes #7785.

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

This is a clarification of what happens already.
Not a language change.

Fixes #7137.

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

If the underlying type of a type T is a boolean, numeric,
or string type, then T is also a boolean, numeric, or
string type, respectively.

Not a language change.

Fixes #7551.

LGTM=iant, rsc, robert.hencke, r
R=r, rsc, iant, ken, robert.hencke
CC=golang-codereviews
https://golang.org/cl/100130044

Increases throughput by 2x on a memory hungry program on 8-node NUMA machine.

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

Currently tip.golang.org leads to golang.org and
local godoc also leads to golang.org (when you don't have internet connectivity).

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/100200043

Number of lost samples was overcounted (never reset).
Also remove unused variable (it's trivial to restore it for debugging if needed).

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

Fixes #6807.

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

Just like run.* scripts do.
Fixes race build.

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

LGTM=iant
R=dsymonds, iant
CC=golang-codereviews, pfr
https://golang.org/cl/98970045

Update #7947

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

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

Update #7406
Fixes #7899

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

Fixes #7071.

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

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

Update #7899

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

The previous syscall constants regeneration on openbsd was conducted
with OpenBSD current 3 months ago and it missed updating openbsd/386.
This CL adds TIOCGSID for fixing the inconsistency between opensbd/amd64
and openbsd/386.

Update #7049

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

We will serve downloads from here until we work out a better plan.

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

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

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

R=rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/100110043

Fixes #7592

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

Where the spelling changed from British to
US norm (e.g., optimise -> optimize) it follows
the style in that file.

LGTM=adonovan
R=golang-codereviews, adonovan
CC=golang-codereviews
https://golang.org/cl/96980043

Generated by addca.

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

Because gotraceback is called early and often, its cache commits to the value of getenv("GOTRACEBACK") before getenv is even ready.  So now we reset its cache once getenv becomes ready.  Panicking programs now dump core again.

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

If slice append is the only place where a program allocates,
then it will consume all available memory w/o triggering GC.
This was demonstrated in the issue.
Fixes #7922.

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

The monotonic clock patch changed all runtime times
to abstract monotonic time. As the result user-visible
MemStats.LastGC become monotonic time as well.
Restore Unix time for LastGC.

This is the simplest way to expose time.now to runtime that I found.
Another option would be to change time.now to C called
int64 runtime.unixnanotime() and then express time.now in terms of it.
But this would require to introduce 2 64-bit divisions into time.now.
Another option would be to change time.now to C called
void runtime.unixnanotime1(struct {int64 sec, int32 nsec} *now)
and then express both time.now and runtime.unixnanotime in terms of it.

Fixes #7852.

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

If systems actually read that much, using 2GB-1 will
result in misaligned subsequent reads. Use 1GB instead,
which will certainly keep reads aligned and which is
plenty large enough.

Update #7812.

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