Tests exist that call m.Run in a loop‽
Now we have one too.

Fixes #23129.

Change-Id: I8cbecb724f239ae14ad45d75e67d12c80e41c994
Reviewed-on: https://go-review.googlesource.com/83956
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

os.NewFile doesn't put the fd into non-blocking mode.
In most cases, an *os.File returned by os.NewFile is in blocking mode.

Updates #7970
Updates #21856
Updates #23111

Change-Id: Iab08432e41f7ac1b5e25aaa8855d478adb7f98ed
Reviewed-on: https://go-review.googlesource.com/83995Reviewed-by: Ian Lance Taylor <iant@golang.org>

The export prologue goes into the _cgo_export.h file, where it may be
be #include'd by a .swig file. As SWIG defines its own type "intgo",
the definition of "intgo" in the export prologue could conflict.
Since we don't need to define "intgo" in the _cgo_export.h file, don't.

Defining "intgo" in _cgo_export.h was new for this release, so this
should not break any existing code.

No test case as I can't quite bring myself to write a test that
combines SWIG and cgo.

Change-Id: I8073e8300a1860cecd5994b9ad07dd35a4298c89
Reviewed-on: https://go-review.googlesource.com/83936
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #22989.

Change-Id: I9776a7b0d0598c2cb118c323d1f8f933665da254
Reviewed-on: https://go-review.googlesource.com/83881
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

t.Run(f) does not wait for f after f calls t.Parallel.
Otherwise it would be impossible to create new
parallel sibling subtests for f.

Fixes #22993.

Change-Id: I27e1555ab1ff608eb8155db261d5e7ee8f486aef
Reviewed-on: https://go-review.googlesource.com/83880
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

If package strings has a particular set of gcflags, then the strings_test
pseudo-package built as part of the test binary started inheriting the
same flags in CL 81496, to fix #22831.

Now the package main and final test binary link built as part of the
strings test binary also inherit the same flags, to fix #22994.

I am slightly uneasy about reusing package strings's flags for
package main, but the alternative would be to introduce some
kind of special case, which I'd be even more uneasy about.

This interpretation preserves the Go 1.9 behavior of existing
commands like:

	go test -c -ldflags=-X=mypkg.debugString=foo mypkg

Fixes #22994.

Change-Id: I9ab83bf1a9a6adae530a7715b907e709fd6c1b5d
Reviewed-on: https://go-review.googlesource.com/83879
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Updates #7970
Updates #21856
Updates #23111

Change-Id: I0cd0151fcca740c40c3c976f941b04e98e67b0bf
Reviewed-on: https://go-review.googlesource.com/83715Reviewed-by: Russ Cox <rsc@golang.org>

Change-Id: I4e357a250b2f9cfbf780b05c5f54805682b19a62
Reviewed-on: https://go-review.googlesource.com/83935Reviewed-by: Matthew Dempsky <mdempsky@google.com>

Updates #22027.

Change-Id: I468348d2b000f146f88ef8b7cf450eea8d1c12a7
Reviewed-on: https://go-review.googlesource.com/83917Reviewed-by: Andrew Bonventre <andybons@golang.org>

This allows errchk to be used with "go vet" output (as opposed to "go tool vet").

Change-Id: I0009a53c9cb74accd5bd3923c137d6dbf9e46326
Reviewed-on: https://go-review.googlesource.com/83836
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Found by upcoming cmd/vet change.

Change-Id: I7a8264a304b2a4f26f3bd418c1b28cc849889c9b
Reviewed-on: https://go-review.googlesource.com/83835
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

The current implementation ignores certs wherein the
Subject does not match the Issuer. An example of where
this causes issue is an enterprise environment with
intermediate CAs. In this case, the issuer is separate
(and may be loaded) but the intermediate is ignored.
A TLS handshake that does not include the intermediate
cert would then fail with an untrusted error in Go.

On other platforms (darwin-nocgo included), all trusted
certs are loaded and accepted reguardless of
Subject/Issuer names.

This change removes the Subject/Issuer name-matching
restriction of certificates when trustAsRoot is set,
allowing all trusted certs to be loaded on darwin (cgo).

Refs #16532

Change-Id: I451e929588f8911892be6bdc2143d0799363c5f8
Reviewed-on: https://go-review.googlesource.com/36942
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Use Brendan Gregg's FlameGraphs page link.
Mention the flame graph is available from the upstream pprof.

Change-Id: Ife1d5a5f4f93f20cd5952a09083f798b77d25a60
Reviewed-on: https://go-review.googlesource.com/83798Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

By the time Go 1.11 is released, OS X 10.9 Mavericks will have gone
two years with no security updates.

For #23011.

Change-Id: I6482852a14477985769b72c45c92416aae8be100
Reviewed-on: https://go-review.googlesource.com/83795
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

As mentioned in #22802, only day component of layout string has space
padding(represented by one underscore before its placeholder). This
commit expands the rule for month, hour, minute and second.

Updates #22802 (maybe fixes it)

Change-Id: I886998380489862ab9a324a6774f2e4cf7124122
Reviewed-on: https://go-review.googlesource.com/78735
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

An exec command is normally used on platforms were the test is run in
some unusual way, making it less likely that the testlog will be useful.

Updates #22593

Change-Id: I0768f6da89cb559d8d675fdf6d685db9ecedab9e
Reviewed-on: https://go-review.googlesource.com/83578
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Fixes #23085

Change-Id: I7fef281079e9e08c49ae05371506b0b881a467db
Reviewed-on: https://go-review.googlesource.com/83577Reviewed-by: Ian Lance Taylor <iant@golang.org>

We can't currently inline functions that contain closures anyway, so
just delete this budgeting code for now. Re-enable once we can (if
ever) inline functions with nested closures.

Updates #15561.
Fixes #23093.

Change-Id: Idc5f8e042ccfcc8921022e58d3843719d4ab821e
Reviewed-on: https://go-review.googlesource.com/83538
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>

When using -importcfg, the import paths recorded by the compiler in
the object file are simply the import paths. When not using -importcfg,
the import paths have a trailing ".a". Assume that if we are using
-importcfg with the compiler, we are using it with the linker,
and so if the linker sees an -importcfg option it should not
strip ".a" from the import path read from the object files.

This was mostly working because the linker only strips a trailing
".x" for a literal dot and any single character 'x'. Since few import
paths end with ".x", most programs worked fine.

Fixes #22986

Change-Id: I6c10a160b97dd63fff3931f27a1514c856e8cd52
Reviewed-on: https://go-review.googlesource.com/81878
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>

The file cmd/go/testdata/src/testcache/script.sh was accidentally
committed with CL 83256. Sorry about that.

Updates #22593

Change-Id: Id8f07587ea97015ed75439db220560a5446e53e6
Reviewed-on: https://go-review.googlesource.com/83395Reviewed-by: Russ Cox <rsc@golang.org>

Otherwise, on systems for which syscall does not implement Getwd,
a lot of unnecessary files and directories get added to the testlog,
right up the root directory. This was causing tests on such systems
to fail to cache in practice.

Updates #22593

Change-Id: Ic8cb3450ea62aa0ca8eeb15754349f151cd76f85
Reviewed-on: https://go-review.googlesource.com/83455
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

All plugins issues I would call bugs now closed, so
(with some amount of optimism) update the plugin documentation.

Change-Id: Ia421c18a166d7cdf599ac86f2336541c1ef42a0d
Reviewed-on: https://go-review.googlesource.com/65670Reviewed-by: Ian Lance Taylor <iant@golang.org>

Updates #22593

Change-Id: I76e52dc8b874da13ae9e2d80e5c0d6d8424b67db
Reviewed-on: https://go-review.googlesource.com/83257
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

It causes every test to fail as the log file is on the local file system,
not the NaCl file system.

Updates #22593

Change-Id: Iee3d8307317bd792c9c701baa962ebbbfa34c147
Reviewed-on: https://go-review.googlesource.com/83256
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Instead of requiring that cmd/api/run.go be edited upon each
release to include the next Go version number, look in $GOROOT/api
for files with the prefix go1* and use those instead to perform
API checks.

Change-Id: I5d9407f2bd368ff5e62f487cccdd245641ca9c9b
Reviewed-on: https://go-review.googlesource.com/83355Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I6d94a14a781a2fbeb90db35ae3490ce2ac5f8ed1
Reviewed-on: https://go-review.googlesource.com/83315Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: Ie7f2890eab9ad82da93babc92380b13c611af3d0
Reviewed-on: https://go-review.googlesource.com/83375Reviewed-by: Andrew Bonventre <andybons@golang.org>

Use “substantial”, which is believed to be the correct word.
Additionally, this change strips trailing whitespace from the file.

Change-Id: I5b6b718fc09e4b8b911b95e8be0733abd58e165d
Reviewed-on: https://go-review.googlesource.com/83356Reviewed-by: Andrew Gerrand <adg@golang.org>

The Builder's ReadFrom method allows the underlying unsafe slice to
escape, and for callers to subsequently modify memory that had been
unsafely converted into an immutable string.

In the original proposal for Builder (#18990), I'd noted there should
be no Read methods:

> There would be no Reset or Bytes or Truncate or Read methods.
> Nothing that could mutate the []byte once it was unsafely converted
> to a string.

And in my prototype (https://golang.org/cl/37767), I handled ReadFrom
properly, but when https://golang.org/cl/74931 arrived, I missed that
it had a ReadFrom method and approved it.

Because we're so close to the Go 1.10 release, just remove the
ReadFrom method rather than think about possible fixes. It has
marginal utility in a Builder anyway.

Also, fix a separate bug that also allowed mutation of a slice's
backing array after it had been converted into a slice by disallowing
copies of the Builder by value.

Updates #18990
Fixes #23083
Fixes #23084

Change-Id: Id1f860f8a4f5f88b32213cf85108ebc609acb95f
Reviewed-on: https://go-review.googlesource.com/83255Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

When we write a cached test result, we now also write a log of the
environment variables and files inspected by the test run,
along with a hash of their content. Before reusing a cached test result,
we recompute the hash of the content specified by the log, and only
use the result if that content has not changed.

This makes test caching behave correctly for tests that consult
environment variables or stat or read files or directories.

Fixes #22593.

Change-Id: I8608798e73c90e0c1911a38bf7e03e1232d784dc
Reviewed-on: https://go-review.googlesource.com/81895
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I0c387b6286bc18fd00c6ac4e42bdf175cf89ccb1
Reviewed-on: https://go-review.googlesource.com/83155Reviewed-by: Ian Lance Taylor <iant@golang.org>

Currently, wbBufFlush does nothing if the goroutine is dying on the
assumption that the system is crashing anyway and running the write
barrier may crash it even more. However, it fails to reset the
buffer's "next" pointer. As a result, if there are later write
barriers on the same P, the write barrier will overflow the write
barrier buffer and start corrupting other fields in the P or other
heap objects. Often, this corrupts fields in the next allocated P
since they tend to be together in the heap.

Fix this by always resetting the buffer's "next" pointer, even if
we're not doing anything with the pointers in the buffer.

Updates #22987 and #22988. (May fix; it's hard to say.)

Change-Id: I82c11ea2d399e1658531c3e8065445a66b7282b2
Reviewed-on: https://go-review.googlesource.com/83016
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>

heapBits.bits is used during bulkBarrierPreWrite via
heapBits.isPointer, which means it must not be preempted. If it is
preempted, several bad things can happen:

1. This could allow a GC phase change, and the resulting shear between
the barriers and the memory writes could result in a lost pointer.

2. Since bulkBarrierPreWrite uses the P's local write barrier buffer,
if it also migrates to a different P, it could try to append to the
write barrier buffer concurrently with another write barrier. This can
result in the buffer's next pointer skipping over its end pointer,
which results in a buffer overflow that can corrupt arbitrary other
fields in the Ps (or anything in the heap, really, but it'll probably
crash from the corrupted P quickly).

Fix this by marking heapBits.bits go:nosplit. This would be the
perfect use for a recursive no-preempt annotation (#21314).

This doesn't actually affect any binaries because this function was
always inlined anyway. (I discovered it when I was modifying heapBits
and make h.bits() no longer inline, which led to rampant crashes from
problem 2 above.)

Updates #22987 and #22988 (but doesn't fix because it doesn't actually
change the generated code).

Change-Id: I60ebb928b1233b0613361ac3d0558d7b1cb65610
Reviewed-on: https://go-review.googlesource.com/83015
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rick Hudson <rlh@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Fixes #23073

Change-Id: Ia43b28beeff9e57579caf5dcb76146ee29d5033b
Reviewed-on: https://go-review.googlesource.com/82918Reviewed-by: Ian Lance Taylor <iant@golang.org>

Parts of TestUDPConnSpecificMethods and TestWriteToUDP fail, because
UDPConn.WriteMsgUDP is broken on Windows XP. UDPConn.WriteMsgUDP uses
Windows WSASendMsg API, but that call is not implemented on Windows XP (see
https://msdn.microsoft.com/en-us/library/windows/desktop/ms741692(v=vs.85).aspx
for details)

Update #23072

Change-Id: I4e8f149bc62bd87cd7c199e6832b9ce479af0a3e
Reviewed-on: https://go-review.googlesource.com/83077
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

For #23072

Change-Id: I089feafef2900413d46f2358b6e41ab78187eced
Reviewed-on: https://go-review.googlesource.com/83076Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Change-Id: I2ad5d73deaee57ccbb2c75378dcc2884e43be3bb
Reviewed-on: https://go-review.googlesource.com/82899Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

On DragonFly mmap with MAP_STACK returns the top of the region, not
the bottom. Rather than try to cope, just don't use the flag anywhere.

Fixes #23061

Change-Id: Ib5df4dd7c934b3efecfc4bc87f8989b4c37555d7
Reviewed-on: https://go-review.googlesource.com/83035
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

The package unsafe docs say it's safe to convert an unsafe.Pointer to
uintptr in the argument list to an assembly function, but it was
erroneously only detecting normal pointers converted to unsafe.Pointer
and then to intptr.

Fixes #23051.

Change-Id: Id1be19f6d8f26f2d17ba815191717d2f4f899732
Reviewed-on: https://go-review.googlesource.com/82817
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

This essentially applies https://golang.org/cl/81636 to the net package.

The full truth seems too complicated to write in this method's doc, so
I'm going with a simple half truth.

The full truth is that File returns the descriptor in blocking mode,
because that is historically how it worked, and existing programs
would be surprised if the descriptor is suddenly non-blocking. On Unix
systems whether a socket is non-blocking or not is a property of the
underlying file description, not of a particular file descriptor, so
changing the returned descriptor to blocking mode also changes the
existing socket to blocking mode. Blocking mode works fine, althoug I/O
operations now take up a thread. SetDeadline and friends rely on the
runtime poller, and the runtime poller only works if the descriptor is
non-blocking. So it's correct that calling File disables SetDeadline.
The other half of the truth is that if the program is willing to work
with a non-blocking descriptor, it could call
syscall.SetNonblock(f.Fd(), true) to change the descriptor, and
the original socket, to non-blocking mode. At that point SetDeadline
would start working again. I tried to write that in a way that is
short and comprehensible but failed. Since we now have the RawConn
approach to frobbing the descriptor, and hopefully most people can use
that rather than calling File, I decided to punt.

Updates #22934
Fixes #21862

Change-Id: If269da762f6f5a88c334e7b6d6f3998f7e10b11e
Reviewed-on: https://go-review.googlesource.com/82915Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>