Was just a missing case (literally) in the type checker.

Fixes #8473.

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

Fixes #8241.

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

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

Inspired by a remark by Leonard Holz, use constants for division

BenchmarkSprintfEmpty           130           132           +1.54%
BenchmarkSprintfString          438           437           -0.23%
BenchmarkSprintfInt             417           414           -0.72%
BenchmarkSprintfIntInt          663           691           +4.22%
BenchmarkSprintfPrefixedInt     791           774           -2.15%
BenchmarkSprintfFloat           701           686           -2.14%
BenchmarkManyArgs               2584          2469          -4.45%
BenchmarkFprintInt              488           357           -26.84%
BenchmarkFprintIntNoAlloc       402           265           -34.08%
BenchmarkScanInts               1244346       1267574       +1.87%
BenchmarkScanRecursiveInt       1748741       1724138       -1.41%

Update #3463

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

Previously, signed and unsigned integers could not be compared, but
this has problems with things like comparing 'x' with a byte in a string.
Since signed and unsigned integers have a well-defined ordering,
even though their types are different, and since we already allow
comparison regardless of the size of the integers, why not allow it
regardless of the sign?

Integers only, a fine place to draw the line.

Fixes #7489.

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

LGTM=bradfitz
R=golang-codereviews, bradfitz, mattn.jp
CC=golang-codereviews
https://golang.org/cl/131650043

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

palette.

Fixes #7993.

LGTM=r
R=r
CC=golang-codereviews, james.jdunne
https://golang.org/cl/138600043

Saw this on a test:

runtime: bad pointer in frame runtime_test.testSetPanicOnFault at 0xc20801c6b0: 0xfff
fatal error: bad pointer!

runtime stack:
...
copystack(0xc2081bf7a0, 0x1000)
        /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/stack.c:621 +0x173 fp=0xfffffd7ffd5ffee0 sp=0xfffffd7ffd5ffe20
runtime.newstack()
        /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/stack.c:774 +0x552 fp=0xfffffd7ffd5fff90 sp=0xfffffd7ffd5ffee0
runtime.morestack()
        /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/asm_amd64.s:324 +0x90 fp=0xfffffd7ffd5fff98 sp=0xfffffd7ffd5fff90

goroutine 163354 [stack growth]:
...
runtime.convT2E(0x587000, 0xc20807bea8, 0x0, 0x0)
        /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/iface.go:141 +0xd2 fp=0xc20801c678 sp=0xc20801c640
runtime_test.testSetPanicOnFault(0xc20822c510, 0xfff, 0xc20801c748)
        /root/work/solaris-amd64-smartos-2dde8b453d26/go/src/runtime/runtime_test.go:211 +0xc6 fp=0xc20801c718 sp=0xc20801c678
...

This test is testing bad pointers.  It loads the bad pointer into a pointer variable,
but before it gets a chance to dereference it, calls convT2E.  That call causes a stack copy,
which exposes that live but bad pointer variable.

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

When running defers, we must check whether the defer
has already been marked as started so we don't run it twice.

Fixes #8774.

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

The proposed text in the last CL had a comma that was missing from the submitted spec.

LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/150720043

Fixes #8107.

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

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

Fixes #8594.

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

Pure renaming. This will make an upcoming CL have smaller diffs.

LGTM=dvyukov, iant
R=iant, dvyukov
CC=golang-codereviews
https://golang.org/cl/142280043

Fixes #8202.

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

Fixes #8755.

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

CL 144940043 renamed it from Sched to SchedType
to avoid a lowercasing conflict in the Go code with
the variable named sched.
We've been using just T resolve those conflicts, not Type.

The FooType pattern is already taken for the kind-specific
variants of the runtime Type structure: ChanType, MapType,
and so on. SchedType isn't a Type.

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

Fixes #6163.

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

Fixes #8517.

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

Update #8690

If liblink determines that the host doesn't support TLS it replaces the MRC call with a BL runtime.tls_read_fallback. The problem is save_g doesn't expect anyone to make any BL calls and hasn't setup its own link register properly so when runtime.tls_read_fallback returns the LR points to save_g, not save_g's caller so the RET at the end of the function turns into an infinite loop.

This fix is only a proof of concept, I think the real fix should go into liblink as its MRC substitution is not as transparent as expected.

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

Fixes #8008.

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

We can't assume all those addresses are unmapped.
But at least one should be.

What we're really testing is that the program doesn't crash.

Fixes #8542.

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

We mark DBG_PRINTEXCEPTION_C messages in VEH handler
as handled, thus preventing debugger from seeing them.
I don't see reason for doing that. The comment warns
of crashes, but I added test and don't see any crashes.

This is also simplify VEH handler before making
changes to fix issue 8006.

Update #8006

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

Fixes #7859.

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

It fixes the TestRemoveAllRace test introduced
in CL 145860043.

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

This is to simplify VEH handler before making
changes to fix issue 8006.

Update #8006

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

Same fix as for SysUnused.
Fixes #8038.

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

The current Windows build failure happens because by
default runtime frames are excluded from stack traces.
Apparently the Windows breakpoint path dies with an
ordinary panic, while the Unix path dies with a throw.
Breakpoint is a strange function and I don't mind that it's
a little different on the two operating systems.

The panic squelches runtime frames but the throw shows them,
because throw is considered something that shouldn't have
happened at all, so as much detail as possible is wanted.

The runtime exclusion is meant to prevents printing too much noise
about internal runtime details. But exported functions are
not internal details, so show exported functions.
If the program dies because you called runtime.Breakpoint,
it's okay to see that frame.
This makes the Breakpoint test show Breakpoint in the
stack trace no matter how it is handled.

Should fix Windows build.
Tested on Unix by changing Breakpoint to fault instead
of doing a breakpoint.

TBR=brainman
CC=golang-codereviews
https://golang.org/cl/143300043

This fixes a couple of problems that occur when the linker
removes its temporary directory on Windows.  The linker only
creates and removes a temporary directory when doing external
linking.  Windows does not yet support external linking.
Therefore, these problems are only seen when using a
cross-compiler hosted on Windows.

In lib9, FindFirstFileW returns just the file name, not the
full path name.  Don't assume that we will find a slash.
Changed the code to work either way just in case.

In ld, Windows requires that files be closed before they are
removed, so close the output file before we might try to
remove it.

Fixes #8723.

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

It's just fundamentally incompatible with
Windows' pickiness about removing things
that are in use.

TBR=brainman
CC=golang-codereviews
https://golang.org/cl/142270043

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

Fixes #8738.

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

Fixes #8332.

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

Fixes #5397.

LGTM=adg
R=gri, adg
CC=golang-codereviews, rsc
https://golang.org/cl/144110044

Since CL 130990043, the GOTRACEBACK variable is
only used when the GODEBUG variable is set.
This change restores the original behavior.

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

In Go 1.3 the runtime called panicstring to report errors like
divide by zero or memory faults. Now we call panic (gopanic)
with pre-allocated error values. That new path is missing the
checking that panicstring did, so add it there.

The only call to panicstring left is in cnew, which is problematic
because if it fails, probably the heap is corrupt. In that case,
calling panicstring creates a new errorCString (no allocation there),
but then panic tries to print it, invoking errorCString.Error, which
does a string concatenation (allocating), which then dies.
Replace that one panicstring with a throw: cnew is for allocating
runtime data structures and should never ask for an inappropriate
amount of memory.

With panicstring gone, delete newErrorCString, errorCString.
While we're here, delete newErrorString, not called by anyone.
(It can't be: that would be C code calling Go code that might
block or grow the stack.)

Found while debugging a malloc corruption.
This resulted in 'panic during panic' instead of a more useful message.

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

Fixes #7776.

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

It fails about 25% of the time on OS X.
I don't know what it's trying to do.
Created issue 8764 to correct this, but for now disable.

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

Replace typeLock with copy-on-write map using atomic.Value.

benchmark                               old ns/op     new ns/op     delta
BenchmarkEndToEndPipe                   7722          7709          -0.17%
BenchmarkEndToEndPipe-2                 5114          4344          -15.06%
BenchmarkEndToEndPipe-4                 3192          2429          -23.90%
BenchmarkEndToEndPipe-8                 1833          1438          -21.55%
BenchmarkEndToEndPipe-16                1332          983           -26.20%
BenchmarkEndToEndPipe-32                1444          675           -53.25%
BenchmarkEndToEndByteBuffer             6474          6019          -7.03%
BenchmarkEndToEndByteBuffer-2           4280          2810          -34.35%
BenchmarkEndToEndByteBuffer-4           2264          1774          -21.64%
BenchmarkEndToEndByteBuffer-8           1275          979           -23.22%
BenchmarkEndToEndByteBuffer-16          1257          753           -40.10%
BenchmarkEndToEndByteBuffer-32          1342          644           -52.01%
BenchmarkEndToEndArrayByteBuffer        727725        671349        -7.75%
BenchmarkEndToEndArrayByteBuffer-2      394079        320473        -18.68%
BenchmarkEndToEndArrayByteBuffer-4      211785        178175        -15.87%
BenchmarkEndToEndArrayByteBuffer-8      141003        118857        -15.71%
BenchmarkEndToEndArrayByteBuffer-16     139249        86367         -37.98%
BenchmarkEndToEndArrayByteBuffer-32     144128        73454         -49.04%

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