TBR=brainman
CC=golang-dev
https://golang.org/cl/4237060

func init runs *after* var declarations

TBR=niemeyer
CC=golang-dev
https://golang.org/cl/4260055

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

This enables goinstall to handle .go and .c files (for cgo)
which are named after the following patterns:

    name_$(GOOS).*
    name_$(GOARCH).*
    name_$(GOOS)_$(GOARCH).*

Files with those names are only included if the $(GOOS) and
$(GOARCH) match the current system.

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

* Change use of m->g0 stack (aka scheduler stack).
* Provide runtime.mcall(f) to invoke f() on m->g0 stack.
* Replace scheduler loop entry with runtime.mcall(schedule).

Runtime.mcall eliminates the need for fake scheduler states that
exist just to run a bit of code on the m->g0 stack
(Grecovery, Gstackalloc).

The elimination of the scheduler as a loop that stops and
starts using gosave and gogo fixes a bad interaction with the
way cgo uses the m->g0 stack.  Cgo runs external (gcc-compiled)
C functions on that stack, and then when calling back into Go,
it sets m->g0->sched.sp below the added call frames, so that
other uses of m->g0's stack will not interfere with those frames.
Unfortunately, gogo (longjmp) back to the scheduler loop at
this point would end up running scheduler with the lower
sp, which no longer points at a valid stack frame for
a call to scheduler.  If scheduler then wrote any function call
arguments or local variables to where it expected the stack
frame to be, it would overwrite other data on the stack.
I realized this possibility while debugging a problem with
calling complex Go code in a Go -> C -> Go cgo callback.
This wasn't the bug I was looking for, it turns out, but I believe
it is a real bug nonetheless.  Switching to runtime.mcall, which
only adds new frames to the stack and never jumps into
functions running in existing ones, fixes this bug.

* Move cgo-related code out of proc.c into cgocall.c.
* Add very large comment describing cgo call sequences.
* Simpilify, regularize cgo function implementations and names.
* Add test suite as misc/cgo/test.

Now the Go -> C path calls cgocall, which calls asmcgocall,
and the C -> Go path calls cgocallback, which calls cgocallbackg.

The shuffling, which affects mainly the callback case, moves
most of the callback implementation to cgocallback running
on the m->curg stack (not the m->g0 scheduler stack) and
only while accounted for with $GOMAXPROCS (between calls
to exitsyscall and entersyscall).

The previous callback code did not block in startcgocallback's
approximation to exitsyscall, so if, say, the garbage collector
were running, it would still barge in and start doing things
like call malloc.  Similarly endcgocallback's approximation of
entersyscall did not call matchmg to kick off new OS threads
when necessary, which caused the bug in issue 1560.

Fixes #1560.

R=iant
CC=golang-dev
https://golang.org/cl/4253054

No known bugs in the current pipe,
but this one is simpler and easier to
understand.

R=iant
CC=golang-dev
https://golang.org/cl/4252057

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

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

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

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

R=adg, rsc
CC=Joe Poirier, golang-dev
https://golang.org/cl/4257052

R=bradfitzgo, dsymonds
CC=golang-dev
https://golang.org/cl/4244053

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

The Hijack functionality wasn't removed, but now you have
to test if your ResponseWriter is also a Hijacker:

func ServeHTTP(rw http.ResponseWriter, req *http.Request) {
    if hj, ok := rw.(http.Hijacker); ok {
        hj.Hijack(..)
    }
}

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

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

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

R=niemeyer
CC=golang-dev
https://golang.org/cl/4256057

R=golang-dev, rsc1
CC=golang-dev
https://golang.org/cl/4235054

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

The recursive algorithm used to parse types in cgo
has a bug related to building the C type representation.

As an example, when the recursion starts at a type *T,
the C type representation won't be known until type T
itself is parsed.  But then, it is possible that type T
references the type **T internally.  The latter
representation is built based on the one of *T, which
started the recursion, so it won't attempt to parse it
again, and will instead use the current representation
value for *T, which is still empty at this point.

This problem was fixed by introducing a simple TypeRepr
type which builds the string representation lazily,
analogous to how the Go type information is built within
the same algorithm.  This way, even if a type
representation is still unknown at some level in the
recursion, representations dependant on it can still
be created correctly.

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

The path package now contains only functions which
deal with slashed paths, sensible for any OS when dealing
with network paths or URLs.  OS-specific functionality
has been moved into the new path/filepath package.

This also includes fixes for godoc, goinstall and other
packages which were mixing slashed and OS-specific paths.

R=rsc, gri, mattn, brainman
CC=golang-dev
https://golang.org/cl/4252044

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

Cgo changed to write these files into _obj, but some
trees may still have the old ones in the source directory.
They need to be removed during make clean so that
a subsequent build will use the ones in _obj.

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

R=rsc1, mattn, bradfitzwork, pascal, bradfitzgo
CC=golang-dev
https://golang.org/cl/4214042

FreeBSD's execve implementation has an integer underflow in a bounds test which
causes it to erroneously think the argument list is too long when argv[0] is
longer than interpreter + path.

R=rsc, bradfitz, rsc1
CC=golang-dev
https://golang.org/cl/4259056

also fix a caching bug.

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

R=bradfitzgo, bradfitzwork
CC=golang-dev
https://golang.org/cl/4264047

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

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

A change a while back stop sending data for unexported fields
but due to an oversight the type info was being sent also. It's
inconsequential but wrong to do that.

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

R=rh
CC=golang-dev
https://golang.org/cl/4239060

This also breaks fs_test into two parts
as the range tests test http's private httpRange
and I had to change the fs_test package from
"http" to "http_test" to use httptest which otherwise
has a cyclic depedency back on http.

Aside: we should start exposing the Range
stuff in the future.

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

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

R=rsc, bradfitzgo, bradfitzwork
CC=golang-dev
https://golang.org/cl/4266042

Fixes #53.

R=bradfitzgo, bradfitzwork
CC=golang-dev
https://golang.org/cl/4240075

The test was checking for a buffer to be empty but
actually racing with the background goroutine that
was emptying it.  Left a comment so that the check
is not reintroduced later.

Fixes #1557.

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

Passing a frame size of 1 was causing the cgo callback
to push 1 byte of arguments onto the stack, making
the stack pointer misaligned, which had the effect of
hiding all the pointers on the stack from the garbage
collector.

SWIG only wraps calls to C++ virtual methods, so it
always has at least 1 argument, so SWIG does not need
to be fixed too.

Fixes #1328.

R=iant
CC=golang-dev
https://golang.org/cl/4261046

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

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

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