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

A terminal panic (one that prints a stack trace and exits)
has been calling runtime.breakpoint before calling exit,
so that if running under a debugger, the debugger can
take control.  When not running under a debugger, though,
this causes an additional SIGTRAP on Unix and pop-up
dialogs on Windows.

Support for debugging Go programs has gotten good
enough that we can rely on the debugger to set its own
breakpoint on runtime.exit if it wants to look around.

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

Much yet to come, but this is a safe first step, introducing
an in-the-future configurable Client object (where policy for
cookies, auth, redirects will live) as well as introducing a
ClientTransport interface for sending requests.

The CL intentionally ignores everything around the creation
and configuration of Clients and merely ports/wraps the old
interfaces to/around Client/ClientTransport.

R=rsc, dsymonds, nigeltao, bradfitzwork
CC=golang-dev
https://golang.org/cl/4182086

The existing code assumed that signals only arrived
while executing on the goroutine stack (g == m->curg),
not while executing on the scheduler stack (g == m->g0).

Most of the signal handling trampolines correctly saved
and restored g already, but the sighandler C code did not
have access to it.

Some rewriting of assembly to make the various
implementations as similar as possible.

Will need to change Windows too but I don't
understand how sigtramp gets called there.

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

With this change, a panic trace due to a signal arriving while
running on the scheduler stack during a lessstack
(a stack unsplit) will trace through the lessstack to show
the state of the goroutine that was unsplitting its stack.

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

same as in issue below, never fixed on ARM

changeset:   5498:3fa1372ca694
user:        Ken Thompson <ken@golang.org>
date:        Thu May 20 17:31:28 2010 -0700

description:
fix issue 798
cannot allocate an audomatic temp
while real registers are allocated.
there is a chance that the automatic
will be allocated to one of the
allocated registers. the fix is to
not registerize such variables.

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

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

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

There are further changes required for things like
recursive map types.  Recursive struct types work
but the mechanism needs generalization.  The
case handled in this CL is pathological since it
cannot be represented at all by gob, so it should
be handled separately. (Prior to this CL, encode
would recur forever.)

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

(Once again, proving that a fuzz tester is the first thing that I
should try.)

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

Avoid passing the placeholder diff to hgpatch, so that
clpatch-ing an empty diff grabs the metadata and warns
about it being empty, rather than failing with a
hard-to-debug problem ("mkdir: no such file or dir",
no metadata, etc).

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

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

This code implements bzip2 decompression only.

R=bradfitzgo, r2, nigeltao, rsc
CC=golang-dev
https://golang.org/cl/4176051

R=rsc
CC=bsiegert, golang-dev, mpl
https://golang.org/cl/4182081

textproto: introduce Header type
websocket: use new interface to access Header

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

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

This is a fix for the overly aggressive CL 4173075.
Ran all tests.

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

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

Thanks to rsc for the suggestion.

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

There are some minor irregularities in the printer
output (some paren's are present that should be
removed), but these are unrelated issues.
Will review in a 2nd step.

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

Changes on laptop were not sync'ed to machine
where I ran hg submit.

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

As a result, parsing a "control clause" is now sufficiently
different for if, switch, and for statements that the code
is not factored out anymore. The code is a bit longer but
clearer in each individual case.

Reflect the changes in AST.

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

Plus a few minor HTML fixes.

Fixes #1535.

R=r, rsc, ken2, iant, r2
CC=golang-dev
https://golang.org/cl/4185065

R=ken2, r2
CC=golang-dev
https://golang.org/cl/4195045

Deleted test/ken/robif.go because test/if.go is
the same program modulo formatting.

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

Fix problems found.

On amd64, various library routines had bigger
stack frames than expected, because large function
calls had been added.

runtime.assertI2T: nosplit stack overflow
        120	assumed on entry to runtime.assertI2T
        8	after runtime.assertI2T uses 112
        0	on entry to runtime.newTypeAssertionError
        -8	on entry to runtime.morestack01

runtime.assertE2E: nosplit stack overflow
        120	assumed on entry to runtime.assertE2E
        16	after runtime.assertE2E uses 104
        8	on entry to runtime.panic
        0	on entry to runtime.morestack16
        -8	after runtime.morestack16 uses 8

runtime.assertE2T: nosplit stack overflow
        120	assumed on entry to runtime.assertE2T
        16	after runtime.assertE2T uses 104
        8	on entry to runtime.panic
        0	on entry to runtime.morestack16
        -8	after runtime.morestack16 uses 8

runtime.newselect: nosplit stack overflow
        120	assumed on entry to runtime.newselect
        56	after runtime.newselect uses 64
        48	on entry to runtime.printf
        8	after runtime.printf uses 40
        0	on entry to vprintf
        -8	on entry to runtime.morestack16

runtime.selectdefault: nosplit stack overflow
        120	assumed on entry to runtime.selectdefault
        56	after runtime.selectdefault uses 64
        48	on entry to runtime.printf
        8	after runtime.printf uses 40
        0	on entry to vprintf
        -8	on entry to runtime.morestack16

runtime.selectgo: nosplit stack overflow
        120	assumed on entry to runtime.selectgo
        0	after runtime.selectgo uses 120
        -8	on entry to runtime.gosched

On arm, 5c was tagging functions NOSPLIT that should
not have been, like the recursive function printpanics:

printpanics: nosplit stack overflow
        124	assumed on entry to printpanics
        112	after printpanics uses 12
        108	on entry to printpanics
        96	after printpanics uses 12
        92	on entry to printpanics
        80	after printpanics uses 12
        76	on entry to printpanics
        64	after printpanics uses 12
        60	on entry to printpanics
        48	after printpanics uses 12
        44	on entry to printpanics
        32	after printpanics uses 12
        28	on entry to printpanics
        16	after printpanics uses 12
        12	on entry to printpanics
        0	after printpanics uses 12
        -4	on entry to printpanics

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

Fixes #1465.

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

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

Other than maybe cleaning the code up a bit, this has
little practical effect for now, but lays the foundation
for remembering the method set of a type, which can
be expensive.

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

Fixes #1543.

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

It was observed that the interface was generic enough
that several other types implemented it too.

Fixes #1530.

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

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

Removed a redefinition of the request URL which is never used and
redundant checking of the return value from send().

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

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

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

Added support for reading images with grayscale + alpha and
for images with depth 1, 2 or 4.

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

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