aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-01-22time: add a regression test for time.AfterFunc goroutine starvationBryan C. Mills
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>
2024-01-22net: remove an unused sync.Map in the fake net implementationBryan C. Mills
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>
2024-01-19net: work around runtime scheduler starvation on js and wasip1Bryan C. Mills
Fixes #65177. Updates #65178. Updates #64321. Change-Id: I698fd3b688c7dfbde692eb7c29cbdafc89e7ca32 Cq-Include-Trybots: luci.golang.try:gotip-js-wasm,gotip-wasip1-wasm_wasmtime,gotip-wasip1-wasm_wazero Reviewed-on: https://go-review.googlesource.com/c/go/+/557037 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>
2024-01-19runtime: make a much better effort to emit CPU profile in a traceMichael Anthony Knyszek
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>
2024-01-19cmd/trace/v2: emit user log annotations in all viewsMichael Anthony Knyszek
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>
2024-01-19internal/goversion: update Version to 1.23Carlos Amedee
(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>
2024-01-18cmd/go/internal/modfetch: set protocol.version=2 for shallow git fetchesBryan C. Mills
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>
2024-01-18go/types, types2: fix range clause checks for constant range expressionsRobert Griesemer
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>
2024-01-17doc/go1.22: document net/netip changesDamien Neil
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>
2024-01-17doc/go1.22: document net/http/cgi changesDamien Neil
For #61422 Change-Id: If9c3d3ccbfb2061f42ffc26461209c96d38020e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/556395 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2024-01-17runtime: document GODEBUG panicnil valuesCuong Manh Le
Updates #25448 Change-Id: Ia1b7a376f5175f67e14ad4bd065d6e8ad5250d38 Reviewed-on: https://go-review.googlesource.com/c/go/+/536955 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org>
2024-01-17runtime: skip test if strace crashesAustin Clements
Very occasionally, at least on linux/386, strace itself will crash in TestUsingVDSO. Detect these crashes and just skip the test. Fixes #63734. Change-Id: I050494459d47dd96c0b8dc0b16353cb532fba93e Reviewed-on: https://go-review.googlesource.com/c/go/+/556357 Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-17runtime: mark TestGdbCoreCrashThreadBacktrace as flakyMichael Pratt
This test exercises the SIGQUIT crash loop and managed to trigger the race from #65138 at least once. For #65138. Fixes #64752. Change-Id: I11091510aa7ae4f58b1d748e53df2e3e3dbfb323 Reviewed-on: https://go-review.googlesource.com/c/go/+/556356 Auto-Submit: Michael Pratt <mpratt@google.com> 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>
2024-01-17cmp: add test case for uinitptrlxl-renren
Change-Id: Iebe79be01eb5208e9b9dea9297c464fe2b2dd3dd GitHub-Last-Rev: 875ab08627b1fb0db3dc2a14ac332fdbc9af8b4b GitHub-Pull-Request: golang/go#65017 Reviewed-on: https://go-review.googlesource.com/c/go/+/554595 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-17cmd/compile: call types2.Unalias to be ready for GODEBUG=gotypesalias=1Robert Griesemer
types2.Unalias is not needed if we know we have a core or underlying type. Also, types of declared functions (signatures) cannot be aliases (this includes tuples). Fixes #65125. Change-Id: I1faa26b66f6c646719e830dd661136fae86f3775 Reviewed-on: https://go-review.googlesource.com/c/go/+/556036 Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2024-01-16doc: fill out net/http.Request.PathValue,SetPathValue sectionDan Peterson
And add a missing code tag wrap elsewhere. Updates #61410 Updates #61422 Change-Id: I70a9c4ecaf4056af2e88d777b8db892a45dfcb9f Reviewed-on: https://go-review.googlesource.com/c/go/+/552195 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Dan Peterson <danp@danp.net> Reviewed-by: Jonathan Amsterdam <jba@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2024-01-15io/fs: godoc links to testing/fstestOlivier Mengué
Add godoc links from io/fs to testing/fstest for discoverability. Change-Id: I6550b4b703d2214faa732987ec8630ac903705b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/534095 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2024-01-15runtime: more godoc linksOlivier Mengué
Change-Id: I8fe66326994894b17ce0eda991bba942844d26b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/541475 Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-13internal/trace/v2: reject events for goroutines with unknown statesDominik Honnef
Change-Id: Ifc472ed4cf0433d06f43559930ac80df23656a6e Reviewed-on: https://go-review.googlesource.com/c/go/+/555496 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-01-12internal/trace/v2: avoid several panics for malformed tracesDominik Honnef
This addresses some panics (out of bounds slice accesses and nil pointer dereferences) when parsing malformed data. These were found via light fuzzing, not by any rigorous means, and more potential panics probably exist. Fixes #64878. Fixes #64879. Change-Id: I4085788ba7dc91fec62e4abd88f50777577db42f Reviewed-on: https://go-review.googlesource.com/c/go/+/552995 Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-01-12crypto/rsa,crypto/internal/bigmod: improve verify/encrypt performanceFilippo Valsorda
Most libraries don't consider N secret, but it's arguably useful for privacy applications. However, E should generally be fixed, and there is a lot of performance to be gained by using variable-time exponentiation. The threshold trick is from BoringSSL. goos: linux goarch: amd64 pkg: crypto/rsa cpu: Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz │ old │ new │ │ sec/op │ sec/op vs base │ DecryptPKCS1v15/2048-4 1.398m ± 0% 1.396m ± 4% ~ (p=0.853 n=10) DecryptPKCS1v15/3072-4 3.640m ± 0% 3.652m ± 1% ~ (p=0.063 n=10) DecryptPKCS1v15/4096-4 7.756m ± 0% 7.764m ± 0% ~ (p=0.853 n=10) EncryptPKCS1v15/2048-4 175.50µ ± 0% 39.37µ ± 0% -77.57% (p=0.000 n=10) DecryptOAEP/2048-4 1.375m ± 0% 1.371m ± 1% ~ (p=0.089 n=10) EncryptOAEP/2048-4 177.64µ ± 0% 41.17µ ± 1% -76.82% (p=0.000 n=10) SignPKCS1v15/2048-4 1.419m ± 0% 1.393m ± 1% -1.84% (p=0.000 n=10) VerifyPKCS1v15/2048-4 173.70µ ± 1% 38.28µ ± 2% -77.96% (p=0.000 n=10) SignPSS/2048-4 1.437m ± 1% 1.413m ± 0% -1.64% (p=0.000 n=10) VerifyPSS/2048-4 176.83µ ± 1% 43.08µ ± 5% -75.64% (p=0.000 n=10) This finally makes everything in crypto/rsa faster than it was in Go 1.19. goos: linux goarch: amd64 pkg: crypto/rsa cpu: Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz │ go1.19.txt │ go1.20.txt │ go1.21.txt │ new.txt │ │ sec/op │ sec/op vs base │ sec/op vs base │ sec/op vs base │ DecryptPKCS1v15/2048-4 1.458m ± 0% 1.597m ± 1% +9.50% (p=0.000 n=10) 1.395m ± 1% -4.30% (p=0.000 n=10) 1.396m ± 4% -4.25% (p=0.002 n=10) DecryptPKCS1v15/3072-4 4.023m ± 1% 5.332m ± 1% +32.53% (p=0.000 n=10) 3.649m ± 1% -9.30% (p=0.000 n=10) 3.652m ± 1% -9.23% (p=0.000 n=10) DecryptPKCS1v15/4096-4 8.710m ± 1% 11.937m ± 1% +37.05% (p=0.000 n=10) 7.564m ± 1% -13.16% (p=0.000 n=10) 7.764m ± 0% -10.86% (p=0.000 n=10) EncryptPKCS1v15/2048-4 51.79µ ± 0% 267.68µ ± 0% +416.90% (p=0.000 n=10) 176.42µ ± 0% +240.67% (p=0.000 n=10) 39.37µ ± 0% -23.98% (p=0.000 n=10) DecryptOAEP/2048-4 1.461m ± 0% 1.613m ± 1% +10.37% (p=0.000 n=10) 1.415m ± 0% -3.13% (p=0.000 n=10) 1.371m ± 1% -6.18% (p=0.000 n=10) EncryptOAEP/2048-4 54.24µ ± 0% 269.19µ ± 0% +396.28% (p=0.000 n=10) 177.31µ ± 0% +226.89% (p=0.000 n=10) 41.17µ ± 1% -24.10% (p=0.000 n=10) SignPKCS1v15/2048-4 1.510m ± 0% 1.705m ± 0% +12.93% (p=0.000 n=10) 1.423m ± 1% -5.78% (p=0.000 n=10) 1.393m ± 1% -7.76% (p=0.000 n=10) VerifyPKCS1v15/2048-4 50.87µ ± 0% 266.41µ ± 1% +423.71% (p=0.000 n=10) 174.38µ ± 0% +242.79% (p=0.000 n=10) 38.28µ ± 2% -24.75% (p=0.000 n=10) SignPSS/2048-4 1.513m ± 1% 1.709m ± 0% +12.97% (p=0.000 n=10) 1.461m ± 0% -3.42% (p=0.000 n=10) 1.413m ± 0% -6.58% (p=0.000 n=10) VerifyPSS/2048-4 53.45µ ± 1% 268.56µ ± 0% +402.48% (p=0.000 n=10) 177.29µ ± 0% +231.72% (p=0.000 n=10) 43.08µ ± 5% -19.39% (p=0.000 n=10) geomean 514.6µ 1.094m +112.65% 801.6µ +55.77% 442.1µ -14.08% Fixes #63516 Change-Id: If40e596a2e4b3ab7a202ff34591cf9cffecfcc1b Reviewed-on: https://go-review.googlesource.com/c/go/+/552935 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org>
2024-01-12crypto/rsa: use E = 65537 in benchmarksFilippo Valsorda
Now, this is embarrassing. For the whole Go 1.20 and Go 1.21 cycles, we based RSA public key operation (verification and decryption) benchmarks on the keys in rsa_test.go, which had E = 3. Most keys in use, including all those generated by GenerateKey, have E = 65537. This significantly skewed even relative benchmarks, because the new constant-time algorithms would incur a larger slowdown for larger exponents. I noticed this only because I got a production profile for an application that does a lot of RSA verifications, saw ExpShort show up, made ExpShort faster, and the crypto/rsa profiles didn't move. We were measuring the wrong thing, and the slowdown was worse than we thought. My apologies. (If E had not been parametrized, it would have avoided issues like this one, too. Grumble. https://words.filippo.io/parameters/#fn9) goos: darwin goarch: arm64 pkg: crypto/rsa │ g35222eeb78 │ new │ │ sec/op │ sec/op vs base │ DecryptPKCS1v15/2048-8 1.414m ± 2% 1.417m ± 1% ~ (p=0.971 n=10) DecryptPKCS1v15/3072-8 4.107m ± 0% 4.160m ± 1% +1.29% (p=0.000 n=10) DecryptPKCS1v15/4096-8 9.363m ± 1% 9.305m ± 1% ~ (p=0.143 n=10) EncryptPKCS1v15/2048-8 162.8µ ± 2% 212.1µ ± 0% +30.34% (p=0.000 n=10) DecryptOAEP/2048-8 1.460m ± 4% 1.413m ± 1% ~ (p=0.105 n=10) EncryptOAEP/2048-8 161.7µ ± 0% 213.4µ ± 0% +31.99% (p=0.000 n=10) SignPKCS1v15/2048-8 1.419m ± 1% 1.476m ± 1% +4.05% (p=0.000 n=10) VerifyPKCS1v15/2048-8 160.6µ ± 0% 212.6µ ± 3% +32.38% (p=0.000 n=10) SignPSS/2048-8 1.419m ± 0% 1.477m ± 2% +4.07% (p=0.000 n=10) VerifyPSS/2048-8 163.9µ ± 8% 212.3µ ± 0% +29.50% (p=0.000 n=10) geomean 802.5µ 899.1µ +12.04% Updates #63516 Change-Id: Iab4a0684d8101ae07dac8462908d8058fe5e9f3d Reviewed-on: https://go-review.googlesource.com/c/go/+/552895 Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com>
2024-01-11runtime: ensure we free unrolled GC bitmapsKeith Randall
CL 555355 has a bug in it - the GC program flag was also used to decide when to free the unrolled bitmap. After that CL, we just don't free any unrolled bitmaps, leading to a memory leak. Use a separate flag to track types that need to be freed when their corresponding object is freed. Change-Id: I841b65492561f5b5e1853875fbd8e8a872205a84 Reviewed-on: https://go-review.googlesource.com/c/go/+/555416 Auto-Submit: Keith Randall <khr@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-11go/types, types2: don't lose position info of interface embeddingsRobert Griesemer
Accurate position information for embedded types in interfaces is crucial to identify the corresponding source file, and with that the Go language version associated with that file. (The position information is also important for proper error messages.) Before this CL, the position information for embedded types was discarded after type set computation, in the assumption that it was not needed anymore. However, substitutions that update the interface may lead to repeated type set computations which then won't have the correct position information. This CL does preserve the position information for embedded types until the end of type checking (cleanup phase), and also copy the position information during a substitution of the interface. The respective bug (#64759) doesn't seem to appear in 1.22 (most likely because it's hidden by some of the changes made with respect to the file version logic), but the existing code is still wrong. The backport of this code to 1.21 and 1.20 fixes the issue in those releases. For #64759. Change-Id: I80f4004c9d79cb02eac6739c324c477706615102 Reviewed-on: https://go-review.googlesource.com/c/go/+/555296 Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
2024-01-11cmd/compile: document go:wasmimport directiveMauri de Souza Meneguzzo
Fixes #64972 Change-Id: I784a8728afbdef9736681d56f0a79c82a00609d6 GitHub-Last-Rev: bf158dbeaaa495dc258c590c7a21cf9e25e76ee7 GitHub-Pull-Request: golang/go#64991 Reviewed-on: https://go-review.googlesource.com/c/go/+/554455 Reviewed-by: Achille Roussel <achille.roussel@gmail.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2024-01-11runtime: don't mark unrolled bitmap type as having a gc programKeith Randall
It doesn't have a GC program - the whole point is that it is the unrolled version of a GC program. Fortunately, this isn't a bug as (*mspan).typePointersOfUnchecked ignores the GCProg flag and just uses GCData as a bitmap unconditionally. Change-Id: I2508af85af4a1806946e54c893120c5cc0cc3da3 Reviewed-on: https://go-review.googlesource.com/c/go/+/555355 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Keith Randall <khr@google.com>
2024-01-10os: relax tests and add examples for UserCacheDir and UserConfigDirBryan C. Mills
Per https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html: “If, when attempting to write a file, the destination directory is non-existent an attempt should be made to create it with permission 0700. […] The application should be prepared to handle the case where the file could not be written […]. In such case it may choose to present an error message to the user.” In certain CI environments, these directories have well-defined locations but do not exist and cannot be created. In that case, we now choose to log and return from the test without failing it. To prevent the functions from falling back to being entirely untested, we still fail the test (and “present an error message to the user”) if either function returns an empty string without an error, or returns a path that refers to a non-directory or results in an error other than ErrNotExist. In addition, since the tests themselves no longer create subdirectories, we add examples illustrating the suggested pattern of usage. Fixes #64990. Change-Id: Ie72106424f5ebe36eaf9288c22710d74bb14a462 Reviewed-on: https://go-review.googlesource.com/c/go/+/554815 Reviewed-by: Austin Clements <austin@google.com> 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> Auto-Submit: Bryan Mills <bcmills@google.com>
2024-01-10cmd/compile: use hashed symbol name for go.shape types if too longThan McIntosh
Shape-based stenciling in the Go compiler's generic instantiation phase looks up shape types using the underlying type of a given target type. This has a beneficial effect in most cases (e.g. we can use the same shape type for two different named types whose underlying type is "int"), but causes some problems when the underlying type is a very large structure. The link string for the underlying type of a large imported struct can be extremely long, since the link string essentially enumerates the full package path for every field type; this can produce a "go.shape.struct { ... " symbol name that is absurdly long. This patch switches the compiler to use a hash of the underlying type link string instead of the string itself, which should continue to provide commoning but keep symbol name lengths reasonable for shape types based on large imported structs. Fixes #65030. Change-Id: I87d602626c43172beb99c186b8ef72327b8227a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/554975 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Than McIntosh <thanm@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
2024-01-10net: add available godoc linkcui fliter
Change-Id: Ib7c4baf0247c421954aedabfbb6a6af8a08a8936 Reviewed-on: https://go-review.googlesource.com/c/go/+/540021 Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: shuang cui <imcusg@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-01-09runtime: replace rwmutexR/W with per-rwmutex lock rankMichael Pratt
CL 549536 intended to decouple the internal implementation of rwmutex from the semantic meaning of an rwmutex read/write lock in the static lock ranking. Unfortunately, it was not thought through well enough. The internals were represented with the rwmutexR and rwmutexW lock ranks. The idea was that the internal lock ranks need not model the higher-level ordering, since those have separate rankings. That is incorrect; rwmutexW is held for the duration of a write lock, so it must be ranked before any lock taken while any write lock is held, which is precisely what we were trying to avoid. This is visible in violations like: 0 : execW 11 0x0 1 : rwmutexW 51 0x111d9c8 2 : fin 30 0x111d3a0 fatal error: lock ordering problem execW < fin is modeled, but rwmutexW < fin is missing. Fix this by eliminating the rwmutexR/W lock ranks shared across different types of rwmutex. Instead require users to define an additional "internal" lock rank to represent the implementation details of rwmutex.rLock. We can avoid an additional "internal" lock rank for rwmutex.wLock because the existing writeRank has the same semantics for semantic and internal locking. i.e., writeRank is held for the duration of a write lock, which is exactly how rwmutex.wLock is used, so we can use writeRank directly on wLock. For #64722. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-staticlockranking Change-Id: Ia572de188a46ba8fe054ae28537648beaa16b12c Reviewed-on: https://go-review.googlesource.com/c/go/+/555055 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-01-09net/http: clarify the precedence order for Request.FormValueJes Cok
Fixes #64575 Change-Id: I0eaec642a9dc8ae3b273a6d41131cc7cb8332947 GitHub-Last-Rev: 17aa5170cbfe42cb86d56f1804266850d33c3eb5 GitHub-Pull-Request: golang/go#64578 Reviewed-on: https://go-review.googlesource.com/c/go/+/547855 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-09math/big: fix uint64 overflow in nat.mulRangeRobert Griesemer
Compute median as a + (b-a)/2 instead of (a + b)/2. Add additional test cases. Fixes #65025. Change-Id: Ib716a1036c17f8f33f51e33cedab13512eb7e0be Reviewed-on: https://go-review.googlesource.com/c/go/+/554617 Reviewed-by: Robert Griesemer <gri@google.com> Auto-Submit: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-01-09io/fs,path/filepath: fix typo in SkipAll/SkipDir docRoger Peppe
Also make the reference into a doc link. Change-Id: Ib112307a65b65c8f963abf60aa92cb1942de940c Reviewed-on: https://go-review.googlesource.com/c/go/+/554295 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-09runtime: fix tests when running with -msanMauri de Souza Meneguzzo
Currently go test -msan runtime always fails on loong64, arm64 and amd64. Changed the variable name to sz to match the function prototypes. For #64256 Change-Id: Ida71197307016520deb39293927850d47845140a GitHub-Last-Rev: 0ee1e3bb093e682ef325d9860a8fed67570ca345 GitHub-Pull-Request: golang/go#64572 Reviewed-on: https://go-review.googlesource.com/c/go/+/547696 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Keith Randall <khr@golang.org>
2024-01-08cmd/doc: fix inconsistent receiver nameMehdi Mostafavi
The ToText method of Package is the only one with a receiver declared 'p'; all the rest have 'pkg'. Fix it to be consistent. Change-Id: I2b47c719f4f6f8d87336316b7f80deb1b49e17dc GitHub-Last-Rev: 7d273b4ef0780b7ed8b651c117a28b25bab5bcb1 GitHub-Pull-Request: golang/go#64912 Reviewed-on: https://go-review.googlesource.com/c/go/+/553335 Run-TryBot: Rob Pike <r@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: qiulaidongfeng <2645477756@qq.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Rob Pike <r@golang.org>
2024-01-08net: clarify maxListenerBacklog windows implementationMauri de Souza Meneguzzo
The previous TODO comments were somewhat ambiguous. This aims to provide a clearer understanding of the behavior on Windows. Windows does not offer a way to peek at the current backlog length, this is explicitly stated in the winapi for `listen`. When set to `syscall.SOMAXCONN`, the OS dynamically adjusts the backlog to a maximum reasonable value. It goes as far as the dotnet runtime itself introducing a new version of `listen` that does not accept a backlog parameter to help eliminate the confusion when comparing the behavior with UNIXes. The docs also mention that `SOMAXCONN_HINT(N)` can be used, and that it clips the final computed value between (200, 65535), which suggests windows might use a `uint16` to back this number. Either way it does not matter since windows will adjust this value anyway, so I removed the wrapping TODO as well. See https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-listen Change-Id: I7b2e7cb547467c4bfc572ef0477a58de8c772521 GitHub-Last-Rev: 34e74abffe8792c8709c73db4d7a5fa05f64b1d0 GitHub-Pull-Request: golang/go#63549 Reviewed-on: https://go-review.googlesource.com/c/go/+/535475 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-08log/slog: clarify SetDefault behaviorJonathan Amsterdam
Change-Id: I53250ca9e6d1ba69cc667949bebb5be2651a020d Reviewed-on: https://go-review.googlesource.com/c/go/+/530477 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alan Donovan <adonovan@google.com> Run-TryBot: Jonathan Amsterdam <jba@google.com>
2024-01-08sync: use map[any]any instead of map[interface{}]interface{} in the godocsivchari
It's shorter and clearer. Change-Id: Ibfbe5a7f8d70fa884691ba9858a2c9b2122d9c50 Reviewed-on: https://go-review.googlesource.com/c/go/+/531475 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
2024-01-08cmd/compile: handle defined iter func type correctlyCuong Manh Le
Fixed #64930 Change-Id: I916de7f97116fb20cb2f3f0b425ac34409afd494 Reviewed-on: https://go-review.googlesource.com/c/go/+/553436 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
2024-01-05doc: s/adjustements/adjustmentsJes Cok
Change-Id: I904b1adee13c63bc7d47d4325b794c1a650eb18d GitHub-Last-Rev: 8eced8db566c4dea433260f87456902542095970 GitHub-Pull-Request: golang/go#64969 Reviewed-on: https://go-review.googlesource.com/c/go/+/554255 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> Run-TryBot: Jes Cok <xigua67damn@gmail.com>
2024-01-05slices: explicitly discard results of some functionsAlan Donovan
This will otherwise trigger an "unusedresult" vet check. Fixes #64978 Change-Id: Ie19aded0f808d394f389452c3ff7f3edc1ed710d Reviewed-on: https://go-review.googlesource.com/c/go/+/554196 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2024-01-05cmd/go: run cover tool before swigThan McIntosh
When building a package, run the cover tool on the collected go/cgo source files before invoking swig (if swig files are present), as opposed to running swig and then cover. Running swig adds new Go files to the "cgo" list, and we want to avoid running those newly generated files through the cover tool. Fixes #64661. Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest Change-Id: I32b6dad5c39fcf5e656c40fb3b44220c69320889 Reviewed-on: https://go-review.googlesource.com/c/go/+/552095 Auto-Submit: Than McIntosh <thanm@google.com> Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-04github: switch seen/expected order in issue formsSean Liao
Also fixup wording across other templates. Fixes #64890 Change-Id: I6f9ade440b6702ddfafc21ccb7fbc6cabc2b856e Reviewed-on: https://go-review.googlesource.com/c/go/+/553155 Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Joseph Tsai <joetsai@digital-static.net> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-01-04net/http: respond with 400 Bad Request for empty hex number of chunk lengthAndy Pan
Fixes #64517 Change-Id: I78b8a6a83301deee05c3ff052a6adcd1f965aef2 Reviewed-on: https://go-review.googlesource.com/c/go/+/553835 Auto-Submit: Damien Neil <dneil@google.com> Commit-Queue: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
2024-01-04net/http/cgi: in TestCopyError, check for a Handler.ServeHTTP goroutine ↵Bryan C. Mills
instead of a running PID Previously, the test could fail spuriously if the CGI process's PID happened to be reused in between checks. That sort of reuse is highly unlikely on platforms that cycle through the PID space sequentially (such as Linux), but plausible on platforms that use randomized PIDs (such as OpenBSD). Also unskip the test on Windows, since it no longer relies on being able to send signal 0 to an arbitrary PID. Also change the expected failure mode of the test to a timeout instead of a call to t.Fatalf, so that on failure we get a useful goroutine dump for debugging instead of a non-actionable failure message. Fixes #57369 (maybe). Change-Id: Ib7e3fff556450b48cb5e6ea120fdf4d53547479b Reviewed-on: https://go-review.googlesource.com/c/go/+/554075 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Damien Neil <dneil@google.com>
2024-01-04cmd/api: fix panic on exported basic type aliasesDevon H. O'Dell
The order of emitting named type and type aliases in the `Walker`'s `emitType` function is inverted. When the type alias references a basic type, this causes a panic as the type assertion on `*types.Named` fails. This change reorders the logic such that type aliases are emitted prior to this type assertion. Fixes #64958 Change-Id: I52dbe13999978912ded788d9cf4948103869bcfa Reviewed-on: https://go-review.googlesource.com/c/go/+/554076 Reviewed-by: Bryan Mills <bcmills@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Bryan Mills <bcmills@google.com>
2024-01-03pagetrace: fix build when experiment is onJohn Howard
due to a recent change, this experiment does not compile at all. This simply fixes to pass in the new required parameter. Change-Id: Idce0e72fa436a7acf4923717913deb3a37847fe2 Reviewed-on: https://go-review.googlesource.com/c/go/+/551415 Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-01-03net/http: make Request.Clone create fresh copies for matches and otherValuesJes Cok
This change fixes Request.Clone to correctly work with SetPathValue by creating fresh copies for matches and otherValues so that SetPathValue for cloned requests doesn't pollute the original request. While here, also added a doc for Request.SetPathValue. Fixes #64911 Change-Id: I2831b38e135935dfaea2b939bb9db554c75b65ef GitHub-Last-Rev: 1981db16475a49fe8d4b874a6bceec64d28a1332 GitHub-Pull-Request: golang/go#64913 Reviewed-on: https://go-review.googlesource.com/c/go/+/553375 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Run-TryBot: Jes Cok <xigua67damn@gmail.com> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Jonathan Amsterdam <jba@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-01-03doc/go1.22: add links to go/types symbolsAlan Donovan
Also, join three paragraphs that should have been one. Change-Id: Ib1c252f88a1e98afe157d477caa5323c0c8365e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/553715 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Eli Bendersky <eliben@google.com>
2024-01-03runtime: correct scavengeIndex.sysGrow min index handlingJoel Sing
The backing store for the scavengeIndex chunks slice is allocated on demand as page allocation occurs. When pageAlloc.grow is called, a range is allocated from a reserved region, before scavengeIndex.grow is called to ensure that the chunks needed to manage this new range have a valid backing store. The valid region for chunks is recorded as the index min and index max. Any changes need to take the existing valid range into consideration and ensure that a contiguous valid range is maintained. However, a bug in the min index handling can currently lead to an existing part of the chunk slice backing store being zeroed via remapping. Initially, there is no backing store allocated and both min and max are zero. As soon as an allocation occurs max will be non-zero, however it is still valid for min to be zero depending on the base addresses of the page allocations. A sequence like the following will trigger the bug: 1. A page allocation occurs requiring chunks [0, 512) (after rounding) - a sysMap occurs for the backing store, min is set to 0 and max is set to 512. 2. A page allocation occurs requiring chunks [512, 1024) - another sysMap occurs for this part of the backing store, max is set to 1024, however min is incorrectly set to 512, since haveMin == 0 (validly). 3. Another page allocation occurs requiring chunks [0, 512) - since min is currently 512 a sysMap occurs for the already mapped and inuse part of the backing store from [0, 512), zeroing the chunk data. Correct this by only updating min when either haveMax == 0 (the uninitialised case) or when needMin < haveMin (the case where the new backing store range is actually below the current allocation). Remove the unnecessary haveMax == 0 check for updating max, as the existing needMax > haveMax case already covers this. Fixes #63385 Change-Id: I9deed74c4ffa187c98286fe7110e5d735e81f35f Reviewed-on: https://go-review.googlesource.com/c/go/+/553135 Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Joel Sing <joel@sing.id.au>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 01:52:59 +0000