Initialize the doc/next directory for the next release by copying the
contents of doc/initial into it.
Also, rewrite doc/README.md to add release instructions and to separate
information for developers from information for the release team.
Change-Id: Ie1e5c2ddae7a8d301e9b2f8a68925519648aa84d
Reviewed-on: https://go-review.googlesource.com/c/go/+/557535
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Add a test that every file in api/next has corresponding
release note fragments.
Vendor in golang.org/x/build/relnote, which brings along some other
things.
Modify dist/test.go to configure the test to run on some trybots.
For #64169.
Change-Id: If87d11350ea6b2605bc3ab31c491fa28f1d6ee7d
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/556995
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The variable represents the RISC-V user-mode application profile for
which to compile. Valid values are rva20u64 (the default) and
rva22u64.
Setting GORISCV64=rva20u64 defines the riscv64.rva20u64 build tag,
sets the internal variable buildcfg.GORISCV64 to 20 and defines the
macro GORISCV64_rva20u64 for use in assembly language code.
Setting GORISCV64=rva22u64 defines the riscv64.rva20u64 and
riscv64.rva22u64 build tags, sets the internal variable
buildcfg.GORISCV64 to 22 and defines the macro GORISCV64_rva22u64
for use in assembly language code.
This patch only provides a mechanism for the compiler and hand-coded
assembly language functions to take advantage of the RISC-V
extensions mandated by the application profiles. Further patches
will be required to get the compiler/assembler and assembly language
functions to actually generate and use these extensions.
Fixes#61476
Change-Id: I9195ae6ee71703cd2112160e89157ab63b8391af
Reviewed-on: https://go-review.googlesource.com/c/go/+/541135
Reviewed-by: M Zhuo <mengzhuo1203@gmail.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Wang Yaduo <wangyaduo@linux.alibaba.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: M Zhuo <mengzhuo1203@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
"cmd/go/internal/str.Contains" does the same thing as the "slices.Contains".
The name "str.Contains" is also easily confused with "strings.Contains".
Given that the slices package is already used in the package,
replace "str.Contains" with "slices.Contains".
"str.Contains" is no longer used so just remove it.
Change-Id: I80572464bd17d4a60e7ff41db3a77c4d0bd03fa3
GitHub-Last-Rev: e74d333f0f
GitHub-Pull-Request: golang/go#64136
Reviewed-on: https://go-review.googlesource.com/c/go/+/542416
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
On Windows, ws2_32.dll is loaded and WSA initialized even if websockets
are not used.
This CL delays loading of ws2_32.dll and starting WSA until net is
initialized.
Change-Id: I07ea8241d79709cd4e80d29ba0d792c7444bbfe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/557015
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
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>
The straight revert in CL 551215 fixed this issue.
Add a test case to make sure we don't reintroduce it.
Test case copied from CL 550237 (by bcmills).
Fixes#64738.
Change-Id: I9654a1fd46fe1a1cc63ee6645a552ec21d720ad0
Reviewed-on: https://go-review.googlesource.com/c/go/+/551255
Reviewed-by: Michael Matloob <matloob@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Bryan Mills <bcmills@google.com>
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>
reflect on the https://go-review.googlesource.com/c/go/+/548436
delete TODO the same.
Change-Id: I5b278cbfcb4108e5ffb332ba82dafb1eaa2bd6b2
GitHub-Last-Rev: cfc3950908
GitHub-Pull-Request: golang/go#64628
Reviewed-on: https://go-review.googlesource.com/c/go/+/548615
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
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: 4a63867098
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>
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>
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>
It's what the documentation says, and oddly it already behaves correctly
for right padding, not left. (We never pad with zeros on the right.)
Just don't do it.
Fixes#56486
Change-Id: I2465edea93c69084e33bee0d945d5a1b85e6cd14
Reviewed-on: https://go-review.googlesource.com/c/go/+/555776
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TestCallbackCallersSEH is flaky when using the internal linker. Skip
it for now until the flakiness is resolved.
Updates #65116
Change-Id: I7628b07eaff8be00757d5604722f30aede25fce5
Reviewed-on: https://go-review.googlesource.com/c/go/+/556635
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
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>
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>
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>
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>
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.)
Fixes#65209.
Updates #65175.
Change-Id: I32f9da779d24f2e133571f0971ec460cebe7820a
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-race
Reviewed-on: https://go-review.googlesource.com/c/go/+/557536
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Jonathan Amsterdam <jba@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.
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>
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>
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>
Add files to doc/initial that set up the overall structure
of the release notes document.
For #64169.
Change-Id: Ifbf330e554e1fa20d47c72cc309d5cd26048a323
Reviewed-on: https://go-review.googlesource.com/c/go/+/556817
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>
This is the first CL in a sequence that adds support
for generating release notes from fragments.
The actual generator will live elsewhere, in x/build.
This repo will hold the content and some validity
checks.
For #64169.
Change-Id: Iaa8d9ad96393ab9433170b3cfa47334837f3f691
Reviewed-on: https://go-review.googlesource.com/c/go/+/542515
Reviewed-by: 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>
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>
For #61422
Change-Id: I50e427b78a533c3196aeb5291a34c05528ee0bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/557455
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
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>
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.
Fixesgolang/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>
The test is skipped on wasm platforms for now, because it
successfully detects a starvation bug on those platforms.
For #65178.
Change-Id: I05d28f1c7be99fcab67ec4dfaa38f412e11fd3cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/557038
Auto-Submit: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Damien Neil <dneil@google.com>
I added this map in CL 526117, but it is apparently unused.
I assume that I removed all uses of it while revising that change.
Updates #59718.
Updates #50216.
Change-Id: I8cdac39f4764d1fcc31566408304c850cf0f9374
Reviewed-on: https://go-review.googlesource.com/c/go/+/557176
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>
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>
This was an oversight in porting over cmd/trace to the new trace format
and API.
Fixes#65153.
Change-Id: I883d302f95956fcc9abb60aa53165acb6d099d67
Reviewed-on: https://go-review.googlesource.com/c/go/+/557175
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
(The corresponding update for the last release cycle was CL 510735.)
For #40705
For #64340
Change-Id: I123ce68131a6c7b0344cab54cd29402cabb57225
Reviewed-on: https://go-review.googlesource.com/c/go/+/557155
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
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.)
Fixes#56881.
Change-Id: I9b241cfb604e5f633ca6a5d799df6706246684a7
Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest,gotip-windows-amd64-longtest
Reviewed-on: https://go-review.googlesource.com/c/go/+/556358
Run-TryBot: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Add missing checks for the case where the range expression is
a (possibly untyped) constant integer expression.
Add context parameter to assignVar for better error message
where the expression is part of a range clause.
Also, rename s/expr/Expr/ where it denotes an AST expression,
for clarity.
Fixes#65133.
For #65137.
Change-Id: I72962d76741abe79f613e251f7b060e99261d3ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/556398
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: 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>
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>
