R=r, dfc, bradfitzwork, bradfitz
CC=golang-dev
https://golang.org/cl/4441078

R=agl, eds, rsc1, rsc
CC=golang-dev
https://golang.org/cl/4432079

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

R=bradfitz, agl1, rsc
CC=golang-dev
https://golang.org/cl/4435055

Fixes #1749.

R=bradfitz
CC=golang-dev
https://golang.org/cl/4431075

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

Also remove some left over copy & paste
in the test of reflect.Copy for arrays.

R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4431074

Fixes #1722.

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

R=golang-dev, bradfitz, dsymonds
CC=golang-dev
https://golang.org/cl/4426069

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

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

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

before & after:
adler32.BenchmarkGolden	  100000	     14747 ns/op
adler32.BenchmarkGolden	  200000	      8761 ns/op

Found by profiling PNG encoding.

R=rsc, bradfitzwork, eds
CC=golang-dev
https://golang.org/cl/4441073

This time for sure.

R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/4437078

Previously, whether declaring a type which copied the structure of a type it was referenced in via a pointer field would work depended on whether you declared it before or after the type it copied, e.g. type T2 T1; type T1 struct { F *T2 } would work, however type T1 struct { F *T2 }; type T2 T1 wouldn't.

Fixes #667.

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

The g->sched.sp saved stack pointer and the
g->stackbase and g->stackguard stack bounds
can change even while "the world is stopped",
because a goroutine has to call functions (and
therefore might split its stack) when exiting a
system call to check whether the world is stopped
(and if so, wait until the world continues).

That means the garbage collector cannot access
those values safely (without a race) for goroutines
executing system calls.  Instead, save a consistent
triple in g->gcsp, g->gcstack, g->gcguard during
entersyscall and have the garbage collector refer
to those.

The old code was occasionally seeing (because of
the race) an sp and stk that did not correspond to
each other, so that stk - sp was not the number of
stack bytes following sp.  In that case, if sp < stk
then the call scanblock(sp, stk - sp) scanned too
many bytes (anything between the two pointers,
which pointed into different allocation blocks).
If sp > stk then stk - sp wrapped around.
On 32-bit, stk - sp is a uintptr (uint32) converted
to int64 in the call to scanblock, so a large (~4G)
but positive number.  Scanblock would try to scan
that many bytes and eventually fault accessing
unmapped memory.  On 64-bit, stk - sp is a uintptr (uint64)
promoted to int64 in the call to scanblock, so a negative
number.  Scanblock would not scan anything, possibly
causing in-use blocks to be freed.

In short, 32-bit platforms would have seen either
ineffective garbage collection or crashes during garbage
collection, while 64-bit platforms would have seen
either ineffective or incorrect garbage collection.
You can see the invalid arguments to scanblock in the
stack traces in issue 1620.

Fixes #1620.
Fixes #1746.

R=iant, r
CC=golang-dev
https://golang.org/cl/4437075

Fixes #1397.

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

runtime: memory allocated by OS not in usable range
runtime: out of memory: cannot allocate 1114112-byte block (2138832896 in use)
throw: out of memory

runtime.throw+0x40 /Users/rsc/g/go/src/pkg/runtime/runtime.c:102
        runtime.throw(0x1fffd, 0x101)
runtime.mallocgc+0x2af /Users/rsc/g/go/src/pkg/runtime/malloc.c:60
        runtime.mallocgc(0x100004, 0x0, 0x1, 0x1, 0xc093, ...)
runtime.mal+0x40 /Users/rsc/g/go/src/pkg/runtime/malloc.c:289
        runtime.mal(0x100004, 0x20bc4)
runtime.new+0x26 /Users/rsc/g/go/src/pkg/runtime/malloc.c:296
        runtime.new(0x100004, 0x8fe84000, 0x20bc4)
main.main+0x29 /Users/rsc/x.go:11
        main.main()
runtime.mainstart+0xf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:93
        runtime.mainstart()
runtime.goexit /Users/rsc/g/go/src/pkg/runtime/proc.c:178
        runtime.goexit()
----- goroutine created by -----
_rt0_386+0xbf /Users/rsc/g/go/src/pkg/runtime/386/asm.s:80

R=iant, r
CC=golang-dev
https://golang.org/cl/4444073

R=brad_danga_com, rsc, dfc, r, dchest, bradfitz
CC=golang-dev
https://golang.org/cl/4439075

This one didn't come up in previous greps.

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

This also removes an unnecessary allocation in
http/transfer.go

R=r, rsc1, r2, adg
CC=golang-dev
https://golang.org/cl/4426066

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

Fixes #1725

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

R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4438077

Add local URI path support, which isn't as fringe
as I originally thought. (it's supported by Apache)

Send an implicit 302 status on redirects (not 200).

Fixes #1597

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

In a GOROOT path a backslash is a path separator
not an escape character. For example, `C:\go`.
Fixes gotest error:
version.go:3: unknown escape sequence: g

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

R=golang-dev, bradfitzgo, bradfitzwork, nigeltao, rog
CC=golang-dev
https://golang.org/cl/4271078

Fixes #1742.
I hope.

Also this picks up an update to go_tutorial.html that should already have happened.

R=brainman, rsc, peterGo
CC=golang-dev
https://golang.org/cl/4452050

R=dsymonds
CC=golang-dev
https://golang.org/cl/4436060

Fixes #1531.

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

For example, with GOPATH set like so
        GOPATH=/home/adg/gocode
And after creating some subdirectories
        mkdir /home/adg/gocode/{bin,pkg,src}

I can use goinstall to install the github.com/nf/goto web server,
which depends on the github.com/nf/stat package, with
        goinstall github.com/nf/goto

This downloads and installs all dependencies (that aren't already
installed) like so
        /home/adg/gocode/bin/goto
        /home/adg/gocode/pkg/darwin_amd64/github.com/nf/stat.a
        /home/adg/gocode/src/github.com/nf/goto/...
        /home/adg/gocode/src/github.com/nf/stat/...

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

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

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

Can make the API nicer in some cases.

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

No bugs found yet, though.

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

I ran the new verification code against a large number of certificates
with a huge (>1000) number of intermediates.

I had previously convinced myself that a cycle in the certificate
graph implied a cycle in the hash graph (and thus, a contradiction).
This is bogus because the signatures don't cover each other.

Secondly, I managed to drive the verification into a time explosion
with a fully connected graph of certificates. The code would try to
walk the factorial number of paths.

This change switches the CertPool to dealing with indexes of
certificates rather than pointers: this makes equality easy. (I didn't
want to compare pointers because a reasonable gc could move objects
around over time.)

Secondly, verification now memorizes the chains from a given
certificate. This is dynamic programming for the lazy, but there's a
solid reason behind it: dynamic programming would ignore the Issuer
hints that we can exploit by walking up the chain rather than down.

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

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

Used to fault trying to access l->list->next
when l->list == nil after MCentral_AllocList.
Now prints

runtime: out of memory: no room in arena for 65536-byte allocation (536870912 in use)
throw: out of memory

followed by stack trace.

Fixes #1650.

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

R=bradfitzgo, rsc, peterGo
CC=golang-dev
https://golang.org/cl/4441051

This change will allow to generate valid executable,
even if rsc disables dwarf generation, as it happend
at revision 9a64273f9d68.

R=rsc
CC=golang-dev, lvd, vcc
https://golang.org/cl/4425066