go/build: build $GOOS_test.go always

We decided to build $GOOS.go always
but forgot to test $GOOS_test.go.

Fixes issue 9159.

LGTM=r
R=r
CC=golang-codereviews
https://codereview.appspot.com/176290043
doc: tidy up "Projects" page; add Go 1.4

LGTM=r
R=r
CC=golang-codereviews
https://codereview.appspot.com/182750043
reflect: Fix reflect.funcLayout.  The GC bitmap has two bits per
pointer, not one.

Fixes issue 9179

LGTM=iant, rsc
R=golang-codereviews, iant, rsc
CC=golang-codereviews
https://codereview.appspot.com/182160043
runtime: fix hang in GC due to shrinkstack vs netpoll race

During garbage collection, after scanning a stack, we think about
shrinking it to reclaim some memory. The shrinking code (called
while the world is stopped) checked that the status was Gwaiting
or Grunnable and then changed the state to Gcopystack, to essentially
lock the stack so that no other GC thread is scanning it.
The same locking happens for stack growth (and is more necessary there).

        oldstatus = runtime?readgstatus(gp);
        oldstatus &= ~Gscan;
        if(oldstatus == Gwaiting || oldstatus == Grunnable)
                runtime?casgstatus(gp, oldstatus, Gcopystack); // oldstatus is Gwaiting or Grunnable
        else
                runtime?throw("copystack: bad status, not Gwaiting or Grunnable");

Unfortunately, "stop the world" doesn't stop everything. It stops all
normal goroutine execution, but the network polling thread is still
blocked in epoll and may wake up. If it does, and it chooses a goroutine
to mark runnable, and that goroutine is the one whose stack is shrinking,
then it can happen that between readgstatus and casgstatus, the status
changes from Gwaiting to Grunnable.

casgstatus assumes that if the status is not what is expected, it is a
transient change (like from Gwaiting to Gscanwaiting and back, or like
from Gwaiting to Gcopystack and back), and it loops until the status
has been restored to the expected value. In this case, the status has
changed semi-permanently from Gwaiting to Grunnable - it won't
change again until the GC is done and the world can continue, but the
GC is waiting for the status to change back. This wedges the program.

To fix, call a special variant of casgstatus that accepts either Gwaiting
or Grunnable as valid statuses.

Without the fix bug with the extra check+throw in casgstatus, the
program below dies in a few seconds (2-10) with GOMAXPROCS=8
on a 2012 Retina MacBook Pro. With the fix, it runs for minutes
and minutes.

package main

import (
        "io"
        "log"
        "net"
        "runtime"
)

func main() {
        const N = 100
        for i := 0; i < N; i++ {
                l, err := net.Listen("tcp", "127.0.0.1:0")
                if err != nil {
                        log.Fatal(err)
                }
                ch := make(chan net.Conn, 1)
                go func() {
                        var err error
                        c1, err := net.Dial("tcp", l.Addr().String())
                        if err != nil {
                                log.Fatal(err)
                        }
                        ch <- c1
                }()
                c2, err := l.Accept()
                if err != nil {
                        log.Fatal(err)
                }
                c1 := <-ch
                l.Close()
                go netguy(c1, c2)
                go netguy(c2, c1)
                c1.Write(make([]byte, 100))
        }
        for {
                runtime.GC()
        }
}

func netguy(r, w net.Conn) {
        buf := make([]byte, 100)
        for {
                bigstack(1000)
                _, err := io.ReadFull(r, buf)
                if err != nil {
                        log.Fatal(err)
                }
                w.Write(buf)
        }
}

var g int

func bigstack(n int) {
        var buf [100]byte
        if n > 0 {
                bigstack(n - 1)
        }
        g = int(buf[0]) + int(buf[99])
}

Fixes issue 9186.

LGTM=rlh
R=austin, rlh
CC=dvyukov, golang-codereviews, iant, khr, r
https://codereview.appspot.com/179680043
tag go1.4rc2

LGTM=rsc
R=rsc
CC=golang-codereviews
https://codereview.appspot.com/178600043
cmd/go: regenerate doc.go

Move change from CL 170770043 to correct file and regenerate docs
for changes from CL 164120043.

LGTM=adg
R=golang-codereviews, adg, bradfitz
CC=golang-codereviews
https://codereview.appspot.com/183000043

Committer: Andrew Gerrand <adg@golang.org>
cmd/pprof: fix symbol resolution for remote profiles

Fixes issue 9199.

LGTM=iant
R=golang-codereviews, iant
CC=austin, golang-codereviews, minux
https://codereview.appspot.com/183080043
spec: add comment marker for consistency.

LGTM=r
R=gri, r
CC=golang-codereviews
https://codereview.appspot.com/185830043
lib/time: update to ICANN time zone database 2014j

Fixes issue 9189.

LGTM=dsymonds
R=golang-codereviews, dsymonds
CC=golang-codereviews
https://codereview.appspot.com/178660043
cmd/pprof/internal/commands: add command to open browser on windows

While we're at there, also add a message to prompt the user to install
Graphviz if "dot" command is not found.

Fixes issue 9178.

LGTM=adg, alex.brainman, cookieo9, rsc
R=rsc, adg, bradfitz, alex.brainman, cookieo9, smyrman
CC=golang-codereviews
https://codereview.appspot.com/180380043

Committer: Russ Cox <rsc@golang.org>
cmd/go: avoid use of bufio.Scanner in generate

Scanner can't handle stupid long lines and there are
reports of stupid long lines in production.

Note the issue isn't long "//go:generate" lines, but
any long line in any Go source file.

To be fair, if you're going to have a stupid long line
it's not a bad bet you'll want to run it through go
generate, because it's some embeddable asset that
has been machine generated. (One could ask why
that generation process didn't add a newline or two,
but we should cope anyway.)

Rewrite the file scanner in "go generate" so it can
handle arbitrarily long lines, and only stores in memory
those lines that start "//go:generate".

Also: Adjust the documentation to make clear that it
does not parse the file.

Fixes issue 9143.
Fixes issue 9196.

LGTM=rsc, dominik.honnef
R=rsc, cespare, minux, dominik.honnef
CC=golang-codereviews
https://codereview.appspot.com/182970043
cmd/go: fix build
The new semantics of split require the newline be present.
The test was stale.

LGTM=adg
R=golang-codereviews, adg
CC=golang-codereviews
https://codereview.appspot.com/182480043
[dev.cc] cmd/ld: finalize linkmode before determining whether to import runtime/cgo

Frankly, I don't understand how the current code could possibly work except
when every android program is using cgo. Discovered this while working on
the iOS port.

LGTM=crawshaw, rsc
R=rsc, crawshaw
CC=golang-codereviews
https://codereview.appspot.com/177470043
[dev.cc] liblink: don't patch jumps to jumps to symbols

When liblink sees something like

       JMP x
       ...
    x: JMP y

it rewrites the first jump to jump directly to y.  This is
fine if y is a resolved label.  However, it *also* does this
if y is a function symbol, but fails to carry over the
relocation that would later patch in that symbol's value.  As
a result, the original jump becomes either a self-jump (if
relative) or a jump to PC 0 (if absolute).

Fix this by disabling this optimization if the jump being
patched in is a jump to a symbol.

LGTM=minux
R=rsc, minux
CC=golang-codereviews
https://codereview.appspot.com/185890044
[dev.cc] all: merge default (8d42099cdc23) into dev.cc

TBR=austin
CC=golang-codereviews
https://codereview.appspot.com/178700044