When sending a request with an "Expect: 100-continue" header,
we must send the request body before sending any further requests
on the connection.
When receiving a non-1xx response to an "Expect: 100-continue" request,
send the request body if the connection isn't being closed after
processing the response. In other words, if either the request
or response contains a "Connection: close" header, then skip sending
the request body (because the connection will not be used for
further requests), but otherwise send it.
Correct a comment on the server-side Expect: 100-continue handling
that implied sending the request body is optional. It isn't.
For #67555Fixes#68199
Change-Id: Ia2f12091bee697771087f32ac347509ec5922d54
Reviewed-on: https://go-review.googlesource.com/c/go/+/591255
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
(cherry picked from commit cf501e05e1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/595096
Reviewed-by: Joedian Reid <joedian@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
callbackUpdateSystemStack contains a fast path to exit early without
update if SP is already within the g0.stack bounds.
This is not safe, as a subsequent call may have new stack bounds that
only partially overlap the old stack bounds. In this case it is possible
to see an SP that is in the old stack bounds, but very close to the
bottom of the bounds due to the partial overlap. In that case we're very
likely to "run out" of space on the system stack.
We only need to do this on extra Ms, as normal Ms have precise bounds
defined when we allocated the stack.
TSAN annotations are added to x_cgo_getstackbounds because bounds is a
pointer into the Go stack. The stack can be reused when an old thread
exits and a new thread starts, but TSAN can't see the synchronization
there. This isn't a new case, but we are now calling more often.
For #62440.
Fixes#67297.
Cq-Include-Trybots: luci.golang.try:go1.21-linux-amd64-longtest
Change-Id: I5389050494987b7668d0b317fb92f85e61d798ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/584597
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 1ffc296717)
Reviewed-on: https://go-review.googlesource.com/c/go/+/585337
For whatever reason, on the builders, when using /usr/bin/ld (the
default linker) with -flto we end up with problems. Specifically, the
linker seems to require LLVMgold.so and can't find it. I'm not really
sure why, but what definitely seems to work is forcing use of lld, which
ships with our clang installation on the builders.
Just enforce this on the builders for now; I've actually had very few
problems running this locally (and I think I'm also mixing and matching
linkers and toolchains too...), so it may be related to the version of
clang we're testing with.
For #67698.
For #67714.
Change-Id: I3bfbcd609e7d0fd70e52ac7e2a0817db95664f20
Cq-Include-Trybots: luci.golang.try:go1.21-linux-amd64-clang15,go1.21-linux-386-clang15
Reviewed-on: https://go-review.googlesource.com/c/go/+/589296
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/591377
Currently the runtime.end symbol is put into the noptrbss section,
which is usually the last section, except that when fuzzing is
enabled, the last section is actually .go.fuzzcntrs. The
runtime.end symbol has the value pointing to the end of the data
segment, so if it is not in the last section, the value will not
actually be in the range of the section. This causes an assertion
failure in the new Apple linker. This CL fixes this by putting it
in the last section.
Updates #65169.
Fixes#67944.
Change-Id: I5c991c46a0483a96e5f6e0255a3b444953676026
Reviewed-on: https://go-review.googlesource.com/c/go/+/592095
Reviewed-by: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit b589478af7)
Reviewed-on: https://go-review.googlesource.com/c/go/+/592477
Since all the platforms now support O_DIRECTORY flag for open, it can be
used to (together with O_NOFOLLOW) to ensure we open a directory, thus
eliminating the need to call stat before open. This fixes the symlink race,
when a directory is replaced by a symlink in between stat and open calls.
While at it, rename openFdAt to openDirAt, because this function is (and was)
meant for directories only.
NOTE Solaris supports O_DIRECTORY since before Solaris 11 (which is the
only version Go supports since supported version now), and Illumos
always had it. The only missing piece was O_DIRECTORY flag value, which
is taken from golang.org/x/sys/unix.
Fixes#67695.
Change-Id: Ic1111d688eebc8804a87d39d3261c2a6eb33f176
Reviewed-on: https://go-review.googlesource.com/c/go/+/589057
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
This CL modifies the download behavior when downloading a toolchain for 1.21+. Previously, Go would attempt to download 1.X when upgrading the toolchain which would cause the download to fail for 1.21+ since 1.X is an invalid toolchain. We will attempt to download 1.X.0 since that's likely what the user intended.
Additionally, we will also now provide a better error message when the
user provides a language version instead of a toolchain version for
1.21+.
For #66175
For #62278Fixes#67235
Change-Id: I28f894290a19d8e3cd220e9d70aeca8f4447e5a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/580217
Reviewed-by: Michael Matloob <matloob@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 27ed85d4d1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/583797
[This is a re-apply of CL 571075]
Imported interfaces don't have position information for embedded types.
When computing the type set of such interfaces, doing a version check
may fail because it will rely on the Go version of the current package.
We must not do a version check for features of types from imported
packages - those types have already been typechecked and are "correct".
The version check code does look at packages to avoid such incorrect
version checks, but we don't have the package information available
in an interface type (divorced from its object).
Instead, for now rely on the fact that imported interfaces don't have
position information for embedded types: if the position is unknown,
don't do a version check.
We may want to assert that positions are known in all other cases,
but since this is an older release, don't add such additional changes
to avoid introducing other bugs.
Fixes#66326.
Updates #66064.
Change-Id: I158cf51aa382f85d612ab958ba4b591de1c5fdb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/574736
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Imported interfaces don't have position information for embedded types.
When computing the type set of such interfaces, doing a version check
may fail because it will rely on the Go version of the current package.
We must not do a version check for features of types from imported
packages - those types have already been typechecked and are "correct".
The version check code does look at packages to avoid such incorrect
version checks, but we don't have the package information available
in an interface type (divorced from its object).
Instead, for now rely on the fact that imported interfaces don't have
position information for embedded types: if the position is unknown,
don't do a version check.
We may want to assert that positions are known in all other cases,
but since this is an older release, don't add such additional changes
to avoid introducing other bugs.
Fixes#66064.
Change-Id: I773d57e5410c3d4a911ab3e018b3233c2972b3c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/571075
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Also fix its call site in internal/poll to pass the length of the
actual buffer instead of an unrelated variable, and update the
definition of FILE_BASIC_INFO to match the documented field types
and add padding that is empirically needed on the 386 architecture.
Passing a pointer to a Go-allocated buffer as type uintptr violates
the unsafe.Pointer conversion rules, which allow such a conversion
only in the call expression itself for a call to syscall.Syscall or
equivalent. That can allow the buffer to be corrupted arbitrarily if
the Go runtime happens to garbage-collect it while the call to
SetFileInformationByHandle is in progress.
The Microsoft documentation for SetFileInformationByHandle specifies
its third argument type as LPVOID, which corresponds to Go's
unsafe.Pointer, not uintptr.
Fixes#65882.
Updates #58933.
Change-Id: If577b57adea9922f5fcca55e46030c703d8f035c
Cq-Include-Trybots: luci.golang.try:go1.21-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/549256
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
(cherry picked from commit a7097243e4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/566155
Reviewed-by: Bryan Mills <bcmills@google.com>
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.
For #65083Fixes#65848
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>
Reviewed-on: https://go-review.googlesource.com/c/go/+/566195
Reviewed-by: Carlos Amedee <carlos@golang.org>
This change fixes a bug where we incorrectly filtered out the main
modules from the beginning of the build list before verifying them. We
made the assumption that the first MainModules.Len() entries of the
build list were the main modules, but now it can contain the go and
toolchain version entries, so removing the first MainModules.Len()
entries could leave main module names in the build list if any of
their names sorted after the string 'go'.
For #62663Fixes#65851
Change-Id: I35ab6857a556f58d306303322afe24c48fc8b38f
Reviewed-on: https://go-review.googlesource.com/c/go/+/565378
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 3f60da7944)
Reviewed-on: https://go-review.googlesource.com/c/go/+/565755
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
testenv's TestHasGoBuild test is supposed to allow noopt builders to not
have go build, but the pattern match is failing on the LUCI builders
where a test shard might have an additional "-test_only" suffix in the
builder name. Furthermore, in the LUCI world, "run mods" (the builder
type suffixes) are supposed to be well-defined and composable, so it
doesn't make sense to restrict "-noopt" to the builder suffix anyway.
This change modifies the test to allow "-noopt" to appear anywhere in
the builder name when checking if it's running on a noopt builder.
For #65470.
Fixes#65472.
Change-Id: I393818e3e8e452c7b0927cbc65726d552aa8ff8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/558596
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
(cherry picked from commit 93f0c0b25e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/560518
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.
Fixes#65053.
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>
Reviewed-on: https://go-review.googlesource.com/c/go/+/555415
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(This cherry-pick combines CL 549536 and the follow-up fix CL 555055.)
Currently, lock ranking doesn't really try to model rwmutex. It records
the internal locks rLock and wLock, but in a subpar fashion:
1. wLock is held from lock to unlock, so it works OK, but it conflates
write locks of all rwmutexes as rwmutexW, rather than allowing
different rwmutexes to have different rankings.
2. rLock is an internal implementation detail that is only taken when
there is contention in rlock. As as result, the reader lock path is
almost never checked.
Add proper modeling. rwmutexR and rwmutexW remain as the ranks of the
internal locks, which have their own ordering. The new init method is
passed the ranks of the higher level lock that this represents, just
like lockInit for mutex.
execW ordered before MALLOC captures the case from #64722. i.e., there
can be allocation between BeforeFork and AfterFork.
For #64722.
Fixes#64761.
------
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:go1.21-linux-amd64-staticlockranking
Change-Id: I23335b28faa42fb04f1bc9da02fdf54d1616cd28
Reviewed-on: https://go-review.googlesource.com/c/go/+/549536
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit 9b4b3e5acc)
(cherry picked from commit dcbe772469)
Reviewed-on: https://go-review.googlesource.com/c/go/+/554976
After CL 527715, needm uses callbackUpdateSystemStack to set the stack
bounds for g0 on an M from the extra M list. Since
callbackUpdateSystemStack is also used for recursive cgocallback, it
does nothing if the stack is already in bounds.
Currently, the stack bounds in an extra M may contain stale bounds from
a previous thread that used this M and then returned it to the extra
list in dropm.
Typically a new thread will not have an overlapping stack with an old
thread, but because the old thread has exited there is a small chance
that the C memory allocator will allocate the new thread's stack
partially or fully overlapping with the old thread's stack.
If this occurs, then callbackUpdateSystemStack will not update the stack
bounds. If in addition, the overlap is partial such that SP on
cgocallback is close to the recorded stack lower bound, then Go may
quickly "overflow" the stack and crash with "morestack on g0".
Fix this by clearing the stack bounds in dropm, which ensures that
callbackUpdateSystemStack will unconditionally update the bounds in
needm.
For #62440.
Fixes#63209.
Change-Id: Ic9e2052c2090dd679ed716d1a23a86d66cbcada7
Reviewed-on: https://go-review.googlesource.com/c/go/+/537695
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
(cherry picked from commit 1af424c196)
Reviewed-on: https://go-review.googlesource.com/c/go/+/549495
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
[This cherry-pick combines CL 527715, CL 527775, CL 527797, and
CL 529216.]
[This is a redo of CL 525455 with the test fixed on darwin by defining
_XOPEN_SOURCE, and disabled with android, musl, and openbsd, which do
not provide getcontext.]
Since CL 495855, Ms are cached for C threads calling into Go, including
the stack bounds of the system stack.
Some C libraries (e.g., coroutine libraries) do manual stack management
and may change stacks between calls to Go on the same thread.
Changing the stack if there is more Go up the stack would be
problematic. But if the calls are completely independent there is no
particular reason for Go to care about the changing stack boundary.
Thus, this CL allows the stack bounds to change in such cases. The
primary downside here (besides additional complexity) is that normal
systems that do not manipulate the stack may not notice unintentional
stack corruption as quickly as before.
Note that callbackUpdateSystemStack is written to be usable for the
initial setup in needm as well as updating the stack in cgocallbackg.
For #62440.
For #62130.
For #63209.
Change-Id: I0fe0134f865932bbaff1fc0da377c35c013bd768
Reviewed-on: https://go-review.googlesource.com/c/go/+/527715
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit 4f9fe6d509)
(cherry picked from commit e8ba0579e2)
(cherry picked from commit a843991fdd)
(cherry picked from commit d110d7c42d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/530480
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Michael Pratt <mpratt@google.com>
The system stack often starts with a stack transition function
like "systemstack" or "mcall", which is marked as SPWRITE. When
unwinding a system stack for printing, we want the traceback stop
at the stack switching frame, but not print the "unexpected
SPWRITE" message.
Previously before CL 525835, we don't print the "unexpected
SPWRITE" message if unwindPrintErrors is set, i.e. printing a
stack trace. This CL restores this behavior.
Another possibility is not printing the message only on the system
stack. We don't expect a stack transition function to appear in a
user G.
Fixes#64935.
Change-Id: I173e89ead2cd4fbf1f0f8cca225f28718b5baebe
Reviewed-on: https://go-review.googlesource.com/c/go/+/531815
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 15a274b621)
Reviewed-on: https://go-review.googlesource.com/c/go/+/553476
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
ReadMemStats has a few assertions it makes about the consistency of the
stats it's about to produce. Specifically, how those stats line up with
runtime-internal stats. These checks are generally useful, but crashing
just because some stats are wrong is a heavy price to pay.
For a long time this wasn't a problem, but very recently it became a
real problem. It turns out that there's real benign skew that can happen
wherein sysmon (which doesn't synchronize with a STW) generates a trace
event when tracing is enabled, and may mutate some stats while
ReadMemStats is running its checks.
Fix this by synchronizing with both sysmon and the tracer. This is a bit
heavy-handed, but better that than false positives.
Also, put the checks behind a debug mode. We want to reduce the risk of
backporting this change, and again, it's not great to crash just because
user-facing stats are off. Still, enable this debug mode during the
runtime tests so we don't lose quite as much coverage from disabling
these checks by default.
For #64401.
Fixes#64410.
Change-Id: I9adb3e5c7161d207648d07373a11da8a5f0fda9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/545277
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
(cherry picked from commit b2efd1de97)
Reviewed-on: https://go-review.googlesource.com/c/go/+/545557
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Bypass: Matthew Dempsky <mdempsky@google.com>
Go 1.21.1 and Go 1.22 have ceased working around an issue with Linux
kernel defaults for transparent huge pages that can result in excessive
memory overheads. (https://bugzilla.kernel.org/show_bug.cgi?id=93111)
Many Linux distributions disable huge pages altogether these days, so
this problem isn't quite as far-reaching as it used to be. Also, the
problem only affects Go programs with very particular memory usage
patterns.
That being said, because the runtime used to actively deal with this
problem (but with some unpredictable behavior), it's preventing users
that don't have a lot of control over their execution environment from
upgrading to Go beyond Go 1.20.
This change adds a GODEBUG to smooth over the transition. The GODEBUG
setting disables transparent huge pages for all heap memory on Linux,
which is much more predictable than restoring the old behavior.
For #64332.
Fixes#64561.
Change-Id: I73b1894337f0f0b1a5a17b90da1221e118e0b145
Reviewed-on: https://go-review.googlesource.com/c/go/+/547475
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>
(cherry picked from commit c915215af6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/547636
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
TryBot-Bypass: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Since CL 226138, TestNohup has a bit of a strange construction: it wants
to run the "uncaught" subtests in parallel with each other, and the
"nohup" subtests in parallel with each other, but also needs join
between "uncaught" and "nohop" so it can Stop notifying for SIGHUP.
It achieves this by doing `go t.Run` with a WaitGroup rather than using
`t.Parallel` in the subtest (which would make `t.Run` return immediately).
However, this makes things more difficult to understand than necessary.
As noted on https://pkg.go.dev/testing#hdr-Subtests_and_Sub_benchmarks,
a second layer of subtest can be used to join parallel subtests.
Switch to this form, which makes the test simpler to follow
(particularly the cleanup that goes with "uncaught").
For #63799.
For #63911.
Change-Id: Ibfce0f439508a7cfca848c7ccfd136c9c453ad8b
Reviewed-on: https://go-review.googlesource.com/c/go/+/538899
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
(cherry picked from commit 5622a4b205)
Reviewed-on: https://go-review.googlesource.com/c/go/+/546021
Prior to CL 460595, Lstat reported most reparse points as regular
files. However, reparse points can in general implement unusual
behaviors (consider IO_REPARSE_TAG_AF_UNIX or IO_REPARSE_TAG_LX_CHR),
and Windows allows arbitrary user-defined reparse points, so in
general we must not assume that an unrecognized reparse tag represents
a regular file; in CL 460595, we began marking them as irregular.
As it turns out, the Data Deduplication service on Windows Server runs
an Optimization job that turns regular files into reparse files with
the tag IO_REPARSE_TAG_DEDUP. Those files still behave more-or-less
like regular files, in that they have well-defined sizes and support
random-access reads and writes, so most programs can treat them as
regular files without difficulty. However, they are still reparse
files: as a result, on servers with the Data Deduplication service
enabled, files could arbitrarily change from “regular” to “irregular”
without explicit user intervention.
Since dedup files are converted in the background and otherwise behave
like regular files, this change adds a special case to report DEDUP
reparse points as regular.
Fixes#63764.
Updates #63429.
No test because to my knowledge we don't have any Windows builders
that have the deduplication service enabled, nor do we have a way to
reliably guarantee the existence of an IO_REPARSE_TAG_DEDUP file.
(In theory we could add a builder with the service enabled on a
specific volume, write a test that encodes knowledge of that volume,
and use the GO_BUILDER_NAME environment variable to run that test only
on the specially-configured builders. However, I don't currently have
the bandwidth to reconfigure the builders in this way, and given the
simplicity of the change I think it is unlikely to regress
accidentally.)
Change-Id: I649e7ef0b67e3939a980339ce7ec6a20b31b23a1
Cq-Include-Trybots: luci.golang.try:go1.21-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/538218
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Tests in rlimit_test.go exist to test the behavior of automatically
bumping RLIMIT_NOFILE on Unix implemented in rlimit.go (issue #46279),
with darwin-specific behavior split out into rlimit_darwin.go and
the rest left empty in rlimit_stub.go.
Since the behavior happens only on Unix, it doesn't make sense to test
it on other platforms. Copy rlimit.go's 'unix' build constraint to
rlimit_test.go to accomplish that.
Leave out the simplification of the build constraint in rlimit_stub.go
so that this CL remains a test-only fix.
In particular, this fixes a problem where TestOpenFileLimit was
failing in some environments when testing the wasip1/wasm port.
The RLIMIT_NOFILE bumping behavior isn't implemented there, so
the test was testing the environment and not the Go project.
Updates #46279.
For #61116.
Fixes#63994.
Change-Id: Ic993f9cfc021d4cda4fe3d7fed8e2e180f78a2ca
Cq-Include-Trybots: luci.golang.try:go1.21-wasip1-wasm_wasmtime
Reviewed-on: https://go-review.googlesource.com/c/go/+/539435
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit b7cbcf0c27)
Reviewed-on: https://go-review.googlesource.com/c/go/+/540615
Reviewed-by: Heschi Kreinick <heschi@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
On Windows, A root local device path is a path which begins with
\\?\ or \??\. A root local device path accesses the DosDevices
object directory, and permits access to any file or device on the
system. For example \??\C:\foo is equivalent to common C:\foo.
The Clean, IsAbs, IsLocal, and VolumeName functions did not
recognize root local device paths beginning with \??\.
Clean could convert a rooted path such as \a\..\??\b into
the root local device path \??\b. It will now convert this
path into .\??\b.
IsAbs now correctly reports paths beginning with \??\
as absolute.
IsLocal now correctly reports paths beginning with \??\
as non-local.
VolumeName now reports the \??\ prefix as a volume name.
Join(`\`, `??`, `b`) could convert a seemingly innocent
sequence of path elements into the root local device path
\??\b. It will now convert this to \.\??\b.
In addition, the IsLocal function did not correctly
detect reserved names in some cases:
- reserved names followed by spaces, such as "COM1 ".
- "COM" or "LPT" followed by a superscript 1, 2, or 3.
IsLocal now correctly reports these names as non-local.
For #63713Fixes#63715
Fixes CVE-2023-45283
Fixes CVE-2023-45284
Change-Id: I446674a58977adfa54de7267d716ac23ab496c54
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2040691
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2072596
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/540276
Auto-Submit: Heschi Kreinick <heschi@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Currently, set_crosscall2 takes the address of crosscall2 without
using the GOT, which, on some architectures, results in a
PC-relative relocation (e.g. R_AARCH64_ADR_PREL_PG_HI21 on ARM64)
to the crosscall2 symbol. But crosscall2 is dynamically exported,
so the C linker thinks it may bind to a symbol from a different
DSO. Some C linker may not like a PC-relative relocation to such a
symbol. Using a local trampoline to avoid taking the address of a
dynamically exported symbol.
It may be possible to not dynamically export crosscall2. But this
CL is safer for backport. Later we may remove the trampolines
after unexport crosscall2, if they are not needed.
Fixes#63509.
Updates #62556.
Change-Id: Id28457f65ef121d3f87d8189803abc65ed453283
Reviewed-on: https://go-review.googlesource.com/c/go/+/533535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
(cherry picked from commit 872d7181f4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/534915
Reviewed-by: David Chase <drchase@google.com>
When creating the struct type to hold variables captured by a function
literal, we currently reuse the captured variable names as fields.
However, there's no particular reason to do this: these struct types
aren't visible to users, and it adds extra complexity in making sure
fields belong to the correct packages.
Further, it turns out we were getting that subtly wrong. If two
function literals from different packages capture variables with
identical names starting with an uppercase letter (and in the same
order and with corresponding identical types) end up in the same
function (e.g., due to inlining), then we could end up creating
closure struct types that are "different" (i.e., not types.Identical)
yet end up with equal LinkString representations (which violates
LinkString's contract).
The easy fix is to just always use simple, exported, generated field
names in the struct. This should allow further struct reuse across
packages too, and shrink binary sizes slightly.
For #62498.
Fixes#62545.
Change-Id: I9c973f5087bf228649a8f74f7dc1522d84a26b51
Reviewed-on: https://go-review.googlesource.com/c/go/+/527135
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
(cherry picked from commit e3ce312621)
Reviewed-on: https://go-review.googlesource.com/c/go/+/534916
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
This CL is a roll-forward (tweaked slightly) of CL 467715, which
turned on text section splitting for GOARCH=arm. The intent is to
avoid recurrent problems with external linking where there is a
disagreement between the Go linker and the external linker over
whether a given branch will reach. In the past our approach has been
to tweak the reachability calculations slightly to try to work around
potential linker problems, but this hasn't proven to be very robust;
section splitting seems to offer a better long term fix.
Updates #58425.
Fixes#63317.
Change-Id: I7372d41abce84097906a3d0805b6b9c486f345d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/531795
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 1e69040920)
Reviewed-on: https://go-review.googlesource.com/c/go/+/532096
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Right now debuggers like Delve rely on the new goroutine created to run
a debugcall function to run on the same thread it started on, up until
it hits itself with a SIGINT as part of the debugcall protocol.
That's all well and good, except debugCallWrap1 isn't particularly
careful about not growing the stack. For example, if the new goroutine
happens to have a stale preempt flag, then it's possible a stack growth
will cause a roundtrip into the scheduler, possibly causing the
goroutine to switch to another thread.
Previous attempts to just be more careful around debugCallWrap1 were
helpful, but insufficient. This change takes everything a step further
and always locks the debug call goroutine and the new goroutine it
creates to the OS thread.
For #61732.
Fixes#62509.
Change-Id: I038f3a4df30072833e27e6a5a1ec01806a32891f
Reviewed-on: https://go-review.googlesource.com/c/go/+/515637
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
(cherry picked from commit d9a4b24a17)
Reviewed-on: https://go-review.googlesource.com/c/go/+/526576
[This is a (manual) backport of CL 527415 to Go 1.21.]
Currently, linking a Go c-shared object with C code using Apple's
new linker, it fails with
% cc a.c go.so
ld: segment '__DWARF' filesize exceeds vmsize in 'go.so'
Apple's new linker has more checks for unmapped segments. It is
very hard to make it accept a Mach-O shared object with an
additional DWARF segment.
We may want to stop combinding DWARF into the shared object (see
also #62577). For now, disable DWARF by default in c-shared mode
on darwin.
Updates #61229.
For #62598.
Change-Id: I525987b7fe1a4e64571327cb4696f98cc7b419a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/527816
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
There are some bugs in Apple's new linker that causes plugins to
be built incorrectly. And the bugs probably will not be fixed when
Xcode 15 is released (some time soon). Force old Apple linker to
work around.
Updates #61229.
For #62598.
Change-Id: I01ba5caadec6dc14f8c85dd02f78c1ed2e8b7d4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/527815
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
If a program imports the plugin package, the mechanisms in place for
detecting and deleting unused global map variables are no longer safe,
since it's possibly for a given global map var to be unreferenced in
the main program but referenced by a plugin. This patch changes the
linker to test for plugin use and to avoid removing any unused global
map variables if the main program could possibly load up a plugin.
Fixes#62505.
Updates #62430.
Change-Id: Ie00b18b681cb0d259e3c859ac947ade5778cd6c8
(cherry picked from commit 660620dd45)
Reviewed-on: https://go-review.googlesource.com/c/go/+/526575
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
In the existing implementation, all /gc/scan/* metrics are
always equal to 0 due to the dependency on gcStatDep not being
set. This leads to gcStatAggregate always containing zeros, and
always reporting 0 for those metrics.
Also, add a test to ensure that /gc/scan/* metrics are not empty.
For #62477.
Fixes#62478.
Change-Id: I67497347d50ed5c3ce1719a18714c062ec938cab
Reviewed-on: https://go-review.googlesource.com/c/go/+/526116
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Prior to CL 458218, gentraceback ignored the SPWrite function flag on
the innermost frame when doing a precise traceback on the assumption
that precise tracebacks could only be started from the morestack
prologue, and that meant that the innermost function could not have
modified SP yet.
CL 458218 rearranged this logic a bit and unintentionally lost this
particular case. As a result, if traceback starts in an assembly
function that modifies SP (either as a result of stack growth or stack
scanning during a GC preemption), traceback stop at the SPWrite
function and then crash with "traceback did not unwind completely".
Fix this by restoring the earlier special case for when the innermost
frame is SPWrite.
This is a fairly minimal change that should be easy to backport. I
think a more robust change would be to encode this per-PC in the
spdelta table, so it would be clear that we're unwinding from the
morestack prologue and wouldn't rely on a complicated and potentially
fragile set of conditions.
Fixes#62464.
Change-Id: I34f38157631890d33a79d0bd32e32c0fcc2574e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/526100
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Auto-Submit: Heschi Kreinick <heschi@google.com>
The HTML specification has incredibly complex rules for how to handle
"<!--", "<script", and "</script" when they appear within literals in
the script context. Rather than attempting to apply these restrictions
(which require a significantly more complex state machine) we apply
the workaround suggested in section 4.12.1.3 of the HTML specification [1].
More precisely, when "<!--", "<script", and "</script" appear within
literals (strings and regular expressions, ignoring comments since we
already elide their content) we replace the "<" with "\x3C". This avoids
the unintuitive behavior that using these tags within literals can cause,
by simply preventing the rendered content from triggering it. This may
break some correct usages of these tags, but on balance is more likely
to prevent XSS attacks where users are unknowingly either closing or not
closing the script blocks where they think they are.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for
reporting this issue.
Fixes#62197Fixes#62398
Fixes CVE-2023-39319
[1] https://html.spec.whatwg.org/#restrictions-for-contents-of-script-elements
Change-Id: Iab57b0532694827e3eddf57a7497ba1fab1746dc
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1976594
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2014619
Reviewed-on: https://go-review.googlesource.com/c/go/+/526097
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
When recovering from a panic, restore the caller's frame pointer before
returning control to the caller. Otherwise, if the function proceeds to
run more deferred calls before returning, the deferred functions will
get invalid frame pointers pointing to an address lower in the stack.
This can cause frame pointer unwinding to crash, such as if an execution
trace event is recorded during the deferred call on architectures which
support frame pointer unwinding.
Original CL by Nick Ripley, includes fix from CL 523697, and includes a
test update from CL 524315.
This CL also deviates from the original fix by doing some extra
computation to figure out the fp from the sp, since we don't have the fp
immediately available to us in `recovery` on the Go 1.21 branch, and it
would probably be complicated to plumb that through its caller.
For #61766Fixes#62046
Change-Id: I5a99ca4f909f6b6e209a330d595d1c99987d4359
Reviewed-on: https://go-review.googlesource.com/c/go/+/523698
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Currently the runtime marks all new memory as MADV_HUGEPAGE on Linux and
manages its hugepage eligibility status. Unfortunately, the default
THP behavior on most Linux distros is that MADV_HUGEPAGE blocks while
the kernel eagerly reclaims and compacts memory to allocate a hugepage.
This direct reclaim and compaction is unbounded, and may result in
significant application thread stalls. In really bad cases, this can
exceed 100s of ms or even seconds.
Really all we want is to undo MADV_NOHUGEPAGE marks and let the default
Linux paging behavior take over, but the only way to unmark a region as
MADV_NOHUGEPAGE is to also mark it MADV_HUGEPAGE.
The overall strategy of trying to keep hugepages for the heap unbroken
however is sound. So instead let's use the new shiny MADV_COLLAPSE if it
exists.
MADV_COLLAPSE makes a best-effort synchronous attempt at collapsing the
physical memory backing a memory region into a hugepage. We'll use
MADV_COLLAPSE where we would've used MADV_HUGEPAGE, and stop using
MADV_NOHUGEPAGE altogether.
Because MADV_COLLAPSE is synchronous, it's also important to not
re-collapse huge pages if the huge pages are likely part of some large
allocation. Although in many cases it's advantageous to back these
allocations with hugepages because they're contiguous, eagerly
collapsing every hugepage means having to page in at least part of the
large allocation.
However, because we won't use MADV_NOHUGEPAGE anymore, we'll no longer
handle the fact that khugepaged might come in and back some memory we
returned to the OS with a hugepage. I've come to the conclusion that
this is basically unavoidable without a new madvise flag and that it's
just not a good default. If this change lands, advice about Linux huge
page settings will be added to the GC guide.
Verified that this change doesn't regress Sweet, at least not on my
machine with:
/sys/kernel/mm/transparent_hugepage/enabled [always or madvise]
/sys/kernel/mm/transparent_hugepage/defrag [madvise]
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none [0 or 511]
Unfortunately, this workaround means that we only get forced hugepages
on Linux 6.1+.
For #61718.
Fixes#62329.
Change-Id: I7f4a7ba397847de29f800a99f9cb66cb2720a533
Reviewed-on: https://go-review.googlesource.com/c/go/+/516795
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 9f9bb26880)
Reviewed-on: https://go-review.googlesource.com/c/go/+/523655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
In inexact unification, when a named type matches against an inferred
unnamed type, we change the previously inferred type to the named type.
This preserves the type name and assignability.
We have to do the same thing when encountering a directional channel:
a bidirectional channel can always be assigned to a directional channel
but not the other way around. Thus, if we see a directional channel, we
must choose the directional channel.
This CL extends the previously existing logic for named types to
directional channels and also makes the code conditional on inexact
unification. The latter is an optimization - if unification is exact,
type differences don't exist and updating an already inferred type has
no effect.
Fixes#62205.
Change-Id: I807e3b9f9ab363f9ed848bdb18b2577b1d680ea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/524256
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
The check for fragmentary post-handshake messages in QUICConn.HandleData
was reversed, resulting in a potential panic when HandleData receives
a partial message.
In addition, HandleData wasn't checking the size of buffered
post-handshake messages. Produce an error when a post-handshake
message is larger than maxHandshake.
TestQUICConnectionState was using an onHandleCryptoData hook
in runTestQUICConnection that was never being called.
(I think it was inadvertently removed at some point while
the CL was in review.) Fix this test while making the hook
more general.
For #62266Fixes#62290
Change-Id: I210b70634e50beb456ab3977eb11272b8724c241
Reviewed-on: https://go-review.googlesource.com/c/go/+/522595
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Marten Seemann <martenseemann@gmail.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>
(cherry picked from commit e92c0f846c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/523039
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Condition variables are subtle and error-prone, and this example
demonstrates exactly the sorts of problems that they introduce.
Unfortunately, we're stuck with them for the foreseeable future.
As previously implemented, this example was racy: since the callback
passed to context.AfterFunc did not lock the mutex before calling
Broadcast, it was possible for the Broadcast to occur before the
goroutine was parked in the call to Wait, causing in a missed wakeup
resulting in deadlock.
The example also had a more insidious problem: it was not safe for
multiple goroutines to call waitOnCond concurrently, but the whole
point of using a sync.Cond is generally to synchronize concurrent
goroutines. waitOnCond must use Broadcast to ensure that it wakes up
the target goroutine, but the use of Broadcast in this way would
produce spurious wakeups for all of the other goroutines waiting on
the same condition variable. Since waitOnCond did not recheck the
condition in a loop, those spurious wakeups would cause waitOnCond
to spuriously return even if its own ctx was not yet done.
Fixing the aforementioned bugs exposes a final problem, inherent to
the use of condition variables in this way. This one is a performance
problem: for N concurrent calls to waitOnCond, the resulting CPU cost
is at least O(N²). This problem cannot be addressed without either
reintroducing one of the above bugs or abandoning sync.Cond in the
example entirely. Given that this example was already published in Go
1.21, I worry that Go users may think that it is appropriate to use a
sync.Cond in conjunction with context.AfterFunc, so I have chosen to
retain the Cond-based example and document its pitfalls instead of
removing or replacing it entirely.
I described this class of bugs and performance issues — and suggested
some channel-based alternatives — in my GopherCon 2018 talk,
“Rethinking Classical Concurrency Patterns”. The section on condition
variables starts on slide 37. (https://youtu.be/5zXAHh5tJqQ?t=679)
Fixes#62189.
Updates #62180.
For #20491.
Change-Id: If987cd9d112997c56171a7ef4fccadb360bb79bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/521596
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
(cherry picked from commit 1081f8c058)
Reviewed-on: https://go-review.googlesource.com/c/go/+/521598
For aggregate-typed arguments passed to a call, expandCalls
decomposed them into parts in the same block where the value
was created. This is not necessarily the call block, and in
the case where stores are involved, can change the memory
leaving that block, and getting that right is problematic.
Instead, do all the expanding in the same block as the call,
which avoids the problems of (1) not being able to reorder
loads/stores across a block boundary to conform to memory
order and (2) (incorrectly, not) exposing the new memory to
consumers in other blocks. Putting it all in the same block
as the call allows reordering, and the call creates its own
new memory (which is already dealt with correctly).
Fixes#62057.
Updates #61992.
Change-Id: Icc7918f0d2dd3c480cc7f496cdcd78edeca7f297
Reviewed-on: https://go-review.googlesource.com/c/go/+/519276
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit e72ecc6a6b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/520058
This reverts CL 452995.
Reason for revert: caused os.File.ReadDir to fail on
filesystems that do not support FILE_ID_BOTH_DIR_INFO.
This is an alternative to a fix-forward change in CL 518196.
Since the original change was mostly a performance improvement,
reverting to the previous implementation seems less risky than
backporting a larger fix.
Fixes#61910Fixes#61964
Change-Id: I60f1602b9eb6ea353e7eb23429f19f1ffa16b394
Reviewed-on: https://go-review.googlesource.com/c/go/+/520156
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
String symbol names could contain weird characters as we put the
string literal into the symbol name. So it may appear to need
mangling. However, as string symbols are grouped into a single
"go:string.*" symbol, the individual symbol names actually don't
matter. So don't mangle them.
Also make the mangling code more defensive in case of weird
symbol names.
Updates #62098.
Fixes#62140.
Change-Id: I533012567a9fffab69debda934f426421c7abb04
Reviewed-on: https://go-review.googlesource.com/c/go/+/520856
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit b65e34f038)
Reviewed-on: https://go-review.googlesource.com/c/go/+/520857
The wasip1 TCP echo test introduced in CL 493358 has a race
condition with port selection. The test runner probes for a free
port and then asks the WASM runtime to listen on the port, which
may be taken by another process in the interim.
Due to limitations with WASI preview 1, the guest is unable to
query the port it's listening on. The test cannot ask the WASM
runtime to listen on port 0 (choose a free port) since there's
currently no way for the test to query the selected port and
connect to it.
Given the race condition is unavoidable, this test is now disabled
by default and requires opt-in via an environment variable.
This commit also eliminates the hard-coded connection timeout.
Updates #61820.
Fixes#61821.
Change-Id: I375145c1a1d03ad45c44f528da3347397e6dcb01
Reviewed-on: https://go-review.googlesource.com/c/go/+/519895
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
(cherry picked from commit 795e779610)
Reviewed-on: https://go-review.googlesource.com/c/go/+/520955
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
On Darwin (and assume also on iOS but not sure), notetsleepg
cannot be called in a signal-handling context. Avoid this
by disabling block reads on Darwin.
An alternate approach was to add "sigNote" with a pipe-based
implementation on Darwin, but that ultimately would have required
at least one more linkname between runtime and syscall to avoid
racing with fork and opening the pipe, so, not.
Fixes#62019.
Updates #61768.
Change-Id: I0e8dd4abf9a606a3ff73fc37c3bd75f55924e07e
Reviewed-on: https://go-review.googlesource.com/c/go/+/518836
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit c6ee8e31e3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/519375
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
The existing code was simply wrong: we cannot ever use the result
signature parameter list (rsig.params) if sigParams was adjusted
for variadic functions. If it was adjusted, we always must either
use sigParams or its separately instantiated version.
In the condition "n > 0 && adjusted", the "n > 0" should have
been in either of the respective "if statement" branches.
Simplified the code by merging with the result signature parameter
update.
Fixes#61932.
Change-Id: I5d39bc8bbc4dd85c7c985055d29532b4b176955e
Reviewed-on: https://go-review.googlesource.com/c/go/+/519456
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/519417
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Historically, the Transport has silently truncated invalid
Host headers at the first '/' or ' ' character. CL 506996 changed
this behavior to reject invalid Host headers entirely.
Unfortunately, Docker appears to rely on the previous behavior.
When sending a HTTP/1 request with an invalid Host, send an empty
Host header. This is safer than truncation: If you care about the
Host, then you should get the one you set; if you don't care,
then an empty Host should be fine.
Continue to fully validate Host headers sent to a proxy,
since proxies generally can't productively forward requests
without a Host.
For #60374Fixes#61431Fixes#61904
Change-Id: If170c7dd860aa20eb58fe32990fc93af832742b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/511155
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
(cherry picked from commit b9153f6ef3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/518856
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Various tools expect tar files to contain entries for directories.
I dropped them when writing cmd/distpack because they're not
strictly necessary and omitting them saves space, but it also
turns out to break some things, so add them back.
We will backport this to release-branch.go1.21 so that Go 1.21.1
will include the directory entries. We can't do anything about
Go 1.21.0 retroactively.
% tar tzvf go1.22rsc1.src.tar.gz | sed 10q
drwxr-xr-x 0 0 0 0 Aug 10 10:07 go/
-rw-r--r-- 0 0 0 1337 Aug 10 10:07 go/CONTRIBUTING.md
-rw-r--r-- 0 0 0 1479 Aug 10 10:07 go/LICENSE
-rw-r--r-- 0 0 0 1303 Aug 10 10:07 go/PATENTS
-rw-r--r-- 0 0 0 1455 Aug 10 10:07 go/README.md
-rw-r--r-- 0 0 0 419 Aug 10 10:07 go/SECURITY.md
-rw-r--r-- 0 0 0 42 Aug 10 10:07 go/VERSION
drwxr-xr-x 0 0 0 0 Aug 10 10:07 go/api/
-rw-r--r-- 0 0 0 1142 Aug 10 10:07 go/api/README
-rw-r--r-- 0 0 0 35424 Aug 10 10:07 go/api/except.txt
% tar tzvf go1.22rsc1.darwin-amd64.tar.gz | sed 10q
drwxr-xr-x 0 0 0 0 Aug 10 10:07 go/
-rw-r--r-- 0 0 0 1337 Aug 10 10:07 go/CONTRIBUTING.md
-rw-r--r-- 0 0 0 1479 Aug 10 10:07 go/LICENSE
-rw-r--r-- 0 0 0 1303 Aug 10 10:07 go/PATENTS
-rw-r--r-- 0 0 0 1455 Aug 10 10:07 go/README.md
-rw-r--r-- 0 0 0 419 Aug 10 10:07 go/SECURITY.md
-rw-r--r-- 0 0 0 42 Aug 10 10:07 go/VERSION
drwxr-xr-x 0 0 0 0 Aug 10 10:07 go/api/
-rw-r--r-- 0 0 0 1142 Aug 10 10:07 go/api/README
-rw-r--r-- 0 0 0 35424 Aug 10 10:07 go/api/except.txt
%
Fixes#61862.
Fixes#61927.
Change-Id: Iecd9ba893015295e88715b031b79a104236b9ced
Reviewed-on: https://go-review.googlesource.com/c/go/+/518335
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/518835
Auto-Submit: Russ Cox <rsc@golang.org>
Apple's new linker, ld-prime from Xcode 15 beta, when handling
initializers in __mod_init_func, drops the offset in the data,
resolving the relocation to the beginning of the section. The
latest version of ld-prime rejects non-zero addend. We need to use
symbol-targeted "external" relocations, so that it doesn't need
an addend and can be resolved correctly. This also works fine with
ld64.
Fixes#60694.
For #61229.
Change-Id: Ida2be6aa4c91bfcd142b755e2ec63aabfbbd77a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/502616
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit bad9ca8a61)
Reviewed-on: https://go-review.googlesource.com/c/go/+/514535
Extremely large RSA keys in certificate chains can cause a client/server
to expend significant CPU time verifying signatures. Limit this by
restricting the size of RSA keys transmitted during handshakes to <=
8192 bits.
Based on a survey of publicly trusted RSA keys, there are currently only
three certificates in circulation with keys larger than this, and all
three appear to be test certificates that are not actively deployed. It
is possible there are larger keys in use in private PKIs, but we target
the web PKI, so causing breakage here in the interests of increasing the
default safety of users of crypto/tls seems reasonable.
Thanks to Mateusz Poliwczak for reporting this issue.
Updates #61460
Fixes CVE-2023-29409
Change-Id: Ie35038515a649199a36a12fc2c5df3af855dca6c
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1912161
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com>
(cherry picked from commit d865c715d92887361e4bd5596e19e513f27781b7)
Reviewed-on: https://go-review.googlesource.com/c/go/+/515056
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a band-aid of a fix for Go 1.21, to create space to work on
a real fix for Go 1.22, if in fact the real fix is different. It simply
disables the go.sum update check during go list -m -u.
I don't have a self-contained test for the breakage. See #61605.
All existing tests continue to pass.
For #61605.
After merging into the Go 1.21 branch we can move #61605 to the Go 1.22 milestone.
Change-Id: Ib155710092003f08d2a6ce0aefa8e0270cad5a5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/514899
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The default WASI runtime was originally set to Wazero, because it was
the first runtime used to test the Go implementation and because we
could easily find and fix issues in our implementation and theirs.
In CL 498675 we switched the default wasip1 runner to Wasmtime as it
runs faster and is a more established and mature runtime. We should
switch the default runtime to Wasmtime to consistently promote
Wasmtime as the primary tested and approved runtime.
Change-Id: Ic6c064142321af90f015e02b7fe0e71444d8842c
Reviewed-on: https://go-review.googlesource.com/c/go/+/513235
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Eli Bendersky <eliben@google.com>
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Auto-Submit: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 4918490962)
Reviewed-on: https://go-review.googlesource.com/c/go/+/514155
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The timeout field is documented as being available so that it's possible
to override timeout by setting a non-zero value. If it's left at zero,
we don't need to override the default go test timeout, but we still need
to apply the timeout scale whenever it's something other than 1.
Fixes#61468.
Change-Id: I63634e9b3ef8c4ec7f334b5a6b4bf3cad121355c
Reviewed-on: https://go-review.googlesource.com/c/go/+/511976
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
When running "go test" including a main package which has a PGO
profile, we currently build the package being tested and its
dependencies with PGO, but we failed to attach the profile to
test-only dependencies. If a package is (transitively) imported
by both the package being tested and the test, the PGO version
and the non-PGO version of the package are both linked into the
binary, causing link-time error.
This CL fixes this by attaching the PGO profile to dependencies of
the test.
Fixes#61376.
Change-Id: I2559db9843c4cdab596b31e2025d8475ffbf58ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/510835
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit af0609b080)
Reviewed-on: https://go-review.googlesource.com/c/go/+/511698
When the final Go 1.21.0 release is made, the release notes will lose
the draft status and begin to be visible at https://go.dev/doc/go1.21.
The source go1.21.html file will then move from the main Go repository
to x/website as part of it becoming a finished and eventually frozen
historical release notes page.
The https://tip.golang.org/doc/go1.21 page that currently serves the
current draft always uses the main repository's main branch, so this
copy on the release branch is not used by anything. Its existence on
this branch may attract backports, which are harmless but also not
very useful. Avoid that temptation by deleting it here sooner.
(Since the first RC comes with a mostly complete release notes draft,
maybe in the future we can consider moving this file to x/website
right before a release branch is cut, making the draft available at
https://go.dev/doc/go1.21 sooner so fewer links will need updating.)
For #58645.
Change-Id: I92c0200b748a5f255f9b8113b4952c122631c6d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/511317
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Merge List:
+ 2023-07-13 b88bd917b8 cmd/go/internal/modfetch: always allow Stat for the current toolchain to succeed
+ 2023-07-13 d4f0d896a6 net/http: revert stray edit to h2_bundle.go from CL 508996
+ 2023-07-13 4a0f51696e all: remove duplicate word and fix comment
+ 2023-07-12 49d42128fd all: fix typos and remove repeated words
Change-Id: Ie4f17f633483d5cd1d244b6e7cde6422dc246d9e
Merge List:
+ 2023-07-12 6244b1946b all: update vendored dependencies
+ 2023-07-12 b4872ea187 cmd/go: fix go get go@badversion
+ 2023-07-12 87350393e6 cmd/go: fix GOTOOLCHAIN parsing for +auto
+ 2023-07-12 230e549142 doc/go1.21: add a release note for CL 463177
+ 2023-07-12 5e4000ad7f cmd/compile: on PPC64, fix sign/zero extension when masking
+ 2023-07-11 af8f94e3c5 src/README.vendor: s/latest/master/
+ 2023-07-11 3eaee3d5dd testing/slogtest: check for no group with empty record
+ 2023-07-11 167c8b73bf net/http/fcgi: eliminate goroutine leaks in tests
+ 2023-07-11 cb7a091d72 os/exec: ignore context.Canceled errors in TestConcurrentExec
+ 2023-07-11 651869716a log/slog: replace nil contexts with context.Background()
+ 2023-07-11 3f8b04bfb5 log/slog: change XXXCtx functions to XXXContext
+ 2023-07-11 4c58d6bf52 time: increase arbitrary upper bound in TestReset to 10s
+ 2023-07-11 6a063b01b0 net: mptcp: force using MPTCP with GODEBUG
+ 2023-07-10 07ede7a543 syscall: serialize locks on ForkLock on platforms where forkExecPipe is not atomic
+ 2023-07-10 7dc62f3bda test: add test cases for index value with range array clear
+ 2023-07-10 0b65b02ba5 cmd/compile: fix clear on slice with zero size elem
+ 2023-07-10 c4db811e44 cmd/compile: don't ICE on unaligned offsets for pointer writes
+ 2023-07-07 5c15498609 os: support reading empty root directories on Windows
+ 2023-07-07 894d24d617 src/database/sql: run gofmt
+ 2023-07-07 ac9137f8d3 go/types, types2: do not mutate arguments in NewChecker
+ 2023-07-07 158d11196f math: add test that covers riscv64 fnm{add,sub} codegen
+ 2023-07-07 d3d78b4bcc log/slog: handle recursively empty groups
+ 2023-07-06 39c5070712 os: do not skip directory entries with zero inodes on wasip1
+ 2023-07-06 e6ec2a34dc runtime: print output on failure in TestMemPprof
+ 2023-07-06 449ef3795d net: only build cgo_stub.go on unix or wasip1
+ 2023-07-06 6305d7fdd3 cmd/go: pass GoVersion in vet config
+ 2023-07-06 b490bdc27d go/types: record Config.GoVersion for reporting in Package.GoVersion method
+ 2023-07-06 36ea4f9680 log/slog: fix faulty test
+ 2023-07-05 3fce111535 cmd/compile: fix FMA negative commutativity of riscv64
+ 2023-07-05 c8dad424bf math: fix portable FMA when x*y < 0 and x*y == -z
+ 2023-07-05 cd6676126b database/sql: prevent internal context error from being returned from Rows.Err()
+ 2023-07-05 b2215e49c7 runtime,runtime/metrics: clarify OS stack metrics
+ 2023-07-04 e126572f8a runtime: have ReadMemStats do a nil check before switching stacks
+ 2023-07-04 e4ed92a355 os, syscall: update unreachable link about =C: envs
+ 2023-07-04 5c1a15df41 test/codegen: enable Mul2 DivPow2 test for riscv64
+ 2023-06-30 5b72f45dd1 runtime: check GOFLAGS not GCFLAGS
+ 2023-06-29 18e17e2cb1 net: enable pure Go resolver for wasip1
+ 2023-06-29 1e97c51536 syscall: stub Getrlimit on wasip1
+ 2023-06-29 683f51d307 cmd/asm/internal/lex: fix comment, remove the first "has"
+ 2023-06-29 2db31efdba cmd/compile/internal/types2: make TestIssue43124 match the go/types version
+ 2023-06-29 499458f7ca net/http: validate Host header before sending
+ 2023-06-29 fe73c186eb cmd/{go,compile}: run gofmt
+ 2023-06-29 da5d8fdd0c runtime: run wasip1 tests with wazero
+ 2023-06-29 411c99671a slices, maps: add examples; doc comment fixes
+ 2023-06-29 03cd8a7b0e internal/bytealg: fix alignment code in equal_riscv64.s
+ 2023-06-28 8b5fe5980c cmd/compile: handle min/max correctly in mayCall
+ 2023-06-28 79d4defa75 cmd/compile/internal/ssagen: fix min/max codegen, again
+ 2023-06-28 a3093eca64 cmd/go: enable slog vet check during 'go test'
+ 2023-06-27 6691f438c3 cmd/dist, internal/abi: support bootstrapping with gccgo
+ 2023-06-27 942c1c12d8 runtime: fix trace.Stop deadlock when built with faketime
+ 2023-06-27 4ad4128d3c cmd/compile: fix bad order of evaluation for min/max builtin
+ 2023-06-27 4f36f7e4dd encoding: document that base32 and base64 do not use UTF-8
+ 2023-06-27 8008c0840f syscall: clarify which handles are affected by SysProcAttr.NoInheritHandles
+ 2023-06-27 13529cc5f4 syscall: try non-blocking stdio on wasip1
+ 2023-06-26 1dbbafc70f go/types, types2: replace TODO with clarifying comment
+ 2023-06-26 7cc0740596 slices: add godoc links
+ 2023-06-26 d49017a7c3 go/types, types2: fix interface unification
+ 2023-06-26 b3ca8d2b3c types2, go/types: record final type for min/max arguments
+ 2023-06-26 ee361ce66c go/types, types2: more readable inference trace
+ 2023-06-26 9f6e87ff74 doc/go1.21: document changes in crypto/x509
+ 2023-06-26 f5015b5164 doc/go1.21: context.Background and TODO may now appear equal
+ 2023-06-24 a031f4ef83 cmd/compile: fix min/max builtin code generation
+ 2023-06-24 ea927e560d slices: clarify MinFunc/MaxFunc result for equal elements
+ 2023-06-23 3619255777 crypto/x509: rename duplicated test
+ 2023-06-23 48dbb6227a runtime: set raceignore to zero when starting a new goroutine
+ 2023-06-23 3adcce5ae7 crypto: document non-determinism of GenerateKey
+ 2023-06-23 6dce882b3a cmd/compile: scanning closures body when visiting wrapper function
+ 2023-06-23 164aceea08 log/slog: fix broken link to AnyValue in comment
+ 2023-06-23 82e17c4d11 log/slog: fix broken link to Record.Clone in package docs
+ 2023-06-22 25e46693a1 cmd/go: impersonate 'go tool dist list' if 'go tool dist' is not present
+ 2023-06-22 f8616b8484 internal/platform,cmd/dist: export the list of supported platforms
+ 2023-06-22 51885c1fa2 cmd/{go,cover}: enable response file args for cmd/cover
+ 2023-06-22 3479e1e543 internal/fuzz: fix typo in comment
+ 2023-06-22 20313660f5 crypto/x509: tolerate multiple matching chains in testVerify
+ 2023-06-21 78c3aba470 net/mail: permit more characters in mail headers
+ 2023-06-21 633b742ae0 test: add test that caused a gofrontend crash
+ 2023-06-21 ad2c517708 doc/go1.21: correct GOOS to GOARCH (another location)
+ 2023-06-21 b23cae8095 doc/go1.21: correct GOOS to GOARCH
+ 2023-06-21 b1f1fb2950 go/types, types2: avoid spurious "declared and not used" error
+ 2023-06-21 e45202f215 runtime: relate GODEBUG=gctrace output to runtime/metrics
+ 2023-06-21 36edde9d9f cmd/go: shorten longest 5 tests
+ 2023-06-21 413e6c0499 cmd/compile/internal/ir: typo
+ 2023-06-20 f3bf18117b log/slog: fix HandlerOptions.ReplaceAttr doc
+ 2023-06-20 e122ebabb6 encoding/binary: on invalid type return -1 from Size
+ 2023-06-20 8484f2fe02 cmd/go: add comment for intentional misspelling
Change-Id: Ie91c398dde7ca2a210b286c7865d3e7a905d6ea9
Merge List:
+ 2023-06-20 a7b1793701 cmd/go: do not index std as a module in modcache
+ 2023-06-20 3d279283a4 cmd/go: restore go.mod files during toolchain selection
+ 2023-06-20 3b4b7b84de cmd/distpack: rename go.mod to _go.mod in toolchain modules
+ 2023-06-20 6459494014 cmd/go: disable sumdb less often for toolchain downloads
+ 2023-06-20 02789816c4 internal/bisect: add 'q' hash option for quiet hash behavior switching
+ 2023-06-20 98617fd23f runtime/trace: add godoc links
+ 2023-06-19 bc21d6a4fc cmd/go/internal/modfetch: fix retractions slice initial length not zero
+ 2023-06-17 261e267618 os/exec: document a method to check if a process is alive
+ 2023-06-16 dbf9bf2c39 cmd/internal/moddeps: allow the "misc" module to be missing from GOROOT
+ 2023-06-16 0183c1aa02 cmd/compile/internal/syntax: skip GOROOT/misc in TestStdLib if it doesn't exist
+ 2023-06-16 199fbd4b59 cmd/internal/testdir: skip Test if GOROOT/test does not exist
+ 2023-06-16 a48f9c26d5 go/types: skip tests that require GOROOT/test if it is not present
+ 2023-06-16 3891ecbd35 go/internal/gcimporter: skip TestImportTypeparamTests if GOROOT/test is missing
+ 2023-06-16 60876717b4 cmd/go/internal/test: don't wait for previous test actions when interrupted
+ 2023-06-16 c1bc44642d path/filepath: avoid assuming that GOROOT/test is present
+ 2023-06-16 9ece9a7ac9 cmd/cgo/internal/testshared: disable gccgo tests on PPC64
+ 2023-06-16 23c5e48c4a cmd/cgo/internal/testshared: strip newline from gccgo -dumpversion
+ 2023-06-16 cf7ae4f136 compress/bzip2: fix typo
+ 2023-06-16 3c8b7a9551 net/http: check RemoteAddr isn't nil before dereferencing
+ 2023-06-16 548790e64a net/http: close req.Body only when it's non-nil on js
+ 2023-06-16 6dc2d2aa6b testing/fstest: fix the Glob test when dir entries are out of order
+ 2023-06-16 2b0ff4b629 reflect: fix ArenaNew to match documentation
+ 2023-06-16 4eceefa338 cmd/distpack: make go_$GOOS_$GOARCH_exec programs executable
+ 2023-06-16 1a7709d6af runtime: use 1-byte load for address checking in racecallatomic
+ 2023-06-15 3e7ec13166 cmd/go: fix build config for 'go list -cover'
+ 2023-06-15 30b17f4f97 net/http: only disable Fetch API in tests
+ 2023-06-15 65db95d0ed math: document that Min/Max differ from min/max
+ 2023-06-15 60e6afb689 cmd/compile: do not report division by error during typecheck
+ 2023-06-15 f6e0dcc474 slices: add sort benchmark for sorted strings
Change-Id: If342a000b719335fbbb421f027a8b253b07c1cab
Merge List:
+ 2023-06-15 b7e7467865 test/codegen: add fsqrt test for riscv64
+ 2023-06-15 befec5ddbb text/template: set variables correctly in range assignment
+ 2023-06-15 c5463218a2 cmd/api: skip TestIssue29837 when -short is set
+ 2023-06-15 9fc84363d1 cmd/asm: fix encoding errors for FMOVD and FMOVS instructions on arm64
+ 2023-06-14 da94586aa3 cmd/go: check for errors reading gccgo package list
+ 2023-06-14 b01cd41b46 cmd/go: use gover.Local for $goversion in TestScript
+ 2023-06-14 3aea422e2c crypto/x509: use synthetic root for platform testing
Change-Id: Icec55130749c52eef75c0e0325d889ff18b067f6
description:"If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on [go.dev/play](https://go.dev/play) is best."
validations:
required:true
- type:textarea
id:actual-behavior
attributes:
label:"What did you see happen?"
description:Command invocations and their associated output, functions with their arguments and return results, full stacktraces for panics (upload a file if it is very long), etc. Prefer copying text output over using screenshots.
validations:
required:true
- type:textarea
id:expected-behavior
attributes:
label:"What did you expect to see?"
description:Why is the current output incorrect, and any additional context we may need to understand the issue.
description:Issues or feature requests for the documentation site
title:"x/pkgsite: issue title"
labels:["pkgsite"]
body:
- type:markdown
attributes:
value:"Please answer these questions before submitting your issue. Thanks!"
- type:input
id:url
attributes:
label:"What is the URL of the page with the issue?"
validations:
required:true
- type:input
id:user-agent
attributes:
label:"What is your user agent?"
description:"You can find your user agent here: https://www.google.com/search?q=what+is+my+user+agent"
validations:
required:true
- type:textarea
id:screenshot
attributes:
label:"Screenshot"
description:"Please paste a screenshot of the page."
validations:
required:false
- type:textarea
id:what-did-you-do
attributes:
label:"What did you do?"
description:"If possible, provide a recipe for reproducing the error. Starting with a Private/Incognito tab/window may help rule out problematic browser extensions."
about: Request a package be removed from the documentation site (pkg.go.dev)
title: "x/pkgsite: package removal request for [type path here]"
labels: pkgsite/package-removal
---
<!--
Please answer these questions before submitting your issue. Thanks!
-->
### What is the path of the package that you would like to have removed?
<!---
We can remove packages with a shared path prefix.
For example, a request for "github.com/author" would remove all pkg.go.dev pages with that package path prefix.
--->
### Are you the owner of this package?
<!---
Only the package owners can request to have their packages removed from pkg.go.dev.
--->
### What is the reason that you could not retract this package instead?
<!---
If you would like to have your module removed from pkg.go.dev, we recommend that you retract them, so that they can be removed from the go command and proxy.golang.org as well.
Retracting a module version involves adding a retract directive to your go.mod file and publishing a new version. For example: https://github.com/jba/retract-demo/blob/main/go.mod#L5-L8
See https://pkg.go.dev/about#removing-a-package for additional tips on retractions.
description:Issues or feature requests for the Go language server (gopls)
title:"x/tools/gopls: issue title"
labels:["gopls","Tools"]
body:
- type:markdown
attributes:
value:"Please answer these questions before submitting your issue. Thanks!"
- type:textarea
id:gopls-version
attributes:
label:"gopls version"
description:"Output of `gopls -v version` on the command line"
validations:
required:true
- type:textarea
id:go-env
attributes:
label:"go env"
description:"Output of `go env` on the command line in your workspace directory"
render:shell
validations:
required:true
- type:textarea
id:what-did-you-do
attributes:
label:"What did you do?"
description:"If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on [go.dev/play](https://go.dev/play) is better. A failing unit test is the best."
validations:
required:true
- type:textarea
id:actual-behavior
attributes:
label:"What did you see happen?"
validations:
required:true
- type:textarea
id:expected-behavior
attributes:
label:"What did you expect to see?"
validations:
required:true
- type:textarea
id:editor-and-settings
attributes:
label:"Editor and settings"
description:"Your editor and any settings you have configured (for example, your VSCode settings.json file)"
validations:
required:false
- type:textarea
id:logs
attributes:
label:"Logs"
description:"If possible please include gopls logs. Instructions for capturing them can be found here: https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capture-logs"
name:Go vulnerability management - bugs and feature requests
description:Issues or feature requests about Go vulnerability management
title:"x/vuln: issue title"
labels:["vulncheck or vulndb"]
body:
- type:markdown
attributes:
value:"Please answer these questions before submitting your issue. Thanks! To add a new vulnerability to the Go vulnerability database (https://vuln.go.dev), see https://go.dev/s/vulndb-report-new. To report an issue about a report, see https://go.dev/s/vulndb-report-feedback."
- type:textarea
id:govulncheck-version
attributes:
label:govulncheck version
description:What version of govulncheck are you using (`govulncheck -version`)?
placeholder:|
Go: devel go1.22-0262ea1ff9 Thu Oct 26 18:46:50 2023 +0000
label:"Does this issue reproduce at the latest version of golang.org/x/vuln?"
validations:
required:true
- type:textarea
id:go-env
attributes:
label:"Output of `go env` in your module/workspace:"
render:shell
validations:
required:true
- type:textarea
id:what-did-you-do
attributes:
label:"What did you do?"
description:"If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on [go.dev/play](https://go.dev/play) is best."
@@ -82,7 +82,7 @@ while still insisting that races are errors and that tools can diagnose and repo
<p>
The following formal definition of Go's memory model closely follows
the approach presented by Hans-J. Boehm and Sarita V. Adve in
“<ahref="https://dl.acm.org/doi/10.1145/1375581.1375591">Foundations of the C++ Concurrency Memory Model</a>”,
“<ahref="https://www.hpl.hp.com/techreports/2008/HPL-2008-56.pdf">Foundations of the C++ Concurrency Memory Model</a>”,
published in PLDI 2008.
The definition of data-race-free programs and the guarantee of sequential consistency
for race-free programs are equivalent to the ones in that work.
@@ -98,12 +98,12 @@ which in turn are made up of memory operations.
A <i>memory operation</i> is modeled by four details:
</p>
<ul>
<li>its kind, indicating whether it is an ordinary data read, an ordinary data write,
or a <i>synchronizing operation</i> such as an atomic data access,
a mutex operation, or a channel operation,</li>
<li>its location in the program,</li>
<li>the memory location or variable being accessed, and</li>
<li>the values read or written by the operation.</li>
<li>its kind, indicating whether it is an ordinary data read, an ordinary data write,
or a <i>synchronizing operation</i> such as an atomic data access,
a mutex operation, or a channel operation,
<li>its location in the program,
<li>the memory location or variable being accessed, and
<li>the values read or written by the operation.
</ul>
<p>
Some memory operations are <i>read-like</i>, including read, atomic read, mutex lock, and channel receive.
@@ -159,11 +159,10 @@ union of the sequenced before and synchronized before relations.
For an ordinary (non-synchronizing) data read <i>r</i> on a memory location <i>x</i>,
<i>W</i>(<i>r</i>) must be a write <i>w</i> that is <i>visible</i> to <i>r</i>,
where visible means that both of the following hold:
</p>
<ol>
<li><i>w</i> happens before <i>r</i>.</li>
<li><i>w</i> does not happen before any other write <i>w'</i> (to <i>x</i>) that happens before <i>r</i>.</li>
<li><i>w</i> happens before <i>r</i>.
<li><i>w</i> does not happen before any other write <i>w'</i> (to <i>x</i>) that happens before <i>r</i>.
</ol>
<p>
@@ -222,7 +221,7 @@ for programs that do contain races.
</p>
<p>
Any implementation can, upon detecting a data race,
First, any implementation can, upon detecting a data race,
report the race and halt execution of the program.
Implementations using ThreadSanitizer
(accessed with “<code>go</code><code>build</code><code>-race</code>”)
@@ -230,18 +229,7 @@ do exactly this.
</p>
<p>
A read of an array, struct, or complex number
may be implemented as a read of each individual sub-value
(array element, struct field, or real/imaginary component),
in any order.
Similarly, a write of an array, struct, or complex number
may be implemented as a write of each individual sub-value,
in any order.
</p>
<p>
A read <i>r</i> of a memory location <i>x</i>
holding a value
Otherwise, a read <i>r</i> of a memory location <i>x</i>
that is not larger than a machine word must observe
some write <i>w</i> such that <i>r</i> does not happen before <i>w</i>
and there is no write <i>w'</i> such that <i>w</i> happens before <i>w'</i>
@@ -453,7 +441,7 @@ crash, or do something else.)
</p>
<pclass="rule">
The <i>k</i>th receive from a channel with capacity <i>C</i> is synchronized before the completion of the <i>k</i>+<i>C</i>th send on that channel.
The <i>k</i>th receive on a channel with capacity <i>C</i> is synchronized before the completion of the <i>k</i>+<i>C</i>th send from that channel completes.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
