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

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