This should allow multiple goyacc grammars to be
compiled into the same binary. There's a chance it
Fixes #1562.

R=rsc, r2
CC=golang-dev
https://golang.org/cl/4256044

R=adg, bsiegert, rsc
CC=golang-dev
https://golang.org/cl/4221047

Fixes #1566.

R=ken2
CC=golang-dev
https://golang.org/cl/4259041

Otherwise if there is an installed /usr/bin/6g the build
will use that one instead of the one it builds.

R=r
CC=golang-dev
https://golang.org/cl/4249045

Return <!DOCTYPE ...> with nested directives as one big token.

Fixes #1549.

R=niemeyer, rsc
CC=golang-dev
https://golang.org/cl/4216050

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4248047

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4248043

This functionality might be used in environments
where programs are limited to a single thread,
to simulate a select-driven network server.  It is
not exposed via the standard runtime API.

R=r, r2
CC=golang-dev
https://golang.org/cl/4254041

to move some variables from the stack to the heap.

Sorted benchmark runs on my 2007-era Mac Mini (GOARCH=amd64, GOOS=linux):

Before:
lzw.BenchmarkDecoder        2000        878176 ns/op
lzw.BenchmarkDecoder        2000        878415 ns/op
lzw.BenchmarkDecoder        2000        880352 ns/op
lzw.BenchmarkDecoder        2000        898445 ns/op
lzw.BenchmarkDecoder        2000        901728 ns/op

After:
lzw.BenchmarkDecoder        2000        859065 ns/op
lzw.BenchmarkDecoder        2000        859402 ns/op
lzw.BenchmarkDecoder        2000        860035 ns/op
lzw.BenchmarkDecoder        2000        860555 ns/op
lzw.BenchmarkDecoder        2000        861109 ns/op

The ratio of before/after median times is 1.024.

The runtime.MemStats.Mallocs delta per loop drops from 109 to 104.

R=r, r2, dfc
CC=golang-dev
https://golang.org/cl/4253043

on each loop iteration, yielding a 20x performance improvement.

R=rsc, r2
CC=golang-dev
https://golang.org/cl/4240044

R=agl, agl1
CC=golang-dev
https://golang.org/cl/4255041

again.
CL 4222043 missed this case.

R=brainman, r, r2
CC=golang-dev
https://golang.org/cl/4235043

go/doc wants to see text after BUG(uid): on the same line
in order to treat it as an official bug comment.

R=gri
CC=golang-dev
https://golang.org/cl/4250043

Using the kernel-supplied compare-and-swap code
on linux/arm means that runtime doesn't have to care
whether this is GOARM=5 or GOARM=6 anymore.

Fixes #1494.

R=r, r2
CC=golang-dev
https://golang.org/cl/4245043

Remove references to custom assembly routines.

R=r, r2
CC=golang-dev
https://golang.org/cl/4241043

Fixes #170.

R=gri, iant, r, r2
CC=golang-dev
https://golang.org/cl/4241041

R=r, r2, gri
CC=ehog.hedge, golang-dev
https://golang.org/cl/4240043

Before this fix, types such as
        type T map[string]T
caused infinite recursion in the gob implementation.
Now they just work.

Fixes #1518.

R=rsc
CC=golang-dev
https://golang.org/cl/4230045

R=ken2
CC=golang-dev
https://golang.org/cl/4240041

R=ken2
CC=golang-dev
https://golang.org/cl/4239041

Also: renamed fixedbugs/bug322.go to fixedbugs/bug323.go
because we already have a bugs/bug322.go and bug322.dir.

R=rsc
CC=golang-dev
https://golang.org/cl/4219044

R=rsc
CC=golang-dev
https://golang.org/cl/4231045

R=r, rsc
CC=golang-dev
https://golang.org/cl/4213044

R=bradfitzgo
CC=golang-dev
https://golang.org/cl/3989052

When providing addition file systems to godoc via -path, the
path names may be symbolic links. Follow them.

Also: better logging of error and special conditions.

R=r, dsymonds, r2
CC=golang-dev
https://golang.org/cl/4217045

R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/4223049

R=rsc, nigeltao_gnome
CC=golang-dev
https://golang.org/cl/4209043

The pointer will eventually let us find *T given T.
This CL just makes room for it, always storing a zero.

R=r, r2
CC=golang-dev
https://golang.org/cl/4221046

In CL 4188061 I changed malg to allocate the requested
number of bytes n, not n+StackGuard, so that the
allocations would use rounder numbers.

The allocation of the signal stack asks for 32k and
then used g->stackguard as the base, but g->stackguard
is StackGuard bytes above the base.  Previously, asking
for 32k meant getting 32k+StackGuard bytes, so using
g->stackguard as the base was safe.  Now, the actual base
must be computed, so that the signal handler does not
run StackGuard bytes past the top of the stack.

Was causing flakiness mainly in programs that use the
network, because they sometimes write to closed network
connections, causing SIGPIPEs.  Was also causing problems
in the doc/progs test.

Also fix Makefile so that changes to stack.h trigger rebuild.

R=bradfitzgo, r, r2
CC=golang-dev
https://golang.org/cl/4230044

A reference to the address of weak.foo resolves at link time
to the address of the symbol foo if foo would end up in the
binary anyway, or to zero if foo would not be in the binary.

For example:

        int xxx = 1;
        int yyy = 2;
        int weak·xxx;
        int weak·yyy;

        void main·main(void) {
                runtime·printf("%p %p %p\n", &xxx, &weak·xxx, &weak·yyy);
        }

prints the same non-nil address twice, then 0 (because yyy is not
referenced so it was dropped from the binary).

This will be used by the reflection tables.

R=iant
CC=golang-dev
https://golang.org/cl/4223044

Issue 1547 is fixed.

R=bradfitzgo, r
CC=golang-dev
https://golang.org/cl/4209045

If the filename was absolute, writeFileAtomically
used the wrong filename for ioutil.TempFile leading
to non-existent directories and the TempFile would
fail.

R=r, r2
CC=golang-dev
https://golang.org/cl/4224043

R=r, r2
CC=golang-dev
https://golang.org/cl/4230042

when we hit a newline during *scanln routines.

Fixes #1490.

R=rsc
CC=golang-dev
https://golang.org/cl/4209042

Fixes #1516.

R=rsc, mattn
CC=golang-dev
https://golang.org/cl/4214041

R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/4217042

R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/4210041

R=adg, bradfitzwork
CC=golang-dev
https://golang.org/cl/4229042

R=r, r2
CC=golang-dev
https://golang.org/cl/4226043

Avoids deadlocks like the one below, in which a stack split happened
in order to call lock(&stacks), but then the stack unsplit cannot run
because stacks is now locked.

The only code calling stackalloc that wasn't on a scheduler
stack already was malg, which creates a new goroutine.

runtime.futex+0x23 /home/rsc/g/go/src/pkg/runtime/linux/amd64/sys.s:139
       runtime.futex()
futexsleep+0x50 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:51
       futexsleep(0x5b0188, 0x300000003, 0x100020000, 0x4159e2)
futexlock+0x85 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:119
       futexlock(0x5b0188, 0x5b0188)
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
       runtime.lock(0x5b0188, 0x7f0d27b4a000)
runtime.stackfree+0x4d /home/rsc/g/go/src/pkg/runtime/malloc.goc:336
       runtime.stackfree(0x7f0d27b4a000, 0x1000, 0x8, 0x7fff37e1e218)
runtime.oldstack+0xa6 /home/rsc/g/go/src/pkg/runtime/proc.c:705
       runtime.oldstack()
runtime.lessstack+0x22 /home/rsc/g/go/src/pkg/runtime/amd64/asm.s:224
       runtime.lessstack()
----- lessstack called from goroutine 2 -----
runtime.lock+0x56 /home/rsc/g/go/src/pkg/runtime/linux/thread.c:158
       runtime.lock(0x5b0188, 0x40a5e2)
runtime.stackalloc+0x55 /home/rsc/g/go/src/pkg/runtime/malloc.c:316
       runtime.stackalloc(0x1000, 0x4055b0)
runtime.malg+0x3d /home/rsc/g/go/src/pkg/runtime/proc.c:803
       runtime.malg(0x1000, 0x40add9)
runtime.newproc1+0x12b /home/rsc/g/go/src/pkg/runtime/proc.c:854
       runtime.newproc1(0xf840027440, 0x7f0d27b49230, 0x0, 0x49f238, 0x40, ...)
runtime.newproc+0x2f /home/rsc/g/go/src/pkg/runtime/proc.c:831
       runtime.newproc(0x0, 0xf840027440, 0xf800000010, 0x44b059)
...

R=r, r2
CC=golang-dev
https://golang.org/cl/4216045