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

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

Permit paired parentheses in URLs such as:

http://en.wikipedia.org/wiki/Camellia_(cipher)

Fixes #5043.

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

Fixes #6836.

LGTM=rsc
R=golang-codereviews, rsc, r, mike
CC=golang-codereviews
https://golang.org/cl/33140043

Fixes #7614.

LGTM=rsc
R=golang-codereviews, r, rsc, dan.kortschak, applezinc
CC=golang-codereviews
https://golang.org/cl/79210044

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/85490043

Given
        type Outer struct {
                *Inner
                ...
        }
the compiler generates the implementation of (*Outer).M dispatching to
the embedded Inner. The implementation is logically:
        func (p *Outer) M() {
                (p.Inner).M()
        }
but since the only change here is the replacement of one pointer
receiver with another, the actual generated code overwrites the
original receiver with the p.Inner pointer and then jumps to the M
method expecting the *Inner receiver.

During reflect.Value.Call, we create an argument frame and the
associated data structures to describe it to the garbage collector,
populate the frame, call reflect.call to run a function call using
that frame, and then copy the results back out of the frame. The
reflect.call function does a memmove of the frame structure onto the
stack (to set up the inputs), runs the call, and the memmoves the
stack back to the frame structure (to preserve the outputs).

Originally reflect.call did not distinguish inputs from outputs: both
memmoves were for the full stack frame. However, in the case where the
called function was one of these wrappers, the rewritten receiver is
almost certainly a different type than the original receiver. This is
not a problem on the stack, where we use the program counter to
determine the type information and understand that during (*Outer).M
the receiver is an *Outer while during (*Inner).M the receiver in the
same memory word is now an *Inner. But in the statically typed
argument frame created by reflect, the receiver is always an *Outer.
Copying the modified receiver pointer off the stack into the frame
will store an *Inner there, and then if a garbage collection happens
to scan that argument frame before it is discarded, it will scan the
*Inner memory as if it were an *Outer. If the two have different
memory layouts, the collection will intepret the memory incorrectly.

Fix by only copying back the results.

Fixes #7725.

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

It turns out there is a relatively common pattern that relies on
inverted channel semaphore:

gate := make(chan bool, N)
for ... {
        // limit concurrency
        gate <- true
        go func() {
                foo(...)
                <-gate
        }()
}
// join all goroutines
for i := 0; i < N; i++ {
        gate <- true
}

So handle synchronization on inverted semaphores with cap>1.
Fixes #7718.

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

This code tests linkmode == LinkExternal but is only invoked
by the compiler/assembler, not the linker.

Update #7164

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

LGTM=bradfitz, alex.brainman
R=golang-codereviews, bradfitz, alex.brainman
CC=golang-codereviews
https://golang.org/cl/85190043

Defers generated from cgo lie to us about their argument layout.
Mark those defers as not copyable.

CL 83820043 contains an additional test for this code and should be
checked in (and enabled) after this change is in.

Fixes bug 7695.

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

Iterate the right number of times in arrays and channels.
Handle channels with zero-sized objects in them.
Output longer type names if we have them.
Compute argument offset correctly.

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

Also makes ErrWriteToConnected more appropriate; it's used
not only UDPConn operations but UnixConn operations.

Update #4856

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

The prefix was not uniformly applied and is probably better
left off for using with OpError.

Update #4856

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

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

Takes advantage of CL 83740044, to optimize map[string] lookup
from []byte key.

Deletes code.

No conditional check for gccgo, since Ian plans to add this
to gccgo before GCC 4.10 (Go 1.3).

benchmark                   old ns/op     new ns/op     delta
BenchmarkReadMIMEHeader     6066          5086          -16.16%

benchmark                   old allocs     new allocs     delta
BenchmarkReadMIMEHeader     12             12             +0.00%

benchmark                   old bytes     new bytes     delta
BenchmarkReadMIMEHeader     1317          1317          +0.00%

Update #3512

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

Superficial inconsistencies that trigger warnings in
Plan 9.  Small enough to be considered trivial and
seemingly benign outside of the Plan 9 environment.

LGTM=iant
R=golang-codereviews, 0intro, iant
CC=golang-codereviews
https://golang.org/cl/73460043

If an error happens on a connection, server goroutine can call b.Logf
after benchmark finishes.
So join both client and server goroutines.
Update #7718

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

Generated by addca.

R=gobot
CC=golang-codereviews
https://golang.org/cl/84710045

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

TBR=khr
CC=golang-codereviews
https://golang.org/cl/84570045

Fixes #7171

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

Fixes #7547

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

I have no idea what this code is for, but it pretty
clearly needs to be uint64, not uint32.

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

Fixes #7214

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

Native Client forbids jumps/calls to arbitrary locations and
enforces a particular alignement, which makes the Duff's device
ineffective.

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

LGTM=mikioh.mikioh
R=golang-codereviews, mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/84340043

Update #7362
Fixes #7377
Fixes #7570

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

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

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

Trying to make GODEBUG=gcdead=1 work with liveness
and in particular ambiguously live variables.

1. In the liveness computation, mark all ambiguously live
variables as live for the entire function, except the entry.
They are zeroed directly after entry, and we need them not
to be poisoned thereafter.

2. In the liveness computation, compute liveness (and deadness)
for all parameters, not just pointer-containing parameters.
Otherwise gcdead poisons untracked scalar parameters and results.

3. Fix liveness debugging print for -live=2 to use correct bitmaps.
(Was not updated for compaction during compaction CL.)

4. Correct varkill during map literal initialization.
Was killing the map itself instead of the inserted value temp.

5. Disable aggressive varkill cleanup for call arguments if
the call appears in a defer or go statement.

6. In the garbage collector, avoid bug scanning empty
strings. An empty string is two zeros. The multiword
code only looked at the first zero and then interpreted
the next two bits in the bitmap as an ordinary word bitmap.
For a string the bits are 11 00, so if a live string was zero
length with a 0 base pointer, the poisoning code treated
the length as an ordinary word with code 00, meaning it
needed poisoning, turning the string into a poison-length
string with base pointer 0. By the same logic I believe that
a live nil slice (bits 11 01 00) will have its cap poisoned.
Always scan full multiword struct.

7. In the runtime, treat both poison words (PoisonGC and
PoisonStack) as invalid pointers that warrant crashes.

Manual testing as follows:

- Create a script called gcdead on your PATH containing:

        #!/bin/bash
        GODEBUG=gcdead=1 GOGC=10 GOTRACEBACK=2 exec "$@"
- Now you can build a test and then run 'gcdead ./foo.test'.
- More importantly, you can run 'go test -short -exec gcdead std'
   to run all the tests.

Fixes #7676.

While here, enable the precise scanning of slices, since that was
disabled due to bugs like these. That now works, both with and
without gcdead.

Fixes #7549.

LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/83410044

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

runtime.Version() requires a trailing "+" when
tree had local modifications at time of build.

Fixes #7701

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

The garbage collector poison pointers
(0x6969696969696969 and 0x6868686868686868)
are malformed addresses on amd64.
That is, they are not 48-bit addresses sign extended
to 64 bits. This causes a different kind of hardware fault
than the usual 'unmapped page' when accessing such
an address, and OS X 10.9.2 sends the resulting SIGSEGV
incorrectly, making it look like it was user-generated
rather than kernel-generated and does not include the
faulting address. This means that in GODEBUG=gcdead=1
mode, if there is a bug and something tries to dereference
a poisoned pointer, the runtime delivers the SIGSEGV to
os/signal and returns to the faulting code, which faults
again, causing the process to hang instead of crashing.

Fix by rewriting "user-generated" SIGSEGV on OS X to
look like a kernel-generated SIGSEGV with fault address
0xb01dfacedebac1e.

I chose that address because (1) when printed in hex
during a crash, it is obviously spelling out English text,
(2) there are no current Google hits for that pointer,
which will make its origin easy to find once this CL
is indexed, and (3) it is not an altogether inaccurate
description of the situation.

Add a test. Maybe other systems will break too.

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

Delaying the runtime.throw until here will print more information.
In particular it will print the signal and code values, which means
it will show the fault address.

The canpanic checks were added recently, in CL 75320043.
They were just not added in exactly the right place.

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

Brad has been asking for this for a while.
I have resisted because I wanted to find a more general way to
do this, one that would keep the performance of code introducing
variables the same as the performance of code that did not.
(See golang.org/issue/3512#c20).

I have not found the more general way, and recent changes to
remove ambiguously live temporaries have blown away the
property I was trying to preserve, so that's no longer a reason
not to make the change.

Fixes #3512.

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

Fixes #7476.

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

Fixes #7385.

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

Cuts hello world by 70kB, because we don't write
those names into the symbol table.

Update #6853

LGTM=khr
R=khr
CC=golang-codereviews
https://golang.org/cl/80370045

Fixes #6769.

LGTM=bradfitz
R=bgarcia, rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/84220044