Fixes #8607

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

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

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

This prevents the temporary directory from being leaked when
the linker is run on a FUSE filesystem.

Fixes #8684.

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

Fixes #8816

At least, I hope it does.

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

This fixes the bug in which the linker reports "missing Go
type information" when a -X option refers to a symbol that is
not used.

Fixes #8821.

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

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

The extra-clever code in Sincos is trying to do

        if v&2 == 0 {
                mask = 0xffffffffffffffff
        } else {
                mask = 0
        }

It does this by turning v&2 into a float64 X0 and then using

        MOVSD $0.0, X3
        CMPSD X0, X3, 0

That CMPSD is defined to behave like:

        if X0 == X3 {
                X3 = 0xffffffffffffffff
        } else {
                X3 = 0
        }

which gives the desired mask in X3. The goal in using the
CMPSD was to avoid a conditional branch.

This code fails when called from a PortAudio callback.
In particular, the failure behavior is exactly as if the
CMPSD always chose the 'true' execution.

Notice that the comparison X0 == X3 is comparing as
floating point values the 64-bit pattern v&2 and the actual
floating point value zero. The only possible values for v&2
are 0x0000000000000000 (floating point zero)
and 0x0000000000000002 (floating point 1e-323, a denormal).
If they are both comparing equal to zero, I conclude that
in a PortAudio callback (whatever that means), the processor
is running in "denormals are zero" mode.

I confirmed this by placing the processor into that mode
and running the test case in the bug; it produces the
incorrect output reported in the bug.

In general, if a Go program changes the floating point math
modes to something other than what Go expects, the math
library is not going to work exactly as intended, so we might
be justified in not fixing this at all.

However, it seems reasonable that the client code might
have expected "denormals are zero" mode to only affect
actual processing of denormals. This code has produced
what is in effect a gratuitous denormal by being extra clever.
There is nothing about the computation being requested
that fundamentally requires a denormal.

It is also easy to do this computation in integer math instead:

        mask = ((v&2)>>1)-1

Do that.

For the record, the other math tests that fail if you put the
processor in "denormals are zero" mode are the tests for
Frexp, Ilogb, Ldexp, Logb, Log2, and FloatMinMax, but all
fail processing denormal inputs. Sincos was the only function
for which that mode causes incorrect behavior on non-denormal inputs.

The existing tests check that the new assembly is correct.
There is no test for behavior in "denormals are zero" mode,
because I don't want to add assembly to change that.

Fixes #8623.

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

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

go test's handling of _test.go files when the entire
package's set of files has no Test functions has varied
over the past few releases. There are a few interesting
cases (all contain no Test functions):
        (1) x_test.go has syntax errors
        (2) x_test.go has type errors
        (3) x_test.go has runtime errors (say, a func init that panics)

In Go 1.1, tests with (1) or (2) failed; (3) passed.
In Go 1.2, tests with (1) or (2) failed; (3) passed.
In Go 1.3, tests with (1) failed; (2) or (3) passed.
After this CL, tests with (1), (2), or (3) all fail.

This is clearly a corner case, but it seems to me that
the behavior of the test should not change if you
add or remove a line like

        func TestAlwaysPasses(t *testing.T) {}

That implies that the _test.go files must always
be built and always be imported into the test binary.
Doing so means that (1), (2), and (3) must all fail.

Fixes #8337.

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

From issue 7967 I learned:

1) yacc accepts either 'x' or "x" to mean token value 0x78
2) yacc also accepts 'xyz' and "XYZ" to mean token value 0x78

Use strconv.Unquote to simplify the handling of quoted
strings and check that each has only one rune.

Although this does clean things up, it makes 'x' and "x"
treated as different internally (now they are stored as
`'x'` and `"x"`; before they were both ` x`). Grammars that
use both interchangeably will now die with an error
similar to the one from issue 7967:

        yacc bug -- cannot have 2 different Ts with same value
                "+" and '+'

The echoing of the quotes should make clear what is going on.

The other semantic change caused by using strconv.Unquote
is that '\"' and "\'" are no longer valid. Like in Go, they must be
spelled without the backslash: '"' and "'".

On the other hand, now yacc and Go agree about what character
and string literals mean.

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

Fixes #7779.

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

The one line that you can't test easily was broken.
This manifested as a failure of a pre-existing test
in test.bash but I didn't notice it (there are a few other
long-standing failures that need to be fixed).

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

Today, 'go build -a my/pkg' and 'go install -a my/pkg'
recompile not just my/pkg and all its dependencies that
you wrote but also the standard library packages.
Recompiling the standard library is problematic on
some systems because the installed copy is not writable.

The -a behavior means that you can't use 'go install -a all'
or 'go install -a my/...' to rebuild everything after a Go
release - the rebuild stops early when it cannot overwrite
the installed standard library.

During development work, however, you do want install -a
to rebuild everything, because anything might have changed.

Resolve the conflict by making the behavior of -a depend
on whether we are using a released copy of Go or a devel copy.
In the release copies, -a no longer applies to the standard library.
In the devel copies, it still does.

This is the latest in a long line of refinements to the
"do I build this or not" logic. It is surely not the last.

Fixes #8290.

LGTM=r
R=golang-codereviews, r, tracey.brendan
CC=adg, golang-codereviews, iant
https://golang.org/cl/151730045

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

Fixes #8130.

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

This fixes the test/linkx.go test, which does not run by default.
(Issue 4139 is about fixing that.)

Fixes #8806.

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

Also rebuild doc.go; was stale, so contains extra changes.

Fixes #8677.

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

While we are here, remove undocumented, meaningless test -file flag.

Fixes #7724.

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

Fix by atom (from CL 89190044), comment and test by me.

Fixes #6823.

LGTM=crawshaw
R=golang-codereviews, crawshaw
CC=0xe2.0x9a.0x9b, adg, golang-codereviews, iant, r
https://golang.org/cl/148180043

If you say 'go get -v' you get extra information when import
paths are not of the expected form.

If you say 'go get -v src/rsc.io/pdf' the message says that
src/rsc.io/pdf does not contain a hostname, which is incorrect.
The problem is that it does not begin with a hostname.

Fixes #7432.

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

If you do 'go get -u rsc.io/pdf' and then rsc.io/pdf's redirect
changes to point somewhere else, after this CL a later
'go get -u rsc.io/pdf' will tell you that.

Fixes #8548.

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

The pattern was only working if the checkout had
already been done, but the code was trying to make
it work even the first time. Test and fix.

Fixes #8335.

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

LGTM=r
R=r, adg, rsc
https://golang.org/cl/148080043

LGTM=r
R=r, rsc, iant, agl
https://golang.org/cl/142650045

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

I'd rather delete the file but I doubt that will be popular.

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

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

Fixes #8084.

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

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

Fixes #8242.

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

Fixes #7834.

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

Fixes #7886.

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

Fixes #8672.

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

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

Fixes #7200.

LGTM=gri, iant
R=golang-codereviews, gri, iant
CC=golang-codereviews, r
https://golang.org/cl/150020044

Fixes #8311.

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

Fixes #8507.

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

Need to restore the g register.  Somehow this line vaporized from
CL 144130043.  Also cgo_topofstack -> _cgo_topofstack, that vaporized also.

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

During a cgo call, the stack can be copied.  This copy invalidates
the pointer that cgo has into the return value area.  To fix this
problem, pass the address of the location containing the stack
top value (which is in the G struct).  For cgo functions which
return values, read the stktop before and after the cgo call to
compute the adjustment necessary to write the return value.

Fixes #8771

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