If the process exits before the spawned goroutine
completes, it'll miss the data race.

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

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

Camlistore uses this pattern to do streaming writes, as do
others I imagine, and it was broken by the lazy boundary
change.

LGTM=dvyukov, ruiu
R=ruiu, dvyukov
CC=golang-codereviews, mathieu.lonjaret
https://golang.org/cl/116690043

Breaks Camlistore by introducing a datarace. See comments on
https://golang.org/cl/95760043/ for details.

I'll add a new test to lock-in the current behavior in a
subsequent CL.

I don't think Camlistore is particularly unique here: it's doing
the obvious thing to stream a multipart body to a server
using a goroutine feeding the multipart writer.

««« original CL description
mime/multipart: delay reading random source

If a user sets his/her own boundary string with SetBoundary,
we don't need to call randomBoundary at all.

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

LGTM=ruiu
R=ruiu
CC=golang-codereviews, mathieu.lonjaret
https://golang.org/cl/117600043

Fixes #6736.

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

We have an autogenerated version in zruntime_defs.
I am not sure what are the consequences as gdb never printed any values for me.
But it looks unnecessary to manually duplicate it.

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

Technically a language change, this cleanup is a completely
backward compatible change that brings the boolean results
of comma-ok expressions in line with the boolean results of
comparisons: they are now all untyped booleans.

The implementation effort should be minimal (less than a
handfull lines of code, depending how well factored the
implementation of comma-ok expressions is).

Fixes #8189.

LGTM=iant, r, rsc
R=r, rsc, iant, ken
CC=golang-codereviews
https://golang.org/cl/112320045

Generated by a+c.

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

With the recent GC changes large objects are handled somewhat differently.

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

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

For consistency with other code, as that was the only use of
memcopy outside of alg.goc.

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

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

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

The gccgo version of USED only accepts a single variable, so
this simplifies merging.

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

The gccgo compiler used to fail this test.  This was the root
cause of http://gcc.gnu.org/PR61308 .  The fix for the gccgo
compiler is https://golang.org/cl/122020043 .

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

Popular tools both add incorrect trailing zeroes to the zip
extras, and popular tools accept trailing zeros. We seemed to
be the only ones being strict here. Stop being strict. :(

Fixes #8186

LGTM=ruiu, adg, dave
R=adg, ruiu, dave
CC=frohrweck, golang-codereviews
https://golang.org/cl/117550044

This CL removes sockaddrToAddr functions from socket creation
operations to avoid the bug like issue 7183.

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

Avoid some pressure on the global mutex by lifting the call to userType
out of the closure.
TOTH to Matt Harden.

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

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

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

A good cleanup anyway, and it makes some room for an additional
field needed for issue 8412.

Update #8412

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

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

6a and 8a rearrange memmove such that the fallthrough from move_1or2 to move_0 ends up being a JMP to a RET. Insert an explicit RET to prevent such silliness.

Do the same for memclr as prophylaxis.

benchmark                old ns/op     new ns/op     delta
BenchmarkMemmove1        4.59          4.13          -10.02%
BenchmarkMemmove2        4.58          4.13          -9.83%

LGTM=khr
R=golang-codereviews, dvyukov, minux, ruiu, bradfitz, khr
CC=golang-codereviews
https://golang.org/cl/120930043

Update #6007.

LGTM=minux, dvyukov
R=golang-codereviews, dvyukov, patrick, aram.h, minux
CC=golang-codereviews
https://golang.org/cl/108700045

TBR=dvyukov
CC=golang-codereviews
https://golang.org/cl/122740044

Create proper closures so hash functions can be called
directly from Go.  Rearrange calling convention so return
value is directly accessible.

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

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

Fixes #8297

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

int(maxMem) is negative on 32 bits.  Need to use
unsigned arithmetic.

TBR=bradfitz
CC=golang-codereviews
https://golang.org/cl/121000045

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

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

Cleanup from recent malloc changes.

LGTM=dvyukov
R=dvyukov
CC=golang-codereviews
https://golang.org/cl/120960043

Several reasons:
1. Significantly simplifies runtime.
2. This code proved to be buggy.
3. Free is incompatible with bump-the-pointer allocation.
4. We want to write runtime in Go, Go does not have free.
5. Too much code to free env strings on startup.

LGTM=khr
R=golang-codereviews, josharian, tracey.brendan, khr
CC=bradfitz, golang-codereviews, r, rlh, rsc
https://golang.org/cl/116390043

LGTM=dsymonds
R=dsymonds
CC=golang-codereviews
https://golang.org/cl/120980043

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

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

Stand-alone this test is fine.  Run together with
others, however, the stack used can actually go
negative because other tests are freeing stack
during its execution.

This behavior is new with the new stack allocator.
The old allocator never returned (min-sized) stacks.

This test is fairly poor - it needs to run in
isolation to be accurate.  Maybe we should delete it.

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

The DISPATCH and CALLFN macro definitions depend on an inconsistency
between the internal cpp mini-implementation and the language proper in
whether center-dot is an identifier character. The macro depends on it not
being an identifier character, but the resulting code depends on it being one.

Remove the dependence on the inconsistency by placing the center-dot into
the macro invocation rather that the body.

No semantic change. This is just renaming macro arguments.

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

machines and int64* on 64 bit machines.

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

This change introduces gomallocgc, a Go clone of mallocgc.
Only a few uses have been moved over, so there are still
lots of uses from C. Many of these C uses will be moved
over to Go (e.g. in slice.goc), but probably not all.
What should remain of C's mallocgc is an open question.

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