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

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

LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/111970043

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

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

Broke build; missing deps_test change. Will re-send the original with the appropriate fix.

««« original CL description
net/rpc: use html/template to render html

Found using the vet check in CL 106370045.

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/101670044
»»»

TBR=r
CC=golang-codereviews
https://golang.org/cl/110880044

Found using the vet check in CL 106370045.

LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/101670044

The code generating the .debug_frame section emits pairs of "advance PC",
"set SP offset" pseudo-instructions. Before the fix, the PC advance comes
out before the SP setting, which means the emitted offset for a block is
actually the value at the end of the block, which is incorrect for the
block itself.

The easiest way to fix this problem is to emit the SP offset before the
PC advance.

One delicate point: the last instruction to come out is now an
"advance PC", which means that if there are padding intsructions after
the final RET, they will appear to have a non-zero offset. This is odd
but harmless because there is no legal way to have a PC in that range,
or to put it another way, if you get here the SP is certainly screwed up
so getting the wrong (virtual) frame pointer is the least of your worries.

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

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

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

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=golang-codereviews
https://golang.org/cl/109470044

LGTM=crawshaw, dave
R=golang-codereviews, crawshaw, dave
CC=golang-codereviews
https://golang.org/cl/104520044

Both stdout and stderr are sent to /dev/null in android
apps. Introducing fatalf allows android to implement its
own copy that sends fatal errors to __android_log_print.

LGTM=minux, dave
R=minux, dave
CC=golang-codereviews
https://golang.org/cl/108400045

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

It snuck into cl/106380043. Too many active clients.

LGTM=ruiu
R=golang-codereviews, ruiu
CC=golang-codereviews
https://golang.org/cl/110830045

Based on cl/69170045 by Elias Naur.

There are currently several schemes for acquiring a TLS
slot to save the g register. None of them appear to work
for android. The closest are linux and darwin.

Linux uses a linker TLS relocation. This is not supported
by the android linker.

Darwin uses a fixed offset, and calls pthread_key_create
until it gets the slot it wants. As the runtime loads
late in the android process lifecycle, after an
arbitrary number of other libraries, we cannot rely on
any particular slot being available.

So we call pthread_key_create, take the first slot we are
given, and put it in runtime.tlsg, which we turn into a
regular variable in cmd/ld.

Makes android/arm cgo binaries work.

LGTM=minux
R=elias.naur, minux, dave, josharian
CC=golang-codereviews
https://golang.org/cl/106380043

The code in GC that handles gp->gobuf.ctxt is wrong,
because it does not mark the ctxt object itself,
if just queues the ctxt object for scanning.
So the ctxt object can be collected as garbage.
However, Gobuf.ctxt is void*, so it's always marked and
scanned through G.

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

Currently it says:
--- PASS: TestDecrypt-2 (0.11s)
pem_decrypt_test.go:17: test 0. %!s(x509.PEMCipher=1)
--- PASS: TestEncrypt-2 (0.00s)
pem_decrypt_test.go:42: test 0. %!s(x509.PEMCipher=1)

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

runtime·usleep and runtime·osyield fall back to calling an
assembly wrapper for the libc functions in the absence of a m,
so they can be called in cgo callback context.

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

A temporary 512 bytes buffer is allocated for every call to
readHeader. This buffer isn't returned to the caller and it could
be reused to lower the number of memory allocations.

This CL improves it by using a pool and zeroing out the buffer before
putting it back into the pool.

benchmark                  old ns/op     new ns/op     delta
BenchmarkListFiles100k     545249903     538832687     -1.18%

benchmark                  old allocs    new allocs    delta
BenchmarkListFiles100k     2105167       2005692       -4.73%

benchmark                  old bytes     new bytes     delta
BenchmarkListFiles100k     105903472     54831527      -48.22%

This improvement is very important if your code has to deal with a lot
of tarballs which contain a lot of files.

LGTM=dsymonds
R=golang-codereviews, dave, dsymonds, bradfitz
CC=golang-codereviews
https://golang.org/cl/108240044

A temporary 512 bytes buffer is allocated for every call to
writeHeader. This buffer could be reused the lower the number
of memory allocations.

benchmark                   old ns/op     new ns/op     delta
BenchmarkWriteFiles100k     634622051     583810847     -8.01%

benchmark                   old allocs     new allocs     delta
BenchmarkWriteFiles100k     2701920        2602621        -3.68%

benchmark                   old bytes     new bytes     delta
BenchmarkWriteFiles100k     115383884     64349922      -44.23%

This change is very important if your code has to write a lot of
tarballs with a lot of files.

LGTM=dsymonds
R=golang-codereviews, dave, dsymonds
CC=golang-codereviews
https://golang.org/cl/107440043

Thanks to Cedric Staub for noting that a short session key would lead
to an out-of-bounds access when conditionally copying the too short
buffer over the random session key.

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

The main changes fall into a few patterns:

1. Replace #define with enum.

2. Add /*c2go */ comment giving effect of #define.
This is necessary for function-like #defines and
non-enum-able #defined constants.
(Not all compilers handle negative or large enums.)

3. Add extra braces in struct initializer.
(c2go does not implement the full rules.)

This is enough to let c2go typecheck the source tree.
There may be more changes once it is doing
other semantic analyses.

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

LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews
https://golang.org/cl/110330043

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

Generated by a+c.

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

Generated by a+c.

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

A TLS slot is reserved by _rt0_.*_plan9 as an automatic and
its address (which is static on Plan 9) is saved in the
global _privates symbol. The startup linkage now is exactly
like that from Plan 9 libc, and the way we access g is
exactly as if we'd have used privalloc(2).

Aside from making the code more standard, this change
drastically simplifies it, both for 386 and for amd64, and
makes the Plan 9 code in liblink common for both 386 and
amd64.

The amd64 runtime code was cleared of nxm assumptions, and
now runs on the standard Plan 9 kernel.

Note handling fixes will follow in a separate CL.

LGTM=rsc
R=golang-codereviews, rsc, bradfitz, dave
CC=0intro, ality, golang-codereviews, jas, minux.ma, mischief
https://golang.org/cl/101510049

We restored registers correctly in the usual case where the thread
is a Go-managed thread and called runtime·sighandler, but we
failed to do so when runtime·sigtramp was called on a cgo-created
thread. In that case, runtime·sigtramp called runtime·badsignal,
a Go function, and did not restore registers after it returned

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

On amd64, the real time is reduced from 176.76s to 140.26s.
On ARM, the real time is reduced from 921.61s to 726.30s.

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

As android and linux have significant overlap, and
because build tags are a poor way to represent an
OS target, this CL introduces an exception into
go/build: linux is treated as a synonym for android
when matching files.

http://golang.org/s/go14android
https://groups.google.com/forum/#!topic/golang-dev/P1ATVp1mun0

LGTM=rsc, minux
R=golang-codereviews, mikioh.mikioh, dave, aram, minux, gobot, rsc, aram.h, elias.naur, iant
CC=golang-codereviews, rsc
https://golang.org/cl/105270043

Move decAlloc calls a bit higher in the call tree.
Cleans code marginally, improves speed marginally.
The benchmarks are noisy but the median time from
20 consective 1-second runs improves by about 2%.

LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/105530043

3-index slices of the form s[:len(s):len(s)]
cannot be simplified to s[::len(s)].

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

TBR=rsc
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/111770043

Fixes #7631.

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

Generated by a+c.

R=gobot, rsc
CC=golang-codereviews
https://golang.org/cl/106340043

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

CC=golang-codereviews
https://golang.org/cl/101590043

We are not the right people to support editor plugins, and the profusion
of editors in this CL demonstrates the unreality of pretending to do so.
People are free to create and advertise their own repos with support.

For discussion: https://groups.google.com/forum/#!topic/golang-dev/SA7fD470FxU

LGTM=rminnich, kamil.kisiel, gri, rsc, dave, josharian, ruiu
R=golang-codereviews, rminnich, kamil.kisiel, gri, rsc, dominik.honnef, dave, josharian, ruiu, ajstarks
CC=golang-codereviews
https://golang.org/cl/105470043

There is no reason to generate different code for cap and len.

Fixes #8025.
Fixes #8026.

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