Apparently, the Windows routines sometimes fail to generate output.
Copy the Unix stdio-based implementations instead.

Suggested by Pietro Gagliardi in CL 65280043 but that CL
seems to have been abandoned.

Fixes #7242.

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

Fixes #5793.

LGTM=rsc
R=rsc, adonovan, dave
CC=golang-codereviews
https://golang.org/cl/13367051

Update #6882.

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

32-bit Windows uses "structured exception handling" (SEH) to
handle hardware faults: that there is a per-thread linked list
of fault handlers maintained in user space instead of
something like Unix's signal handlers. The structures in the
linked list are required to live on the OS stack, and the
usual discipline is that the function that pushes a record
(allocated from the current stack frame) onto the list pops
that record before returning. Not to pop the entry before
returning creates a dangling pointer error: the list head
points to a stack frame that no longer exists.

Go pushes an SEH record in the top frame of every OS thread,
and that record suffices for all Go execution on that thread,
at least until cgo gets involved.

If we call into C using cgo, that called C code may push its
own SEH records, but by the convention it must pop them before
returning back to the Go code. We assume it does, and that's
fine.

If the C code calls back into Go, we want the Go SEH handler
to become active again, not whatever C has set up. So
runtime.callbackasm1, which handles a call from C back into
Go, pushes a new SEH record before calling the Go code and
pops it when the Go code returns. That's also fine.

It can happen that when Go calls C calls Go like this, the
inner Go code panics. We allow a defer in the outer Go to
recover the panic, effectively wiping not only the inner Go
frames but also the C calls. This sequence was not popping the
SEH stack up to what it was before the cgo calls, so it was
creating the dangling pointer warned about above. When
eventually the m stack was used enough to overwrite the
dangling SEH records, the SEH chain was lost, and any future
panic would not end up in Go's handler.

The bug in TestCallbackPanic and friends was thus creating a
situation where TestSetPanicOnFault - which causes a hardware
fault - would not find the Go fault handler and instead crash
the binary.

Add checks to TestCallbackPanicLocked to diagnose the mistake
in that test instead of leaving a bad state for another test
case to stumble over.

Fix bug by restoring SEH chain during deferred "endcgo"
cleanup.

This bug is likely present in Go 1.2.1, but since it depends
on Go calling C calling Go, with the inner Go panicking and
the outer Go recovering the panic, it seems not important
enough to bother fixing before Go 1.3. Certainly no one has
complained.

Fixes #7470.

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

Regenerate z-files for DragonFly BSD 3.6.

F_DUP_FD_CLOEXEC is now supported, so remove the zero value constant
from types_dragonfly.go so that we use the generated value from the
z-files.

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

The format of the DragonFly BSD syscalls.master file has changed
slightly - update mksysnum_dragonfly.pl to match.

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

Disable the "udp" to IPv6 unicast address on the loopback interface
test under DragonFly BSD. This currently returns a local address of
0.0.0.1, rather than an IPv6 address with zone identifier.

Update #7473

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

Performing multiple connect system calls on a non-blocking socket
under DragonFly BSD does not necessarily result in errors from earlier
connect calls being returned, particularly if we are connecting to
localhost. Instead, once netpoll tells us that the socket is ready,
get the SO_ERROR socket option to see if the connection succeeded
or failed.

Fixes #7474

LGTM=mikioh.mikioh
R=mikioh.mikioh
CC=golang-codereviews
https://golang.org/cl/69340044

Logging calls when running "go install -a std" turns:

  547  openDir succeeded
  3593 openDir failed and fell back to openFile
  3592 openFile succeeded
  1    both failed

into:

  3592 openFile succeeded
  548  openFile failed and fell back
  547  openDir succeeded
  1    both failed

Here the change trades 3593 failed openDir for 548 failed openFile.

Fix issue 7426.

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

Added test cases and expanded test harness to handle token end
positions.

Also: Make sure token end positions are never outside the valid
      position range, as was possible in case of parse errors.

Fixes #7458.

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

the crypto/tls revision d3d43f270632 (CL 67010043, requiring ServerName or InsecureSkipVerify) breaks net/smtp,
since it seems impossible to do SMTP via TLS anymore. i've tried to fix this by simply using a tls.Config with
ServerName, instead of a nil *tls.Config. without this fix, doing SMTP with TLS results in error "tls: either
ServerName or InsecureSkipVerify must be specified in the tls.Config".

testing: the new method TestTlsClient(...) sets up a skeletal smtp server with tls capability, and test client
injects a "fake" certificate allowing tls to work on localhost; thus, the modification to SendMail(...) enabling
this.

Fixes #7437.

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

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

The arm puts the text flags in a different place
than the other architectures. This needs to be
cleaned up.

TBR=minux
CC=golang-codereviews
https://golang.org/cl/71260043

Fixes #7454

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

The network connection dies differently from the server's
perspective on (some) Windows when the client goes away. Match
on the common prefix (common to Unix and Windows) instead of
the network error part.

Fixes #7456

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

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

For non-closure functions, the context register is uninitialized
on entry and will not be used, but morestack saves it and then the
garbage collector treats it as live. This can be a source of memory
leaks if the context register points at otherwise dead memory.
Avoid this by introducing a parallel set of morestack functions
that clear the context register, and use those for the non-closure functions.

I hope this will help with some of the finalizer flakiness, but it probably won't.

Fixes #7244.

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

I have one machine where this 25 test run is flaky
and fails ("21 >= 21"), but 50 works everywhere.

LGTM=josharian
R=josharian
CC=golang-codereviews
https://golang.org/cl/67870053

It mentioned true and false for error values. Instead, just
don't mention the error semantics, as they match normal Go
conventions (if error is non-nil, the other value is
meaningless). We generally only document error values when
they're interesting (where non-nil, non-nil is valid, or the
error value can be certain known values or types).

Fixes #7464

LGTM=agl
R=agl
CC=golang-codereviews
https://golang.org/cl/68440044

Fixes #6463.

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

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

Generated by addca.

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

Generated by addca.

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

Generated by addca.

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

The flakiness appears to be just in tests, not in the actual code.
Specifically, the many tests call runtime.GC once and expect that
the finalizers will be running in the background when GC returns.
Now that the sweep phase is concurrent with execution, however,
the finalizers will not be run until sweep finishes, which might
be quite a bit later. To force sweep to finish, implement runtime.GC
by calling the actual collection twice. The second will complete the
sweep from the first.

This was reliably broken after a few runs before the CL and now
passes tens of runs:

while GOMAXPROCS=2 ./runtime.test -test.run=Finalizer -test.short \
        -test.timeout=300s -test.cpu=$(perl -e 'print ("1,2,4," x 100) . "1"')
do true; done

Fixes #7328.

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

Fixes #7438.

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

Fixes #7346.

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

The exception handler runs on the ordinary g stack,
and the stack copier is now trying to do a traceback
across it. That's never been needed before, so it was
unimplemented. Implement it, in all its ugliness.

Fixes windows/amd64 build.

TBR=khr
CC=golang-codereviews
https://golang.org/cl/71030043

gccgo considers built-in function calls returning a constant not as function call (issue 7386)
go/types considers any call (regular or built-in) as a function call

The wording and examples clarify that only "function calls" that are issued
at run-time (and thus do not result in a constant result) are considered
function calls in this case.

gc is inconsistent (issue 7385)
gccgo already interprets the spec accordingly and issue 7386 is moot.
go/types considers all calls (constant or not) as function calls (issue 7457).

Fixes #7387.
Fixes #7386.

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

1) Move StateHijacked callback earlier, to make it
panic-proof.  A Hijack followed by a panic didn't previously
result in ConnState getting fired for StateHijacked.  Move it
earlier, to the time of hijack.

2) Don't fire StateActive unless any bytes were read off the
wire while waiting for a request. This means we don't
transition from New or Idle to Active if the client
disconnects or times out. This was documented before, but not
implemented properly.

This CL is required for an pending fix for Issue 7264

LGTM=josharian
R=josharian
CC=golang-codereviews
https://golang.org/cl/69860049

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

Actually, speed up Int31n and Int63n by avoiding retry loop.

benchmark           old ns/op    new ns/op    delta
BenchmarkFloat32           32           26  -19.45%
BenchmarkFloat64           46           23  -49.47%

Fixes #7267.

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

TBR=ken2
CC=golang-codereviews
https://golang.org/cl/70200053

Also makes variable names explicit.

Fixes #7186.

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

Update #7186
Update #7428

LGTM=r, bradfitz
R=golang-codereviews, rsc, minux.ma, r, bradfitz
CC=golang-codereviews
https://golang.org/cl/68880043

Fixes #7187.
Update #7193

LGTM=bradfitz
R=golang-codereviews, dave, rsc, minux.ma, bradfitz
CC=golang-codereviews
https://golang.org/cl/64510043

This CL tweaks syscall.InterfaceMessage to support FreeBSD 10 and
prior to 10.

See http://svnweb.freebsd.org/base?view=revision&revision=254804.

Fixes #7193.

LGTM=iant
R=golang-codereviews, rsc, minux.ma, gobot, iant
CC=golang-codereviews
https://golang.org/cl/56980043

Update #7193

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

Unfortunately FreeBSD 10 has changed its syscall arguments for
some reasons but as per request at golang-dev this CL does not
generate some structures, syscall numbers and constants as
compatible to FreeBSD 10 as follows:

Structure: Stat_t, IfData, IfMsghdr are based on 8-STABLE
Syscall number: Capsicum API is based on 9-STABLE
Constant: IFT_CARP, SIOCAIFADDR, SIOCSIFPHYADDR are based on 9-STABLE

Update #7193

FreeBSD 10 breaking changes:

r205792: Rename st_*timespec fields to st_*tim for POSIX 2008
compliance.
http://svnweb.freebsd.org/base?view=revision&revision=205792

r254804: Restructure the mbuf pkthdr to make it fit for upcoming
capabilities and features.
http://svnweb.freebsd.org/base?view=revision&revision=254804

r255219: Change the cap_rights_t type from uint64_t to a structure
that we can extend in the future in a backward compatible (API and
ABI) way.
http://svnweb.freebsd.org/base?view=revision&revision=255219

LGTM=iant
R=golang-codereviews, rsc, minux.ma, gobot, iant
CC=golang-codereviews
https://golang.org/cl/56770044

CBARGS is unused on amd64p32 so make this explicit.

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