Russ Cox [Tue, 12 Dec 2023 17:53:32 +0000 (12:53 -0500)]
net: move cgo-using darwin test to separate package
It is a goal / requirement that nothing in the standard library
on darwin require cgo, and this test-only file makes net use
cgo on darwin. Move it elsewhere.
Change-Id: I6c11a8391d3913f73ce0098ba63b29adf5864f93
Reviewed-on: https://go-review.googlesource.com/c/go/+/549255 Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com> Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Russ Cox <rsc@golang.org>
Bryan C. Mills [Mon, 11 Dec 2023 21:45:04 +0000 (16:45 -0500)]
net: unskip and attempt to deflake TestAcceptTimeout
This test has been unconditionally skipped for over five years.
It may be that whatever was causing it to flake has been fixed.
And if it hasn't been fixed, it isn't providing any value.
Let's unskip it for the Go 1.23 development cycle and see what happens.
Let's also use a separate listener for each test case, so that a
leaked Dial goroutine from one case won't interfere with the other.
Fixes #17948 (maybe).
Change-Id: I239f22ca5d5a44388b9aa0ed4d81e451c6342617
Reviewed-on: https://go-review.googlesource.com/c/go/+/548940
Commit-Queue: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
qiulaidongfeng [Tue, 23 Jan 2024 00:42:58 +0000 (00:42 +0000)]
reflect: delete TODO pass safe to packEface don't need to copy if safe==true
valueInterface not copy result in the follow incorrect behavior
w1. x := ValueOf(&v).Elem()
r1. iface := Value.Interface()
w2. x.Set() or x.SetT()
The write operation of W2 will be observed by the read operation of r1,
but the existing behavior is not.
The valueInterface in deepValueEqual can, in theory, pass safe==true to not copy the object,
but there is no benchmark to indicate that the memory allocation has changed,
maybe we don't actually need safe==true here.
Change-Id: I55c423fd50adac8822a7fdbfe67af89ee223eace
GitHub-Last-Rev: 4a6386709817f3ea6055711dd39d2694d58b3043
GitHub-Pull-Request: golang/go#64618
Reviewed-on: https://go-review.googlesource.com/c/go/+/548436
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Keith Randall <khr@golang.org>
Bryan C. Mills [Mon, 22 Jan 2024 23:02:38 +0000 (18:02 -0500)]
net: report timeouts more aggressively in Accept in the fake implementation
This ensures that if the listener has already timed out when Accept
is called, Accept always returns an error instead of instantaneously
accepting a connection that was already pending.
For #17948.
Change-Id: Iabef7121590df3dcc2fe428429d7c2bc2bcb6cd5
Reviewed-on: https://go-review.googlesource.com/c/go/+/557438
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
qmuntal [Fri, 19 Jan 2024 13:14:17 +0000 (14:14 +0100)]
runtime,internal/poll: move websocket handling out of the runtime on Windows
On Windows, the netpoll is currently coupled with the websocket usage
in the internal/poll package.
This CL moves the websocket handling out of the runtime and puts it into
the internal/poll package, which already contains most of the async I/O
logic for websockets.
This is a good refactor per se, as the Go runtime shouldn't know about
websockets. In addition, it will make it easier (in a future CL) to only
load ws2_32.dll when the Go program actually uses websockets.
Change-Id: Ic820872cf9bdbbf092505ed7f7504edb6687735e
Reviewed-on: https://go-review.googlesource.com/c/go/+/556936
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Olivier Mengué [Mon, 15 Jan 2024 23:32:40 +0000 (00:32 +0100)]
hash/crc32: fix codegen to align with manual changes
Update gen_const_ppc64le.go to match the manual changes applied in
CL 478976.
Change-Id: I79a0d014a2a151750f898517b2771b312f3437bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/555996 Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Jorropo [Wed, 10 Jan 2024 06:31:57 +0000 (07:31 +0100)]
cmd/compile: improve integer comparisons with numeric bounds
This do:
- Fold always false or always true comparisons for ints and uint.
- Reduce < and <= where the true set is only one value to == with such value.
Change-Id: Ie9e3f70efd1845bef62db56543f051a50ad2532e
Reviewed-on: https://go-review.googlesource.com/c/go/+/555135
Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I92629a106b75b0526e9f2a8fe3cc4a6f7fc63c8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/518631
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: M Zhuo <mzh@golangcn.org> Reviewed-by: Wang Yaduo <wangyaduo@linux.alibaba.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Mark Ryan <markdryan@rivosinc.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Michael Anthony Knyszek [Mon, 22 Jan 2024 16:34:41 +0000 (16:34 +0000)]
runtime: use the correct M ID for syscalling goroutines in traces
Earlier in the development of the new tracer, m.id was used as a the
canonical ID for threads. Later, we switched to m.procid because it
matches the underlying OS resource. However, in that switch, we missed a
spot.
The tracer catches and emits statuses for goroutines that have remained
in either waiting or syscall across a whole generation, and emits a
thread ID for the latter set. The ID being used here, however, was m.id
instead of m.procid, like the rest of the tracer.
This CL also adds a regression test. In order to make the regression
test actually catch the failure, we also have to make the parser a
little less lenient about GoStatus events with GoSyscall: if this isn't
the first generation, then we should've seen the goroutine bound to an
M already when its status is getting emitted for its context. If we emit
the wrong ID, then we'll catch the issue when we emit the right ID when
the goroutine exits the syscall.
Fixes #65196.
Change-Id: I78b64fbea65308de5e1291c478a082a732a8bf9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/557456 Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Jin Lin [Wed, 20 Sep 2023 19:22:26 +0000 (12:22 -0700)]
cmd/preprofile: Add preprocess tool to pre-parse the profile file.
The pgo compilation time is very long if the profile file is large.
We added a preprocess tool to pre-parse profile file in order to
expedite the compile time.
Change-Id: I6f50bbd01f242448e2463607a9b63483c6ca9a12
Reviewed-on: https://go-review.googlesource.com/c/go/+/529738 Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Bryan C. Mills [Mon, 22 Jan 2024 18:54:56 +0000 (13:54 -0500)]
net: delete TestListenCloseListen
In CL 557177, I attempted to fix a logical race in this test (#65175).
However, I introduced a data race in the process (#65209).
The race was reported on the windows-amd64-race builder. When I tried
to reproduce it on linux/amd64, I added a time.Sleep in the Accept
loop. However, that Sleep causes the test to fail outright with
EADDRINUSE, which suggests that my earlier guess about the open Conn
preventing reuse of the port was, in fact, incorrect.
On some platforms we could instead use SO_REUSEPORT and avoid closing
the first Listener entirely, but that wouldn't be even remotely in the
spirit of the original test.
Since I don't see a way to preserve the test in a way that is not
inherently flaky / racy, I suggest that we just delete it. It was
originally added as a regression test for a bug in the nacl port,
which no longer exists anyway. (Some of that code may live on in the
wasm port, but it doesn't seem worth maintaining a flaky
port-independent test to maintain a regression test for a bug specific
to secondary platforms.)
Roland Shoemaker [Wed, 10 Jan 2024 19:02:14 +0000 (11:02 -0800)]
net/mail: properly handle special characters in phrase and obs-phrase
Fixes a couple of misalignments with RFC 5322 which introduce
significant diffs between (mostly) conformant parsers.
This change reverts the changes made in CL50911, which allowed certain
special RFC 5322 characters to appear unquoted in the "phrase" syntax.
It is unclear why this change was made in the first place, and created
a divergence from comformant parsers. In particular this resulted in
treating comments in display names incorrectly.
Additionally properly handle trailing malformed comments in the group
syntax.
Fixes #65083
Change-Id: I00dddc044c6ae3381154e43236632604c390f672
Reviewed-on: https://go-review.googlesource.com/c/go/+/555596 Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Austin Clements [Wed, 3 Jan 2024 15:41:09 +0000 (10:41 -0500)]
runtime: simplify freedefer logic
Currently, freedefer's API forces a subtle and fragile situation. It
requires that the caller unlink the _defer from the G list, but
freedefer itself is responsible for zeroing some _defer fields. In the
window between these two steps, we have to prevent stack growth
because stack growth walks the defer list (which no longer contains
the unlinked defer) to adjust pointers, and would thus leave an
unadjusted and potentially invalid pointer behind in the _defer before
freedefer zeroes it.
This setup puts part of this subtle responsibility on the caller and
also means freedefer must be nosplit, which forces other shenanigans
to avoid nosplit overflows.
We can simplify all of this by replacing freedefer with a new popDefer
function that's responsible for both unlinking and zeroing the _defer,
in addition to freeing it.
Some history: prior to regabi, defer records contained their argument
frame, which deferreturn copied to the stack before freeing the defer
record (and subsequently running the defer). Since that argument frame
didn't have a valid stack map until we ran the deferred function, the
non-preemptible window was much larger and more difficult to isolate.
Now we use normal closure calls to capture defer state and call the
defer, so the non-preemptible window is narrowed to just the unlinking
step.
Change-Id: I7cf95ba18e1e2e7d73f616b9ed9fb38f5e725d72
Reviewed-on: https://go-review.googlesource.com/c/go/+/553696 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Cherry Mui [Mon, 22 Jan 2024 16:47:50 +0000 (11:47 -0500)]
all: update vendored dependencies
The Go 1.23 development tree has opened. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
Generated with:
go install golang.org/x/build/cmd/updatestd@latest
go install golang.org/x/tools/cmd/bundle@latest
updatestd -goroot=$(pwd) -branch=master
For #36905.
Change-Id: I46a68f27a54f1e3f9e1aa5af4de6ee0b26388f3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/557457 Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
qmuntal [Fri, 19 Jan 2024 09:59:39 +0000 (10:59 +0100)]
runtime: avoid loading winmm.dll on newer Windows versions
winmm.dll is only used for timeBeginPeriod and timeEndPeriod, which are
not needed on Windows versions supporting high resolution timers, that
is Windows 10 version 1803, and later.
Updates #56745.
Change-Id: Ie9576638fb8d2b4e648283bec3170aefa76f9f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/556935 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Bryan C. Mills [Sat, 20 Jan 2024 00:05:53 +0000 (19:05 -0500)]
net: attempt to deflake TestListenCloseListen
Also make it flakier in longtest mode by burning through more
ephemeral ports. (Burning through the ports raised the failure rate
for me locally enough to reliably reproduce the failure in #65175 with
-count=10.)
Fixes #65175 (I hope).
Change-Id: I5f5b68b6bf6a6aa92e66f0288078817041656a3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/557177 Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Rob Findley [Sat, 6 Jan 2024 00:19:14 +0000 (19:19 -0500)]
go/types, types2: typeparams.IndexExpr must not be an ast.Expr
The typeparams.IndexExpr wrapper type was added as a compatibility layer
to make the go/types code symmetric with types2. However, this type
incidentally implemented the ast.Expr interface, leading to the
accidental misuse that led to golang/go#63933.
Fix this minimally for now, though leave a TODO that this old
compatibility shim really needs to be eliminated.
Also fix a case in types2 where operand.expr was set to a typed nil.
Fixes golang/go#63933
Change-Id: I180d411e52f795a8322ecce6ed8649e88af1c63b
Reviewed-on: https://go-review.googlesource.com/c/go/+/554395 Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Michael Anthony Knyszek [Thu, 11 Jan 2024 21:55:04 +0000 (21:55 +0000)]
runtime: make a much better effort to emit CPU profile in a trace
Currently the new execution tracer's handling of CPU profile samples is
very best-effort. The same CPU profile buffer is used across
generations, leading to a high probability that CPU samples will bleed
across generations. Also, because the CPU profile buffer (not the trace
buffer the samples get written into) isn't guaranteed to be flushed when
we close out a generation, nor when tracing stops. This has led to test
failures, but can more generally just lead to lost samples.
In general, lost samples are considered OK. The CPU profile buffer is
only read from every 100 ms, so if it fills up too much before then, old
samples will get overwritten. The tests already account for this, and in
that sense the CPU profile samples are already best-effort. But with
actual CPU profiles, this is really the only condition under which
samples are dropped.
This CL aims to align CPU profiles better with traces by eliminating
all best-effort parts of the implementation aside from the possibility
of dropped samples from a full buffer.
To achieve this, this CL adds a second CPU profile buffer and has the
SIGPROF handler pick which CPU profile buffer to use based on the
generation, much like every other part of the tracer. The SIGPROF
handler then reads the trace generation, but not before ensuring it
can't change: it grabs its own thread's trace seqlock. It's possible
that a SIGPROF signal lands while this seqlock is already held by the
thread. Luckily this is detectable and the SIGPROF handler can simply
elide the locking if this happens (the tracer will already wait until
all threads exit their seqlock critical section).
Now that there are two CPU profile buffers written to, the read side
needs to change. Instead of calling traceAcquire/traceRelease for every
single CPU sample event, the trace CPU profile reader goroutine holds
this conceptual lock over the entirety of flushing a buffer. This means
it can pick the CPU profile buffer for the current generation to flush.
With all this machinery in place, we're now at a point where all CPU
profile samples get divided into either the previous generation or the
current generation. This is good, since it means that we're able to
emit profile samples into the correct generation, avoiding surprises in
the final trace. All that's missing is to flush the CPU profile buffer
from the previous generation, once the runtime has moved on from that
generation. That is, when the generation counter updates, there may yet
be CPU profile samples sitting in the last generation's buffer. So,
traceCPUFlush now first flushes the CPU profile buffer, followed by any
trace buffers containing CPU profile samples.
The end result of all this is that no sample gets left behind unless it
gets overwritten in the CPU profile buffer in the first place. CPU
profile samples in the trace will now also get attributed to the right
generation, since the SIGPROF handler now participates in the tracer's
synchronization across trace generations.
Fixes #55317.
Change-Id: I47719fad164c544eef0bb12f99c8f3c15358e344
Reviewed-on: https://go-review.googlesource.com/c/go/+/555495
Auto-Submit: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Bryan C. Mills [Wed, 17 Jan 2024 20:00:40 +0000 (15:00 -0500)]
cmd/go/internal/modfetch: set protocol.version=2 for shallow git fetches
This works around an apparent bug in the Git HTTP backend, introduced
in Git 2.21, that causes responses for the version 1 protocol to
provide incomplete tags.
For Git commands older than 2.18, this configuration flag is ignored.
(Note that Git 2.29 and above already use protocol version 2 by
default.)
Damien Neil [Wed, 17 Jan 2024 19:59:10 +0000 (11:59 -0800)]
doc/go1.22: document net/netip changes
For #61422
Change-Id: Ide818366b035eada4ba04b70b4741fb1891585d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/556396
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Cuong Manh Le [Mon, 23 Oct 2023 03:56:57 +0000 (10:56 +0700)]
runtime: document GODEBUG panicnil values
Updates #25448
Change-Id: Ia1b7a376f5175f67e14ad4bd065d6e8ad5250d38
Reviewed-on: https://go-review.googlesource.com/c/go/+/536955 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Keith Randall <khr@golang.org>
Robert Griesemer [Wed, 17 Jan 2024 00:59:31 +0000 (16:59 -0800)]
cmd/compile: call types2.Unalias to be ready for GODEBUG=gotypesalias=1
types2.Unalias is not needed if we know we have a core or underlying
type. Also, types of declared functions (signatures) cannot be aliases
(this includes tuples).
Fixes #65125.
Change-Id: I1faa26b66f6c646719e830dd661136fae86f3775
Reviewed-on: https://go-review.googlesource.com/c/go/+/556036
Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Dominik Honnef [Wed, 27 Dec 2023 21:01:19 +0000 (22:01 +0100)]
internal/trace/v2: avoid several panics for malformed traces
This addresses some panics (out of bounds slice accesses and nil pointer
dereferences) when parsing malformed data. These were found via light
fuzzing, not by any rigorous means, and more potential panics probably
exist.
Fixes #64878.
Fixes #64879.
Change-Id: I4085788ba7dc91fec62e4abd88f50777577db42f
Reviewed-on: https://go-review.googlesource.com/c/go/+/552995
Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Most libraries don't consider N secret, but it's arguably useful for
privacy applications. However, E should generally be fixed, and there is
a lot of performance to be gained by using variable-time exponentiation.
Filippo Valsorda [Tue, 26 Dec 2023 22:21:34 +0000 (23:21 +0100)]
crypto/rsa: use E = 65537 in benchmarks
Now, this is embarrassing. For the whole Go 1.20 and Go 1.21 cycles, we
based RSA public key operation (verification and decryption) benchmarks
on the keys in rsa_test.go, which had E = 3. Most keys in use, including
all those generated by GenerateKey, have E = 65537. This significantly
skewed even relative benchmarks, because the new constant-time
algorithms would incur a larger slowdown for larger exponents.
I noticed this only because I got a production profile for an
application that does a lot of RSA verifications, saw ExpShort show up,
made ExpShort faster, and the crypto/rsa profiles didn't move.
We were measuring the wrong thing, and the slowdown was worse than we
thought. My apologies.
(If E had not been parametrized, it would have avoided issues like this
one, too. Grumble. https://words.filippo.io/parameters/#fn9)
Keith Randall [Thu, 11 Jan 2024 20:52:16 +0000 (12:52 -0800)]
runtime: ensure we free unrolled GC bitmaps
CL 555355 has a bug in it - the GC program flag was also used to decide
when to free the unrolled bitmap. After that CL, we just don't free any
unrolled bitmaps, leading to a memory leak.
Use a separate flag to track types that need to be freed when their
corresponding object is freed.
Change-Id: I841b65492561f5b5e1853875fbd8e8a872205a84
Reviewed-on: https://go-review.googlesource.com/c/go/+/555416
Auto-Submit: Keith Randall <khr@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Robert Griesemer [Wed, 10 Jan 2024 23:49:33 +0000 (15:49 -0800)]
go/types, types2: don't lose position info of interface embeddings
Accurate position information for embedded types in interfaces is
crucial to identify the corresponding source file, and with that
the Go language version associated with that file. (The position
information is also important for proper error messages.)
Before this CL, the position information for embedded types was
discarded after type set computation, in the assumption that it
was not needed anymore. However, substitutions that update the
interface may lead to repeated type set computations which then
won't have the correct position information.
This CL does preserve the position information for embedded
types until the end of type checking (cleanup phase), and also
copy the position information during a substitution of the
interface.
The respective bug (#64759) doesn't seem to appear in 1.22 (most
likely because it's hidden by some of the changes made with respect
to the file version logic), but the existing code is still wrong.
The backport of this code to 1.21 and 1.20 fixes the issue in those
releases.
For #64759.
Change-Id: I80f4004c9d79cb02eac6739c324c477706615102
Reviewed-on: https://go-review.googlesource.com/c/go/+/555296
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Bryan C. Mills [Mon, 8 Jan 2024 22:20:14 +0000 (17:20 -0500)]
os: relax tests and add examples for UserCacheDir and UserConfigDir
Per https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html:
“If, when attempting to write a file, the destination directory is
non-existent an attempt should be made to create it with permission
0700. […] The application should be prepared to handle the case where
the file could not be written […]. In such case it may choose to
present an error message to the user.”
In certain CI environments, these directories have well-defined
locations but do not exist and cannot be created. In that case,
we now choose to log and return from the test without failing it.
To prevent the functions from falling back to being entirely untested,
we still fail the test (and “present an error message to the user”) if
either function returns an empty string without an error, or returns a
path that refers to a non-directory or results in an error other than
ErrNotExist.
In addition, since the tests themselves no longer create subdirectories,
we add examples illustrating the suggested pattern of usage.
Than McIntosh [Tue, 9 Jan 2024 15:06:15 +0000 (15:06 +0000)]
cmd/compile: use hashed symbol name for go.shape types if too long
Shape-based stenciling in the Go compiler's generic instantiation
phase looks up shape types using the underlying type of a given target
type. This has a beneficial effect in most cases (e.g. we can use the
same shape type for two different named types whose underlying type is
"int"), but causes some problems when the underlying type is a very
large structure. The link string for the underlying type of a large
imported struct can be extremely long, since the link string
essentially enumerates the full package path for every field type;
this can produce a "go.shape.struct { ... " symbol name that is
absurdly long.
This patch switches the compiler to use a hash of the underlying type
link string instead of the string itself, which should continue to
provide commoning but keep symbol name lengths reasonable for shape
types based on large imported structs.
Fixes #65030.
Change-Id: I87d602626c43172beb99c186b8ef72327b8227a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/554975
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Than McIntosh <thanm@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Michael Pratt [Tue, 9 Jan 2024 18:13:45 +0000 (13:13 -0500)]
runtime: replace rwmutexR/W with per-rwmutex lock rank
CL 549536 intended to decouple the internal implementation of rwmutex
from the semantic meaning of an rwmutex read/write lock in the static
lock ranking.
Unfortunately, it was not thought through well enough. The internals
were represented with the rwmutexR and rwmutexW lock ranks. The idea was
that the internal lock ranks need not model the higher-level ordering,
since those have separate rankings. That is incorrect; rwmutexW is held
for the duration of a write lock, so it must be ranked before any lock
taken while any write lock is held, which is precisely what we were
trying to avoid.
This is visible in violations like:
0 : execW 11 0x0
1 : rwmutexW 51 0x111d9c8
2 : fin 30 0x111d3a0
fatal error: lock ordering problem
execW < fin is modeled, but rwmutexW < fin is missing.
Fix this by eliminating the rwmutexR/W lock ranks shared across
different types of rwmutex. Instead require users to define an
additional "internal" lock rank to represent the implementation details
of rwmutex.rLock. We can avoid an additional "internal" lock rank for
rwmutex.wLock because the existing writeRank has the same semantics for
semantic and internal locking. i.e., writeRank is held for the duration
of a write lock, which is exactly how rwmutex.wLock is used, so we can
use writeRank directly on wLock.
For #64722.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-staticlockranking
Change-Id: Ia572de188a46ba8fe054ae28537648beaa16b12c
Reviewed-on: https://go-review.googlesource.com/c/go/+/555055
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Roger Peppe [Fri, 5 Jan 2024 12:47:56 +0000 (12:47 +0000)]
io/fs,path/filepath: fix typo in SkipAll/SkipDir doc
Also make the reference into a doc link.
Change-Id: Ib112307a65b65c8f963abf60aa92cb1942de940c
Reviewed-on: https://go-review.googlesource.com/c/go/+/554295 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Mauri de Souza Meneguzzo [Sat, 2 Dec 2023 15:11:36 +0000 (15:11 +0000)]
net: clarify maxListenerBacklog windows implementation
The previous TODO comments were somewhat ambiguous. This aims to
provide a clearer understanding of the behavior on Windows.
Windows does not offer a way to peek at the current backlog length, this
is explicitly stated in the winapi for `listen`.
When set to `syscall.SOMAXCONN`, the OS dynamically adjusts the
backlog to a maximum reasonable value. It goes as far as the dotnet
runtime itself introducing a new version of `listen` that does not accept a
backlog parameter to help eliminate the confusion when comparing the
behavior with UNIXes.
The docs also mention that `SOMAXCONN_HINT(N)` can be used, and that
it clips the final computed value between (200, 65535), which suggests
windows might use a `uint16` to back this number. Either way it does not
matter since windows will adjust this value anyway, so I removed the
wrapping TODO as well.
See https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen
Change-Id: I7b2e7cb547467c4bfc572ef0477a58de8c772521
GitHub-Last-Rev: 34e74abffe8792c8709c73db4d7a5fa05f64b1d0
GitHub-Pull-Request: golang/go#63549
Reviewed-on: https://go-review.googlesource.com/c/go/+/535475 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Than McIntosh [Thu, 21 Dec 2023 13:21:59 +0000 (08:21 -0500)]
cmd/go: run cover tool before swig
When building a package, run the cover tool on the collected go/cgo
source files before invoking swig (if swig files are present), as
opposed to running swig and then cover. Running swig adds new Go files
to the "cgo" list, and we want to avoid running those newly generated
files through the cover tool.
Fixes #64661.
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Change-Id: I32b6dad5c39fcf5e656c40fb3b44220c69320889
Reviewed-on: https://go-review.googlesource.com/c/go/+/552095
Auto-Submit: Than McIntosh <thanm@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Bryan C. Mills [Thu, 4 Jan 2024 16:41:54 +0000 (11:41 -0500)]
net/http/cgi: in TestCopyError, check for a Handler.ServeHTTP goroutine instead of a running PID
Previously, the test could fail spuriously if the CGI process's PID
happened to be reused in between checks. That sort of reuse is highly
unlikely on platforms that cycle through the PID space sequentially
(such as Linux), but plausible on platforms that use randomized PIDs
(such as OpenBSD).
Also unskip the test on Windows, since it no longer relies on being
able to send signal 0 to an arbitrary PID.
Also change the expected failure mode of the test to a timeout instead
of a call to t.Fatalf, so that on failure we get a useful goroutine
dump for debugging instead of a non-actionable failure message.
Fixes #57369 (maybe).
Change-Id: Ib7e3fff556450b48cb5e6ea120fdf4d53547479b
Reviewed-on: https://go-review.googlesource.com/c/go/+/554075
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
Devon H. O'Dell [Thu, 4 Jan 2024 16:49:17 +0000 (11:49 -0500)]
cmd/api: fix panic on exported basic type aliases
The order of emitting named type and type aliases in the `Walker`'s
`emitType` function is inverted. When the type alias references a basic
type, this causes a panic as the type assertion on `*types.Named` fails.
This change reorders the logic such that type aliases are emitted prior
to this type assertion.
Jes Cok [Wed, 3 Jan 2024 04:18:15 +0000 (04:18 +0000)]
net/http: make Request.Clone create fresh copies for matches and otherValues
This change fixes Request.Clone to correctly work with SetPathValue
by creating fresh copies for matches and otherValues so that
SetPathValue for cloned requests doesn't pollute the original request.
While here, also added a doc for Request.SetPathValue.
Fixes #64911
Change-Id: I2831b38e135935dfaea2b939bb9db554c75b65ef
GitHub-Last-Rev: 1981db16475a49fe8d4b874a6bceec64d28a1332
GitHub-Pull-Request: golang/go#64913
Reviewed-on: https://go-review.googlesource.com/c/go/+/553375 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Jes Cok <xigua67damn@gmail.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Joel Sing [Fri, 29 Dec 2023 11:56:58 +0000 (22:56 +1100)]
runtime: correct scavengeIndex.sysGrow min index handling
The backing store for the scavengeIndex chunks slice is allocated on demand
as page allocation occurs. When pageAlloc.grow is called, a range is
allocated from a reserved region, before scavengeIndex.grow is called
to ensure that the chunks needed to manage this new range have a valid
backing store. The valid region for chunks is recorded as the index min
and index max. Any changes need to take the existing valid range into
consideration and ensure that a contiguous valid range is maintained.
However, a bug in the min index handling can currently lead to an existing
part of the chunk slice backing store being zeroed via remapping. Initially,
there is no backing store allocated and both min and max are zero. As soon
as an allocation occurs max will be non-zero, however it is still valid for
min to be zero depending on the base addresses of the page allocations. A
sequence like the following will trigger the bug:
1. A page allocation occurs requiring chunks [0, 512) (after rounding) - a
sysMap occurs for the backing store, min is set to 0 and max is set
to 512.
2. A page allocation occurs requiring chunks [512, 1024) - another sysMap
occurs for this part of the backing store, max is set to 1024, however
min is incorrectly set to 512, since haveMin == 0 (validly).
3. Another page allocation occurs requiring chunks [0, 512) - since min is
currently 512 a sysMap occurs for the already mapped and inuse part
of the backing store from [0, 512), zeroing the chunk data.
Correct this by only updating min when either haveMax == 0 (the
uninitialised case) or when needMin < haveMin (the case where the new
backing store range is actually below the current allocation). Remove
the unnecessary haveMax == 0 check for updating max, as the existing
needMax > haveMax case already covers this.
Fixes #63385
Change-Id: I9deed74c4ffa187c98286fe7110e5d735e81f35f
Reviewed-on: https://go-review.googlesource.com/c/go/+/553135 Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Robert Griesemer [Wed, 27 Dec 2023 05:17:04 +0000 (21:17 -0800)]
doc: fix typo in example in spec
Follow-up on CL 551095.
For #56010.
Change-Id: I8913d6ca96c419c81683e88c6286b05ae1323416
Reviewed-on: https://go-review.googlesource.com/c/go/+/552915
TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Robert Griesemer [Tue, 19 Dec 2023 01:09:18 +0000 (17:09 -0800)]
doc: document new iteration variable semantics in spec
For #56010.
Change-Id: Icca987a03d80587dd0e901f596ff7788584893ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/551095 Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Cherry Mui [Wed, 20 Dec 2023 19:33:46 +0000 (14:33 -0500)]
runtime: use racereleasemerge for godebugInc
CL 549796 adds race annotations to godebugInc. It uses racerelease
to model a CompareAndSwap. However, a CompareAndSwap is
essentially a load and a store. Modeling it as just racerelease
makes it not synchronized with other racerelease, i.e. other CAS.
For the following execution
thread A B
load, got nil
load, got nil
set *inc
set *inc
racerelease
CAS success
racerelease
CAS fail
load
raceacquire
use *inc (from A)
On thread B, the raceacquire synchronizes with the previous
racerelease, which is not synchronized with racerelease on thread
A, so it doesn't know that the use of *inc on thread B is after
the set on thread A, and will report a race.
Change it to use racereleasemerge, which synchronizes with
previous racerelease and racereleasemerge. So in the case above it
knows thread B's CAS is after thread A's.
Also remove stale comment that was more relevant when the code
used atomic store, where CL 549796 changed to CAS.
Updates #64649.
Change-Id: I17671090a19c0699fcb4e6481e2abd98ef2e5542
Reviewed-on: https://go-review.googlesource.com/c/go/+/551856 Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
Tim King [Tue, 19 Dec 2023 18:08:00 +0000 (10:08 -0800)]
doc/go1.22: document changes to vet loopclosure analyzer
cmd/vet no longer reports loopclosure bugs within files built at
GoVersion>=1.22.
For #61422.
Change-Id: I6f29373bb236822ece4e7ae35914859538b8d57b
Reviewed-on: https://go-review.googlesource.com/c/go/+/551376
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Tim King <taking@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Robert Griesemer [Tue, 19 Dec 2023 21:32:07 +0000 (13:32 -0800)]
doc: update unsafe.Pointer rule in spec
The valid conversions consider the core types of operands, not just
their underlying type.
This also explains the valid arguments for unsafe.Slice which are
explained in terms of unsafe.Pointer conversions.
unsafe.SliceData simply refers to "slice argument" and we use
similar terminology elsewhere in the spec to denote values that
have a core type of slice (or any other type for that matter).
Leaving alone for now.
Fixes #64452.
Change-Id: I0eed3abbc0606f22358835e5d434f026fe0909c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/551379
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Robert Griesemer <gri@google.com>
Than McIntosh [Tue, 19 Dec 2023 15:32:52 +0000 (10:32 -0500)]
doc: comment out remaining TODOs in Go 1.22 relnotes (for now)
This patch comments out the remaining "TODO" items in the Go 1.22
release notes temporarily, so as to have RC1 go out with the notes
in a clean (TODO-less) state.
Change-Id: I88f5fef75860fc78b8077dce704ae71c6194a6a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/551257 Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Than McIntosh <thanm@google.com>