CLA links are now redirects. Use new URLs instead.

Also, use https:// links for all Google sites where
the http version just redirects to https anyway.
(That's all links on the page, as it turns out)

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

Also add it to doc/go1.3.txt.

Update #7289

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

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

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

Fixes #7289.

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

Generated by addca.

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

Fixes the syscall test.

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

This documents the implemented behavior of both
gc and gccgo as an implementation restriction.

NOT A LANGUAGE CHANGE.

Fixes #5425.

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

Essentialy for running tests without a working cmd/go.
While we're at it, also fix a typo.

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

During the glob decoding process interface values are set to concrete
values after a test for assignability. If the assignability test fails
a slightly vague error message is produced. While technically accurate
the error message does not clearly describe the problem.

Rewrite the error message to include the usage of the word assignable,
which makes it clear the concrete value type is not assignable to the
interface value type.

Fixes #6467.

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

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

Recently NetBSD starts to enforce this, and refuses to execute
the program if n is larger than the sum of entry sizes.

Before:
$ readelf -n ../bin/go.old
Notes at offset 0x00000bd0 with length 0x00000019:
  Owner         Data size       Description
  NetBSD                0x00000004      NT_VERSION (version)
readelf: Warning: corrupt note found at offset 18 into core notes
readelf: Warning:  type: 0, namesize: 00000000, descsize: 00000000
$ readelf -n ../bin/go
Notes at offset 0x00000bd0 with length 0x00000018:
Owner         Data size       Description
NetBSD                0x00000004      NT_VERSION (version)

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

Add CgoFiles to the covered files when building
with cover support.

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

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