Cherry Mui [Tue, 14 Dec 2021 17:17:53 +0000 (12:17 -0500)]
doc/go1.18: remove residual TODOs
There doesn't seem anything that still needs to de done there.
Updates #47694.
Change-Id: I7909f566638332f3904d20a34f61d371af1d2da2
Reviewed-on: https://go-review.googlesource.com/c/go/+/371754
Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Jeremy Faller <jeremy@golang.org> Reviewed-by: Alex Rakoczy <alex@golang.org>
Russ Cox [Tue, 14 Dec 2021 15:49:07 +0000 (10:49 -0500)]
cmd/compile: fix any in -G=0 mode
Fixes go test -gcflags=all=-G=0 -short std,
except for the packages with generics in their tests
(constraints, encoding/xml), and except for the
go/internal/gcimporter and go/types tests,
because the compiler does not preserve any
in its -G=0 export information.
(That's probably acceptable for now.)
Fixes cd test/; GO_BUILDER_NAME=longtest go run run.go
completely, which should fix the longtest builder.
Dan Scales [Tue, 14 Dec 2021 00:15:52 +0000 (16:15 -0800)]
cmd/compile: fix case where we didn't delay transformAssign in varDecl
We delay all transformations on generic functions, and only do them on
instantiated functions, for several reasons, of which one is that
otherwise the compiler won't understand the relationship between
constrained type parameters. In an instantiation with shape arguments,
the underlying relationship between the type arguments are clear and
don't lead to compiler errors.
This issue is because I missed delaying assignment transformations for
variable declarations. So, we were trying to transform an assignment,
and the compiler doesn't understand the relationship between the T and U
type parameters.
The fix is to delay assignment transformations for variable declarations
of generic functions, just as we do already for normal assignment
statements.
A work-around for this issue would be to just separate the assignment
from the variable declaration in the generic function (for this case of
an assignment involving both of the constrained type parameters).
Fixes #50147
Change-Id: Icdbcda147e5c4b386e4715811761cbe73d0d837e
Reviewed-on: https://go-review.googlesource.com/c/go/+/371534
Trust: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Dan Scales [Mon, 13 Dec 2021 20:42:38 +0000 (12:42 -0800)]
cmd/compile: avoid re-instantiating method that is already imported
We can import an shape-instantiated function/method for inlining
purposes. If we are instantiating the methods of a instantiated type
that we have seen, and it happens to need a shape instantiation that we
have imported, then don't re-create the instantiation, since we will end
up with conflicting/duplicate definitions for the instantiation symbol.
Instead, we can just use the existing imported instantation, and enter
it in the instInfoMap[].
Fixes #50121
Change-Id: I6eeb8786faad71106e261e113048b579afad04fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/371414
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Cherry Mui [Mon, 13 Dec 2021 15:24:07 +0000 (10:24 -0500)]
cmd/internal/obj: fix tail call in non-zero frame leaf function on MIPS and S390X
A "RET f(SB)" wasn't assembled correctly in a leaf function with
non-zero frame size. Follows CL 371034, for MIPS(32/64)(be/le)
and S390X. Other architectures seem to do it right. Add a test.
Change-Id: I41349a7ae9862b924f3a3de2bcb55b782061ce21
Reviewed-on: https://go-review.googlesource.com/c/go/+/371214
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: David Chase <drchase@google.com>
Bryan C. Mills [Mon, 13 Dec 2021 21:12:50 +0000 (16:12 -0500)]
net/http: revert h2_bundle.go formatting change from CL 368254
h2_bundle.go is automatically generated from x/net/http2. Any
formatting changes within that file need to be first made upstream.
This brings the contents of h2_bundle.go back in line with the
upstream generator, fixing the cmd/internal/moddeps test that is
currently failing on the longtest builders.
Than McIntosh [Mon, 13 Dec 2021 17:03:13 +0000 (12:03 -0500)]
cmd/compile/internal/amd64: fix for coverage testing
Fix up a unit test to make it more friendly for coverage runs.
Currently on tip if you do
cd ${GOROOT}/src ; go test -cover cmd/compile/...
it will cause a failure in the TestGoAMD64v1 testpoint of
cmd/compile/internal/amd64, the reason being that this testpoint
copies and reruns the test executable, expecting the rerun to produce
only the output "PASS", whereas if "-cover" is used, the output will
include percentage of statements covered as well. To fix, rework the
test to tolerate additional output if coverage is enabled.
Change-Id: I2512e06ca06e5f38108f2891ff84276d148c4f9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/371234 Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Katie Hockman [Fri, 10 Dec 2021 19:03:20 +0000 (14:03 -0500)]
testing: update docs for fuzzcachedir
Although most of the code seems to be already implemented
to support this for general use, it didn't make it in for
Go 1.18, so for now we should at least document that it's
only for use by the go command.
Russ Cox [Wed, 1 Dec 2021 17:15:45 +0000 (12:15 -0500)]
all: gofmt -w -r 'interface{} -> any' src
And then revert the bootstrap cmd directories and certain testdata.
And adjust tests as needed.
Not reverting the changes in std that are bootstrapped,
because some of those changes would appear in API docs,
and we want to use any consistently.
Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories
when preparing the bootstrap copy.
A few files changed as a result of running gofmt -w
not because of interface{} -> any but because they
hadn't been updated for the new //go:build lines.
Robert Griesemer [Fri, 10 Dec 2021 23:35:46 +0000 (15:35 -0800)]
spec: fix conversion rules (match implementation)
As written, the conversion P(x), where P and the type
of x are type parameters with identical underlying types
(i.e., identical constraints), is valid. However, unless
the type of x and P are identical (which is covered with
the assignability rule), such a conversion is not valid
in general (consider the case where both type parameters
are different type parameters with constraint "any").
This change adjusts the rules to prohibit type parameters
in this case. The same reasoning applies and the analogue
change is made for pointer types.
The type checker already implements these updated rules.
Change-Id: Id90187900cb2820f6a0a0cf582cf26cdf8addbce
Reviewed-on: https://go-review.googlesource.com/c/go/+/371074
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bryan C. Mills [Fri, 10 Dec 2021 19:13:52 +0000 (14:13 -0500)]
net: refactor TestWriteToTimeout
The test cases for this test had listed specific errors, but the
specific error values were ignored in favor of just calling
isDeadlineExceeded.
Moreover, ENOBUFS errors (which can legitimately occur in the test if
the network interface also happens to be saturated when the timeout
occurs) were not handled at all.
Now the test relies only on the timeout: we iterate until we have seen
two of the expected timeout errors, and if we see ENOBUFS instead of
"deadline exceeded" we back off to give the queues time to drain.
Bryan C. Mills [Thu, 9 Dec 2021 16:55:20 +0000 (11:55 -0500)]
net: create unix sockets in unique directories
This change applies the same transformation as in CL 366774,
but to the net package.
testUnixAddr was using os.CreateTemp to obtain a unique socket path,
but then calling os.Remove on that path immediately. Since the
existence of the file is what guarantees its uniqueness, that could
occasionally result in testUnixAddr returning the same path for two
calls, causing the tests using those paths to fail — especially if
they are the same test or are run in parallel.
Instead, we now create a unique, short temp directory for each call,
and use a path within that directory for the socket address.
Bryan C. Mills [Thu, 9 Dec 2021 16:42:42 +0000 (11:42 -0500)]
net: pass a testing.TB to newLocal* helpers
Passing in an explicit testing.TB gives two benefits:
1. It allows the helper to fail the test itself, instead of returning
an error to the caller. A non-nil error invariably fails the
calling test, and none of these callers bother to add detail to the
error when logging it anyway so returning the error just added
noise to the test bodies.
2. It allows the helper to use t.Cleanup to perform any needed cleanup
tasks, which will be used in CL 370695 to clean up temp directories
used as namespaces for unix socket paths.
Bryan C. Mills [Thu, 9 Dec 2021 16:54:46 +0000 (11:54 -0500)]
net: do not try to remove the LocalAddr of a unix socket
TestUnixAndUnixpacketServer deferred a call to os.Remove on the local
address of a dialed unix domain socket, in an attempt to remove the
socket from the server. However, that call appears to be neither
necessary nor correct.
In this test, the file that needs to be unlinked is the one attached
to the listener — but the listener's Close method already does that
(see the Unlink call in (*UnixListener).close), so there is no need
for the test itself to do the same.
Moreover, the local address is not something that is sensible to
delete — on Linux, it is empirically always the literal string "@" —
and the Addr returned by c.LocalAddr is not reliably non-nil on all
platforms (see #34611).
Since we don't need to do anything with the local address, we shouldn't.
At best, this is a benign Remove of a file that doesn't exist anyway;
at worst, it is a nil-panic.
Bryan C. Mills [Thu, 9 Dec 2021 22:00:51 +0000 (17:00 -0500)]
net: remove erroneous Dial check in TestListenerClose
TestListenerClose had been asserting that a Dial to the newly-closed
address always fails, on the assumption that the listener's address
and port would not be reused by some other listener that could then
accept the connection.
As far as I can tell, that assumption is not valid: the Dial after
Close may well connect to a Listener opened for some other test, or
even one opened by a completely different process running concurrently
on the same machine.
Dan Scales [Sun, 12 Dec 2021 19:08:59 +0000 (11:08 -0800)]
cmd/compile: fix identity case relating to 'any' and shape types
In identical(), we don't want any to match a shape empty-interface type
for the identStrict option, since IdenticalStrict() is specifically not
supposed to match a shape type with a non-shape type.
There is similar code in (*Type).cmp() (TINTER case), but I don't
believe that we want to disqualify shape types from matching any in this
case, since cmp() is used for back-end code, where we don't care about
shape types vs non-shape types.
The issue mainly comes about when 'any' is used as a type argument
(rather than 'interface{}'), but only with some complicated
circumstances, as shown by the test case. (Couldn't reproduce with
simpler test cases.)
Fixes #50109
Change-Id: I3f2f88be158f9ad09273237e1d346bc56aac099f
Reviewed-on: https://go-review.googlesource.com/c/go/+/371154
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Austin Clements [Sat, 11 Dec 2021 02:09:16 +0000 (21:09 -0500)]
os: document error returned by pending I/O operations on Close
Currently, File.Close only documents that "an" error will be returned
by pending I/O operations. Update the documentation to say that error
is specifically ErrClosed.
Change-Id: Ica817c9196ad6cb570c826789d37a4ff15a5d13d
Reviewed-on: https://go-review.googlesource.com/c/go/+/371015
Trust: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Thu, 9 Dec 2021 17:51:29 +0000 (12:51 -0500)]
testenv: kill subprocess if SIGQUIT doesn't do it
This makes testenv.RunWithTimeout first attempt to SIGQUIT the
subprocess to get a useful Go traceback, but if that doesn't work, it
sends a SIGKILL instead to make sure we tear down the subprocess. This
is potentially important for non-Go subprocesses.
Austin Clements [Thu, 9 Dec 2021 17:25:04 +0000 (12:25 -0500)]
testenv: abstract run-with-timeout into testenv
This lifts the logic to run a subcommand with a timeout in a test from
the runtime's runTestProg into testenv. The implementation is
unchanged in this CL. We'll improve it in a future CL.
Currently, tests that run subcommands usually just timeout with no
useful output if the subcommand runs for too long. This is a step
toward improving this.
Tim King [Thu, 9 Dec 2021 19:06:25 +0000 (11:06 -0800)]
doc: document cmd/vet changes for 1.18 release
cmd/vet has several precision improvements for the checkers copylock, printf, sortslice, testinggoroutine, and tests. Adds a high level mention in the release notes and an example of string constant concatenation.
Updates #47694
Change-Id: I7a342a57ca3fd9e2f3e8ec99f7b647269798317f
Reviewed-on: https://go-review.googlesource.com/c/go/+/370734 Reviewed-by: Russ Cox <rsc@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Tim King <taking@google.com>
Run-TryBot: Tim King <taking@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Bryan C. Mills [Fri, 3 Dec 2021 19:02:58 +0000 (14:02 -0500)]
net: ignore EADDRINUSE errors when dialing to IPv4 from IPv6 on FreeBSD
The failure mode in #34264 appears to match
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210726.
That bug was supposed to have been fixed in FreeBSD 12, but we're
still observing failures specifically for the 6-to-4 case on FreeBSD
12.2. It is not clear to me whether FreeBSD 13.0 is also affected.
For #34264
Change-Id: Iba7c7fc57676ae628b13c0b8fe43ddf2251c3637
Reviewed-on: https://go-review.googlesource.com/c/go/+/369157
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Matthew Dempsky [Wed, 8 Dec 2021 19:12:50 +0000 (11:12 -0800)]
cmd/compile: preserve 'any' type alias in unified IR
When exporting the "any" empty interface type for unified IR, write it
out as a reference to the "any" alias, rather than to the underlying
empty interface. This matches how "byte" and "rune" are handled.
Verified to fix the issue demonstrated in CL 369975.
Change-Id: Ic2844b0acc3b17c20b3a40aaf262f62ec653eb5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/370374
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
Bryan C. Mills [Wed, 8 Dec 2021 21:47:56 +0000 (16:47 -0500)]
crypto/x509: skip known TestSystemVerify flakes on windows-*-2008 builders
The "-2008" builders are the only ones on which the failure has
been observed, so I suspect that it is due to a platform bug fixed in a
subsequent release.
Since no one has added a workaround since #19564 was filed over four
years ago, I'm assuming that no workaround is planned for this issue.
Let's add a skip for the known failure mode and call it at that.
Russ Cox [Wed, 8 Dec 2021 23:06:41 +0000 (18:06 -0500)]
syscall: avoid writing to p when Pipe(p) fails
Generally speaking Go functions make no guarantees
about what has happened to result parameters on error,
and Pipe is no exception: callers should avoid looking at
p if Pipe returns an error.
However, we had a bug in which ForkExec was using the
content of p after a failed Pipe, and others may too.
As a robustness fix, make Pipe avoid writing to p on failure.
Updates #50057
Change-Id: Ie8955025dbd20702fabadc9bbe1d1a5ac0f36305
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291271 Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370577
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Trust: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Rakoczy <alex@golang.org>
Russ Cox [Wed, 8 Dec 2021 23:05:11 +0000 (18:05 -0500)]
syscall: fix ForkLock spurious close(0) on pipe failure
Pipe (and therefore forkLockPipe) does not make any guarantees
about the state of p after a failed Pipe(p). Avoid that assumption
and the too-clever goto, so that we don't accidentally Close a real fd
if the failed pipe leaves p[0] or p[1] set >= 0.
Fixes #50057
Fixes CVE-2021-44717
Change-Id: Iff8e19a6efbba0c73cc8b13ecfae381c87600bb4
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1291270 Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/370576
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Trust: Russ Cox <rsc@golang.org> Reviewed-by: Alex Rakoczy <alex@golang.org>
Michael Pratt [Wed, 8 Dec 2021 20:30:28 +0000 (15:30 -0500)]
runtime/pprof: increase systemstack calls in TestLabelSystemstack
TestLabelSystemstack needs to collect samples within runtime.systemstack
to complete the test.
The current approach uses fmt.Fprintf, which gets into systemstack
through the allocator and GC, but also does lots of other work. In my
measurements, approximately 2% of samples contain runtime.systemstack.
The new approach uses debug.SetGCPercent, which uses systemstack for
most of its work, including contention on mheap_.lock, which extends
usage even more. In my measurements, approximately 99% of samples
contain runtime.systemstack.
Fixes #50050
Change-Id: I59e5bb756341b716a12e13d2e3fe0adadd7fe956
Reviewed-on: https://go-review.googlesource.com/c/go/+/370375 Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Heschi Kreinick [Wed, 8 Dec 2021 20:29:12 +0000 (15:29 -0500)]
cmd/api: run half as many go list calls in parallel
We currently run one 'go list' invocation per GOMAXPROC. Since the go
command uses memory and has its own internal parallelism, that's
unlikely to be an efficient use of resources. Run half as many. I
suspect that's still too many but this should fix our OOMs.
Robert Findley [Tue, 7 Dec 2021 19:29:21 +0000 (14:29 -0500)]
doc: document cmd/vet changes for generics in 1.18
Fixes #50011
Updates #47694
Change-Id: Id3d43f2f72de61b360b79c2b375ca1372d5f4692
Reviewed-on: https://go-review.googlesource.com/c/go/+/369979
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Tim King <taking@google.com>
David Chase [Tue, 23 Nov 2021 18:29:13 +0000 (13:29 -0500)]
cmd/compile: try to preserve IsStmt marks from OpConvert
Note when a statement mark was not consumed during Prog
generation, and try to use it on a subsequent opcode so
that the statement marker will not be lost.
And a test.
Fixes #49628.
Change-Id: I03f7782a9809cc4a0a5870df92b3e182cf124554
Reviewed-on: https://go-review.googlesource.com/c/go/+/366694
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Trust: Dan Scales <danscales@google.com> Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Michael Matloob [Tue, 23 Nov 2021 22:36:21 +0000 (17:36 -0500)]
cmd/go: fix hang in workspaces
golang.org/cl/365234 incorrectly had pruningForGoVersion always return
workspace pruning instead of just returning workspace pruning at the top
level, which broke the proper determination of pruning for dependency
packages. Fix that code, and also fix a hang that resulted because the
module loading code keeps loading dependencies until it reaches a pruned
module or an unpruned module it already saw, so it could get stuck in a
cycle.
Change-Id: I8911f7d83aaee5870c43ef0355abbd439f15d4f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/366775
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Robert Findley [Sat, 4 Dec 2021 14:35:34 +0000 (09:35 -0500)]
go/types: sort to reduce computational complexity of initOrder
Our calculation of initOrder builds the dependency graph and then
removes function nodes approximately at random. While profiling, I
noticed that this latter step introduces a superlinear algorithm into
our type checking pass, which can dominate type checking for large
packages such as runtime.
It is hard to analyze this rigorously, but to give an idea of how such a
non-linearity could arise, suppose the following assumptions hold:
- Every function makes D calls at random to other functions in the
package, for some fixed constant D.
- The number of functions is proportional to N, the size of the package.
Under these simplified assumptions, the cost of removing an arbitrary
function F is P*D, where P is the expected number of functions calling
F. P has a Poisson distribution with mean D.
Now consider the fact that when removing a function F in position i, we
recursively pay the cost of copying F's predecessors and successors for
each node in the remaining unremoved subgraph of functions containing F.
With our assumptions, the size of this subgraph is proportional to
(N-i), the number of remaining functions to remove.
Therefore, the total cost of removing functions is proportional to
P*D*Σᴺ(N-i)
which is proportional to N².
However, if we remove functions in ascending order of cost, we can
partition by the number of predecessors, and the total cost of removing
functions is proportional to
N*D*Σ(PMF(X))
where PMF is the probability mass function of P. In other words cost is
proportional to N.
Assuming the above analysis is correct, it is still the case that the
initial assumptions are naive. Many large packages are more accurately
characterized as combinations of many smaller packages. Nevertheless, it
is intuitively clear that removing expensive nodes last should be
cheaper.
Therefore, we sort by cost first before removing nodes in
dependencyGraph.
We also move deletes to the outer loop, to avoid redundant deletes. By
inspection, this avoids a bug where n may not have been removed from its
successors if n had no predecessors.
name old time/op new time/op delta
Check/runtime/funcbodies/noinfo-8 568ms ±25% 82ms ± 1% -85.53% (p=0.000 n=8+10)
name old lines/s new lines/s delta
Check/runtime/funcbodies/noinfo-8 93.1k ±56% 705.1k ± 1% +657.63% (p=0.000 n=10+10)
Updates #49856
Change-Id: Id2e70d67401af19205e1e0b9947baa16dd6506f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/369434
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Rhys Hiltner [Tue, 7 Dec 2021 21:32:24 +0000 (13:32 -0800)]
runtime: fix flake in TestCgoPprofThread
If the test's main goroutine receives a SIGPROF while creating the
C-owned thread for the test, that sample will appear in the resulting
profile. The root end of that stack will show a set of Go functions. The
leaf end will be the C functions returned by the SetCgoTraceback
handler, which will confuse the test runner.
Add a label to the main goroutine while it calls in to C, so all profile
samples that triggered the SetCgoTraceback handler are either correct,
or can easily be excluded from the test's analysis. (The labels will not
apply to the resulting C-owned thread, which does not use goroutines.)
Fixes #43174
Change-Id: Ica3100ca0f191dcf91b30b0084e8541c5a25689f
Reviewed-on: https://go-review.googlesource.com/c/go/+/370135 Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Bryan C. Mills [Wed, 8 Dec 2021 14:49:04 +0000 (09:49 -0500)]
debug/buildinfo: update test for CL 369977
As a side effect of the changes in cmd/go/internal/work in CL 369977,
binaries built in GOPATH mode now include rudimentary build metadata
for at least the package path and compiler in use.
That seems like a strict improvement, but the test needs to be updated
to reflect the newly-available metadata.
Russ Cox [Tue, 7 Dec 2021 22:09:41 +0000 (17:09 -0500)]
cmd: go get golang.org/x/tools@fd2bfb7 (Dec 7 2021)
cd src/cmd
go get golang.org/x/tools@fd2bfb7
go mod tidy
go mod vendor
Brings in fixes to cmd/vet for 'any' changes.
Change-Id: I70a48d451bd99f5d82f91fd079fbdd1b4bac2520
Reviewed-on: https://go-review.googlesource.com/c/go/+/370136
Trust: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Hana [Tue, 7 Dec 2021 22:50:50 +0000 (17:50 -0500)]
cmd/go: fix references to old `go mod editwork`
That is replaced by `go work edit`.
Change-Id: I39996c7bea0182a18edf6a1f70b6616c74099a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/370139 Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Michael Pratt [Mon, 6 Dec 2021 22:26:32 +0000 (17:26 -0500)]
runtime/pprof: assert that labelHog samples are always labeled
With https://golang.org/issue/50007 resolved, there are no known issues
with pprof labels remaining. Thus, the 10% allowed error in
TestLabelSystemstack should not be required.
Drop it in favor of an explicit assertion that all samples containing
labelHog are properly labeled.
This is no flaky in my local testing. It is possible that other bugs
will appear at larger testing scale, in which case this CL will be
reverted, but then at least we will be aware of additional failure
modes.
For #50007.
Change-Id: I1ef530c303bd9a01af649b8b08d4b35505e8aada
Reviewed-on: https://go-review.googlesource.com/c/go/+/369744 Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Michael Pratt [Mon, 6 Dec 2021 21:05:55 +0000 (16:05 -0500)]
runtime/pprof: consume tag for first CPU record
profBuf.write uses an index in b.tags for each entry, even if that entry
has no tag (that slice entry just remains 0). profBuf.read similarly
returns a tags slice with exactly as many entries as there are records
in data.
profileBuilder.addCPUData iterates through the tags in lockstep with the
data records. Except in the special case of the first record, where it
forgets to increment tags. Thus the first read of profiling data has all
tags off-by-one.
To help avoid regressions, addCPUData is changed to assert that tags
contains exactly the correct number of tags.
For #50007.
Change-Id: I5f32f93003297be8d6e33ad472c185d924a63256
Reviewed-on: https://go-review.googlesource.com/c/go/+/369741 Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Dan Scales [Tue, 7 Dec 2021 00:30:19 +0000 (16:30 -0800)]
cmd/compile: deal with unsatisfiable type assertion in some instantiations
Deal with case where a certain instantiation of a generic
function/method leads to an unsatisfiable type assertion or type case.
In that case, the compiler was causing a fatal error while trying to
create an impossible itab for the dictionary. To deal with that case,
allow ITabLsym() to create a dummy itab even when the concrete type
doesn't implement the interface. This dummy itab is analogous to the
"negative" itabs created on-the-fly by the runtime.
We will use the dummy itab in type asserts and type switches in
instantiations that use that dictionary entry. Since the dummy itab can
never be used for any real value at runtime (since the concrete type
doesn't implement the interface), there will always be a failure for the
corresponding type assertion or a non-match for the corresponding
type-switch case.
Fixes #50002
Change-Id: I1df05b1019533e1fc93dd7ab29f331a74fab9202
Reviewed-on: https://go-review.googlesource.com/c/go/+/369894 Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Katie Hockman [Wed, 1 Dec 2021 16:25:16 +0000 (11:25 -0500)]
internal/fuzz: handle unrecoverable errors during minimization
Previously, if an unrecoverable error occurred during
minimization, then the input that caused the failure
could not be retrieved by the coordinator. This was fine
if minimizing a crash, since the coordinator could simply
report the original error, and ignore the new one.
However, if an error occurred while minimizing an
interesting input, then we may lose an important error
that would be better to report.
This changes is a pretty major refactor of the minimization
logic in order to support this. It removes minimization
support of all types except []byte and string. There isn't
compelling evidence that minimizing types like int or float64
are actually beneficial, so removing this seems fine.
With this change, the coordinator requests that the worker
minimize a single value at a time. The worker updates shared
memory directly during minimzation, writing the *unmarshaled*
bytes to the shared memory region. If a nonrecoverable error occurs
during minimization, then the coordinator can get the
unmarshaled value out of shared memory for that type being
minimized.
Russ Cox [Mon, 6 Dec 2021 18:38:04 +0000 (13:38 -0500)]
cmd/link, cmd/go: make version info easier to extract
Reading the version information to date has required evaluating
two pointers to strings (which themselves contain pointers to data),
which means applying relocations, which can be very system-dependent.
To simplify the lookup, inline the string data into the build info blob.
This makes go version work on binaries built with external linking
on darwin/arm64.
Also test that at least the very basics work on a trivial binary,
even in short mode.
Jeremy Faller [Thu, 2 Dec 2021 18:47:39 +0000 (13:47 -0500)]
doc/go1.18: add docs for -count when benchmarking
CL 356669
Updates #47694
Change-Id: I49e0cdd3b34e81e9e44020a8eb1304d78249cd66
Reviewed-on: https://go-review.googlesource.com/c/go/+/368677
Trust: Jeremy Faller <jeremy@golang.org>
Run-TryBot: Jeremy Faller <jeremy@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Bryan C. Mills [Tue, 7 Dec 2021 03:09:12 +0000 (22:09 -0500)]
net/http: remove arbitrary timeout in TestServerHijackGetsBackgroundByte_big
This test fails with "timeout" once per couple of months.
It may be that the arbitrary timeout is too short,
or it may be that the test is detecting a real bug
(perhaps a deadlock) and reporting it without sufficient
information to debug.
Either way, the arbitrary timeout is doing only harm:
either it is too short, or it is preventing us from getting
a useful goroutine dump when the test inevitably times out.
Fixes #35498 (hopefully).
Change-Id: Ic6bbb1ef8df2c111b9888ba9903f58633e7cb95d
Reviewed-on: https://go-review.googlesource.com/c/go/+/369854
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Damien Neil <dneil@google.com>
Michael Anthony Knyszek [Tue, 7 Dec 2021 05:24:54 +0000 (00:24 -0500)]
runtime: fix comments on the behavior of SetGCPercent
Fixes for #49680, #49695, #45867, and #49370 all assumed that
SetGCPercent(-1) doesn't block until the GC's mark phase is done, but
it actually does. The cause of 3 of those 4 failures comes from the fact
that at the beginning of the sweep phase, the GC does try to preempt
every P once, and this may run concurrently with test code. In the
fourth case, the issue was likely that only *one* of the debug_test.go
tests was missing a call to SetGCPercent(-1). Just to be safe, leave a
TODO there for now to remove the extraneous runtime.GC calls, but leave
the calls in.
Updates #49680, #49695, #45867, and #49370.
Change-Id: Ibf4e64addfba18312526968bcf40f1f5d54eb3f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/369815 Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Bryan C. Mills [Mon, 6 Dec 2021 22:25:34 +0000 (17:25 -0500)]
cmd/go: fix tests broken in CL 358539
CL 358539 revised the build-stamp format, and updated the git and hg
tests to match. However, the fossil and bzr tests were missed, and
were not caught on the builders due to the fact that none of the
builder images have the necessary VCS tools installed.
Bryan C. Mills [Tue, 23 Nov 2021 15:27:30 +0000 (10:27 -0500)]
net: in (*netFD).dial, use the passed in local address if getsockname fails
'man getsockname' lists a number of possible failure modes, including
ENOBUFS (for resource exhaustion) and EBADF (which we could possibly
see in the event of a bug or race condition elsewhere in the program).
If getsockname fails for an explicit user-provided local address, the
user is probably not expecting LocalAddr on the returned net.Conn to
return nil. This may or may not fix #34611, but should at least help
us diagnose it more clearly.
While we're add it, also add more nil-checking logic in the test based
on the stack traces posted to
https://golang.org/issue/34611#issuecomment-975923748.
Cherry Mui [Mon, 6 Dec 2021 23:41:49 +0000 (18:41 -0500)]
cmd/dist: enable plugin test on Linux/ARM64
The test was skipped because with the old gold linker on the
builder it fails with an internal error in gold. The builders now
have gold 2.31 and the test passes. Enable it.
Fixes #17138.
Change-Id: Ia0054030dd12f1d003c7420bf7ed8b112715baa9
Reviewed-on: https://go-review.googlesource.com/c/go/+/369814
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Michael Anthony Knyszek [Mon, 6 Dec 2021 22:53:35 +0000 (17:53 -0500)]
runtime: clean up redundant calls to SetGCPercent in debug_test.go
SetGCPercent(-1) is called by several tests in debug_test.go (followed
by a call to runtime.GC) due to #49370. However, startDebugCallWorker
already actually has this, just without the runtime.GC call (allowing an
in-progress GC to still mess up the test).
This CL consolidates SetGCPercent into startDebugDebugCallWorker where
applicable.
Change-Id: Ifa12d6a911f1506e252d3ddf03004cf2ab3f4ee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/369751
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Michael Anthony Knyszek [Mon, 6 Dec 2021 22:35:58 +0000 (17:35 -0500)]
runtime: call runtime.GC in several tests that disable GC
These tests disable GC because of the potential for a deadlock, but
don't consider that a GC could be in progress due to other tests. The
likelihood of this case was increased when the minimum heap size was
lowered during the Go 1.18 cycle. The issue was then mitigated by
CL 368137 but in theory is always a problem.
This change is intended specifically for #45867, but I just walked over
a whole bunch of other tests that don't take this precaution where it
seems like it could be relevant (some tests it's not, like the
UserForcedGC test, or testprogs where no other code has run before it).
Fixes #45867.
Change-Id: I6a1b4ae73e05cab5a0b2d2cce14126bd13be0ba5
Reviewed-on: https://go-review.googlesource.com/c/go/+/369747 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: David Chase <drchase@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Bryan C. Mills [Tue, 23 Nov 2021 22:02:10 +0000 (17:02 -0500)]
log/syslog: create unix sockets in unique directories
startServer was invoking os.Remove on the temporary file for a unix
socket after creating it. Since the files were created in the global
temp directory, that could cause two tests to arrive at colliding
names.
(Noticed while looking into the failure at
https://storage.googleapis.com/go-build-log/af2c83b1/solaris-amd64-oraclerel_3e01fda8.log,
but I would be surprised if this solves that failure.)
This change uses unique temporary directories, and attempts to keep
name lengths minimal to avoid accidentally running into socket-name
length limitations.
Jeremy Faller [Thu, 2 Dec 2021 18:33:18 +0000 (13:33 -0500)]
doc/go1.18: add new sync.[RW]Mutex methods
CL 319769
Updates #47694
Change-Id: I9655af0d249926617645c33617d53b73f985aa19
Reviewed-on: https://go-review.googlesource.com/c/go/+/368797
Trust: Jeremy Faller <jeremy@golang.org>
Run-TryBot: Jeremy Faller <jeremy@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Jeremy Faller [Thu, 2 Dec 2021 18:22:46 +0000 (13:22 -0500)]
doc/go1.18: add changes to regexp to release notes
CL 354569
Updates #47694
Change-Id: I78536c110215b3c9f247c1420bcaa5fc3d8fb930
Reviewed-on: https://go-review.googlesource.com/c/go/+/368795
Trust: Jeremy Faller <jeremy@golang.org>
Run-TryBot: Jeremy Faller <jeremy@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Mon, 6 Dec 2021 18:33:54 +0000 (13:33 -0500)]
doc/go1.18: minor tweaks to generics section
This CL reorders the bullet points in the generics section to more
closely match what I think users will consider most important. I put
the ~ token before the mention of ~T in interfaces to avoid a forward
reference, though I wonder if we actually want to spent a couple more
sentences saying what union and ~T types are, since most people are
going to care about that a lot more than they care about the low-level
detail that there's a new token.
For #47694.
Change-Id: Ib84f096ef6346a711801268ce362b64fa423d3f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/369734
Trust: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
To prevent interleaving of output when 'go build' compiles several
packages in parallel, the output mutex in the Builder struct must
be locked around any calls to Builder.Print which could generate
arbitrary amounts of text (ie more than is guaranteed to be written
atomically to a pipe).
Michael Anthony Knyszek [Mon, 23 Aug 2021 17:27:40 +0000 (17:27 +0000)]
runtime: set iOS addr space to 40 bits with incremental pagealloc
In iOS <14, the address space is strictly limited to 8 GiB, or 33 bits.
As a result, the page allocator also assumes all heap memory lives in
this region. This is especially necessary because the page allocator has
a PROT_NONE mapping proportional to the size of the usable address
space, so this keeps that mapping very small.
However starting with iOS 14, this restriction is relaxed, and mmap may
start returning addresses outside of the <14 range. Today this means
that in iOS 14 and later, users experience an error in the page
allocator when a heap arena is mapped outside of the old range.
This change increases the ios/arm64 heapAddrBits to 40 while
simultaneously making ios/arm64 use the 64-bit pagealloc implementation
(with reservations and incremental mapping) to accommodate both iOS
versions <14 and 14+.
Once iOS <14 is deprecated, we can remove these exceptions and treat
ios/arm64 like any other arm64 platform.
This change also makes the BaseChunkIdx expression a little bit easier
to read, while we're here.
Fixes #46860.
Change-Id: I13865f799777739109585f14f1cc49d6d57e096b
Reviewed-on: https://go-review.googlesource.com/c/go/+/344401
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com>
Roi Martin [Tue, 30 Nov 2021 18:35:47 +0000 (19:35 +0100)]
cmd/go: update "go help doc" docs
This CL updates "go help doc" docs so they reflect the following
changes:
- CL 59413 modified "go doc", so the behavior of the two-args case is
consistent with the one-arg one.
- CL 141397 removed godoc's command-line interface in favor of "go doc".
Ian Lance Taylor [Sun, 5 Dec 2021 01:59:19 +0000 (17:59 -0800)]
test/ken/slicearray.go: correct type width in comment
The type was changed in https://golang.org/cl/3991043 but the comment
wasn't updated.
Change-Id: I7ba3f625c732e5e801675ffc5d4a28e1d310faa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/369374
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
Robert Griesemer [Sat, 4 Dec 2021 03:24:54 +0000 (19:24 -0800)]
doc/go1.18: expand section on generics
Also, move it up in the document.
Updates #47694
Change-Id: I927c4c845089a5c22e2c5b5f3de1831c04c6d990
Reviewed-on: https://go-review.googlesource.com/c/go/+/369102
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>