3-index slices of the form s[:len(s):len(s)]
cannot be simplified to s[::len(s)].

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

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

Fixes #7631.

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

Generated by a+c.

R=gobot, rsc
CC=golang-codereviews
https://golang.org/cl/106340043

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

CC=golang-codereviews
https://golang.org/cl/101590043

We are not the right people to support editor plugins, and the profusion
of editors in this CL demonstrates the unreality of pretending to do so.
People are free to create and advertise their own repos with support.

For discussion: https://groups.google.com/forum/#!topic/golang-dev/SA7fD470FxU

LGTM=rminnich, kamil.kisiel, gri, rsc, dave, josharian, ruiu
R=golang-codereviews, rminnich, kamil.kisiel, gri, rsc, dominik.honnef, dave, josharian, ruiu, ajstarks
CC=golang-codereviews
https://golang.org/cl/105470043

There is no reason to generate different code for cap and len.

Fixes #8025.
Fixes #8026.

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

Breaks windows and race detector.
TBR=rsc

««« original CL description
runtime: stack allocator, separate from mallocgc

In order to move malloc to Go, we need to have a
separate stack allocator.  If we run out of stack
during malloc, malloc will not be available
to allocate a new stack.

Stacks are the last remaining FlagNoGC objects in the
GC heap.  Once they are out, we can get rid of the
distinction between the allocated/blockboundary bits.
(This will be in a separate change.)

Fixes #7468
Fixes #7424

LGTM=rsc, dvyukov
R=golang-codereviews, dvyukov, khr, dave, rsc
CC=golang-codereviews
https://golang.org/cl/104200047
»»»

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

In order to move malloc to Go, we need to have a
separate stack allocator.  If we run out of stack
during malloc, malloc will not be available
to allocate a new stack.

Stacks are the last remaining FlagNoGC objects in the
GC heap.  Once they are out, we can get rid of the
distinction between the allocated/blockboundary bits.
(This will be in a separate change.)

Fixes #7468
Fixes #7424

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

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

The old code's structure needed to track indirections because of the
use of unsafe. That is no longer necessary, so we can remove all
that tracking. The code cleans up considerably but is a little slower.
We may be able to recover that performance drop. I believe the
code quality improvement is worthwhile regardless.

BenchmarkEndToEndPipe           5610          5780          +3.03%
BenchmarkEndToEndByteBuffer     3156          3222          +2.09%

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

If the actual types of two reflect values are
the same and the values are structs, they must
have the same number of fields.

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

CC=golang-codereviews
https://golang.org/cl/103690043

This removes a major unsafe thorn in our side, a perennial obstacle
to clean garbage collection.
Not coincidentally: In cleaning this up, several bugs were found,
including code that reached inside by-value interfaces to create
pointers for pointer-receiver methods. Unsafe code is just as
advertised.

Performance of course suffers, but not too badly. The Pipe number
is more indicative, since it's doing I/O that simulates a network
connection. Plus these are end-to-end, so each end suffers
only half of this pain.

The edit is pretty much a line-by-line conversion, with a few
simplifications and a couple of new tests. There may be more
performance to gain.

BenchmarkEndToEndByteBuffer     2493          3033          +21.66%
BenchmarkEndToEndPipe           4953          5597          +13.00%

Fixes #5159.

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

Fix copy paste error pointed out by rsc, https://golang.org/cl/107290043/diff/60001/test/fixedbugs/issue8074.go#newcode7

LGTM=ruiu, r
R=golang-codereviews, ruiu, r
CC=golang-codereviews
https://golang.org/cl/106210047

Fixes #8299.

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

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

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

The only text that describes the accepted format is in the package doc,
which is far away from these functions. The other flag types don't need
this explicitness because they are more obvious.

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

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

Remove GC bitmap backward scanning.
This was already done once in https://golang.org/cl/5530074/
Still makes GC a bit faster.
On the garbage benchmark, before:
        gc-pause-one=237345195
        gc-pause-total=4746903
        cputime=32427775
        time=32458208
after:
        gc-pause-one=235484019
        gc-pause-total=4709680
        cputime=31861965
        time=31877772
Also prepares mgc0.c for future changes.

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

newproc takes two extra pointers, not two extra registers.
On amd64p32 (nacl) they are different.

We diagnosed this before the 1.3 cut but the tree was frozen.
I believe this is causing the random problems on the builder.

Fixes #8199.

TBR=r
CC=golang-codereviews
https://golang.org/cl/102710043

Include these files in the build,
even though they don't get executed.

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

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

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

Output number of spinning threads,
this is useful to understanding whether the scheduler
is in a steady state or not.

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

LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/108150043

Say when a goroutine is locked to OS thread in crash reports
and goroutine profiles.
It can be useful to understand what goroutines consume OS threads
(syscall and locked), e.g. if you forget to call UnlockOSThread
or leak locked goroutines.

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

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

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

Pending acceptance of CL 101500044
and adjustment of test/fixedbugs/bug299.go.

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

The runtime has historically held two dedicated values g (current goroutine)
and m (current thread) in 'extern register' slots (TLS on x86, real registers
backed by TLS on ARM).

This CL removes the extern register m; code now uses g->m.

On ARM, this frees up the register that formerly held m (R9).
This is important for NaCl, because NaCl ARM code cannot use R9 at all.

The Go 1 macrobenchmarks (those with per-op times >= 10 µs) are unaffected:

BenchmarkBinaryTree17              5491374955     5471024381     -0.37%
BenchmarkFannkuch11                4357101311     4275174828     -1.88%
BenchmarkGobDecode                 11029957       11364184       +3.03%
BenchmarkGobEncode                 6852205        6784822        -0.98%
BenchmarkGzip                      650795967      650152275      -0.10%
BenchmarkGunzip                    140962363      141041670      +0.06%
BenchmarkHTTPClientServer          71581          73081          +2.10%
BenchmarkJSONEncode                31928079       31913356       -0.05%
BenchmarkJSONDecode                117470065      113689916      -3.22%
BenchmarkMandelbrot200             6008923        5998712        -0.17%
BenchmarkGoParse                   6310917        6327487        +0.26%
BenchmarkRegexpMatchMedium_1K      114568         114763         +0.17%
BenchmarkRegexpMatchHard_1K        168977         169244         +0.16%
BenchmarkRevcomp                   935294971      914060918      -2.27%
BenchmarkTemplate                  145917123      148186096      +1.55%

Minux previous reported larger variations, but these were caused by
run-to-run noise, not repeatable slowdowns.

Actual code changes by Minux.
I only did the docs and the benchmarking.

LGTM=dvyukov, iant, minux
R=minux, josharian, iant, dave, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/109050043

Matches CL 101500044.

LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/110160044

A single iteration of BenchmarkSaveRestore runs for 5 seconds
on my freebsd machine. 5 seconds looks like too long for a single
iteration.
This is the only benchmark that times out on freebsd-amd64-race builder.

R=golang-codereviews, dave
CC=golang-codereviews
https://golang.org/cl/107340044

Breaks the build

««« original CL description
cmd/go: build test files containing non-runnable examples

Even if we can't run them, we should at least check that they compile.

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

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

Runs for 4 seconds on my mac.
Also this is the only test that times out on freebsd in -race mode.

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

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

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

This CL removes the special syntax for method receivers and
makes it just like other parameters. Instead, the crucial
receiver-specific rules (exactly one receiver, receiver type
must be of the form T or *T) are specified verbally instead
of syntactically.

This is a fully backward-compatible (and minor) syntax
relaxation. As a result, the following syntactic restrictions
(which are completely irrelevant) and which were only in place
for receivers are removed:

a) receiver types cannot be parenthesized
b) receiver parameter lists cannot have a trailing comma

The result of this CL is a simplication of the spec and the
implementation, with no impact on existing (or future) code.

Noteworthy:

- gc already permits a trailing comma at the end of a receiver
  declaration:

  func (recv T,) m() {}

  This is technically a bug with the current spec; this CL will
  legalize this notation.

- gccgo produces a misleading error when a trailing comma is used:

  error: method has multiple receivers

  (even though there's only one receiver)

- Compilers and type-checkers won't need to report errors anymore
  if receiver types are parenthesized.

Fixes #4496.

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