-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Go 1.22.2 #88
Merged
Merged
Go 1.22.2 #88
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
While at it, set the date to the Go 1.22 release date. Change-Id: I03872626e500433eb63786d24c67810c8c6289f4 Reviewed-on: https://go-review.googlesource.com/c/go/+/562337 Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/562320 Reviewed-by: Russ Cox <rsc@golang.org>
…builder name in test 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 golang#65470. Fixes golang#65471. 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 93f0c0b) Reviewed-on: https://go-review.googlesource.com/c/go/+/560696
…lders in tests This change updates the testenv tests to correctly match on future LUCI builder names for mobile builders. This isn't a problem today because those haven't been set up yet, but the builder names are structured and it's clear where the modifiers will appear. Might as well set them up now. For golang#65473. Fixes golang#65474. Change-Id: I244b88a62a90312c0f3ff2360527d58531070362 Reviewed-on: https://go-review.googlesource.com/c/go/+/558597 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 5c7c24c) Reviewed-on: https://go-review.googlesource.com/c/go/+/560536
…tion checking for clang Pending a resolution to golang#65606, this CL marks clang's ASAN runtime as unable to symbolize stack traces to unblock the LUCI clang builder. For golang#65606. For golang#65469. Fixes golang#65641. Change-Id: I649773085aff30e5703e7f7ac2c72a0430a015c2 Cq-Include-Trybots: luci.golang.try:go1.22-linux-amd64-clang15 Reviewed-on: https://go-review.googlesource.com/c/go/+/562675 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit d94ab59) Reviewed-on: https://go-review.googlesource.com/c/go/+/563015
…m stack traceReadCPU calls profBuf.read, which does a raceacquire. g0 does not have a race context, so this crashes when running on the system stack. We could borrow a race context, but it is simpler to just move traceReadCPU off of the system stack. For golang#65607. Fixes golang#65644. Change-Id: I335155b96d683aebb92b2f4e1eea063dd139f2d5 Reviewed-on: https://go-review.googlesource.com/c/go/+/562996 Auto-Submit: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> (cherry picked from commit 9fa153b) Reviewed-on: https://go-review.googlesource.com/c/go/+/562559
Fixes golang#65619. Change-Id: I55fef8cf7be4654c7242462d45f12999e0c91c02 Reviewed-on: https://go-review.googlesource.com/c/go/+/562322 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com> (cherry picked from commit 08370dc) Reviewed-on: https://go-review.googlesource.com/c/go/+/562815
… if function generic PGO uses noder.LookupFunc to look for devirtualization targets in export data. LookupFunc does not support type-parameterized functions, and will currently fail the build when attempting to lookup a type-parameterized function because objIdx is passed the wrong number of type arguments. This doesn't usually come up, as a PGO profile will report a generic function with a symbol name like Func[.go.shape.foo]. In export data, this is just Func, so when we do LookupFunc("Func[.go.shape.foo]") lookup simply fails because the name doesn't exist. However, if Func is not generic when the profile is collected, but the source has since changed to make Func generic, then LookupFunc("Func") will find the object successfully, only to fail the build because we failed to provide type arguments. Handle this with a objIdxMayFail, which allows graceful failure if the object requires type arguments. Bumping the language version to 1.21 in pgo_devirtualize_test.go is required for type inference of the uses of mult.MultFn in cmd/compile/internal/test/testdata/pgo/devirtualize/devirt_test.go. For golang#65615. Fixes golang#65618. Change-Id: I84d9344840b851182f5321b8f7a29a591221b29f Reviewed-on: https://go-review.googlesource.com/c/go/+/562737 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 532c6f1) Reviewed-on: https://go-review.googlesource.com/c/go/+/563016
The jump table symbol is accessed only from the function symbol (in the same package), so it can be static. Also, if the function is DUPOK and it is, somehow, compiled differently in two different packages, the linker must choose the jump table symbol associated to the function symbol it chose. Currently the jump table symbol is DUPOK, so that is not guaranteed. Making it static will guarantee that, as each copy of the function symbol refers to its own jump table symbol. Updates golang#65783. Fixes golang#65818. Change-Id: I27e051d01ef585d07700b75d4dfac5768f16441e Reviewed-on: https://go-review.googlesource.com/c/go/+/565535 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> (cherry picked from commit 2908352) Reviewed-on: https://go-review.googlesource.com/c/go/+/566475
…d at a DMB instruction CL 525637 changed to the guard of DMB instruction from the compiled-in runtime.goarm value to GOARM_7 macro and CPU feature detection. It missed a place where runtime.goarm is loaded to a register and reused later. This CL corrects the condition. Updates golang#65601. Fixes golang#65760. Change-Id: I2ddefd03a1eb1048dbec0254c6e234c65b054279 Reviewed-on: https://go-review.googlesource.com/c/go/+/564855 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> (cherry picked from commit a0226c5) Reviewed-on: https://go-review.googlesource.com/c/go/+/567555 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> TryBot-Bypass: Carlos Amedee <carlos@golang.org>
… set in NewAlias Types returned by the go/types API must be immutable (or at least concurrency safe), but NewAlias returned an alias without actual set. Ensure that actual is set by unaliasing. Also make some superficial simplifications to unalias, and avoid indirection where unnecessary. Fixes golang#65728 Change-Id: Ic9a020da5accf9032056a924b65c9e9e08cb2e0a Reviewed-on: https://go-review.googlesource.com/c/go/+/560915 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Robert Griesemer <gri@google.com> (cherry picked from commit 10a6564) Reviewed-on: https://go-review.googlesource.com/c/go/+/564356
…e for identifying goroutines To determine the identity of a goroutine for displaying in the trace UI, we should use the root frame from a call stack. This will be the starting function for the goroutine and is the same for each call stack from a given goroutine. The new tracer no longer includes starting PCs for goroutines which existed at the start of tracing, so we can't use a PC for grouping together goroutines any more. Instead, we just use the name of the entry function for grouping. For golang#65574 Fixes golang#65577 Change-Id: I5324653316f1acf0ab90c30680f181060ea45dd7 Reviewed-on: https://go-review.googlesource.com/c/go/+/562455 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit a517131) Reviewed-on: https://go-review.googlesource.com/c/go/+/562558 Reviewed-by: Michael Pratt <mpratt@google.com>
…main modules in verify 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 golang#62663 Fixes golang#65852 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 3f60da7) Reviewed-on: https://go-review.googlesource.com/c/go/+/565775 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Michael Matloob <matloob@golang.org>
…in phrase and obs-phrase Fixes a couple of misalignments with RFC 5322 which introduce significant diffs between (mostly) conformant parsers. This change reverts the changes made in CL50911, which allowed certain special RFC 5322 characters to appear unquoted in the "phrase" syntax. It is unclear why this change was made in the first place, and created a divergence from comformant parsers. In particular this resulted in treating comments in display names incorrectly. Additionally properly handle trailing malformed comments in the group syntax. For golang#65083 Fixed golang#65849 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/+/566215 Reviewed-by: Carlos Amedee <carlos@golang.org>
… on js and wasip1 For golang#65883. Updates golang#65177. Updates golang#65178. Updates golang#64321. Change-Id: I698fd3b688c7dfbde692eb7c29cbdafc89e7ca32 Cq-Include-Trybots: luci.golang.try:go1.22-js-wasm,go1.22-wasip1-wasm_wasmtime,go1.22-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> (cherry picked from commit f19f31f) Reviewed-on: https://go-review.googlesource.com/c/go/+/566175 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
…rshalJSON errors Escape "</script" and "<!--" in errors returned from MarshalJSON errors when attempting to marshal types in script blocks. This prevents any user controlled content from prematurely terminating the script block. Updates golang#65697 Fixes golang#65969 Change-Id: Icf0e26c54ea7d9c1deed0bff11b6506c99ddef1b Reviewed-on: https://go-review.googlesource.com/c/go/+/564196 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit ccbc725) Reviewed-on: https://go-review.googlesource.com/c/go/+/567535 Reviewed-by: Carlos Amedee <carlos@golang.org>
A recent change to Transport.dialConnFor introduced an early return that skipped dialing. This path did not call decConnsPerHost, which can cause subsequent HTTP calls to hang if Transport.MaxConnsPerHost is set. For golang#65705 Fixes golang#65759 Change-Id: I157591114b02a3a66488d3ead7f1e6dbd374a41c Reviewed-on: https://go-review.googlesource.com/c/go/+/564036 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Than McIntosh <thanm@google.com> (cherry picked from commit 098a87f) Reviewed-on: https://go-review.googlesource.com/c/go/+/566536 Reviewed-by: Carlos Amedee <carlos@golang.org>
…ore interface conversion alreadyInChain assumes all keys fit a interface which contains the Equal method (which they do), but this ignores that certificates may have a nil key when PublicKeyAlgorithm is UnknownPublicKeyAlgorithm. In this case alreadyInChain panics. Check that the key is non-nil as part of considerCandidate (we are never going to build a chain containing UnknownPublicKeyAlgorithm anyway). For golang#65390 Fixes golang#65831 Fixes CVE-2024-24783 Change-Id: Ibdccc0a487e3368b6812be35daad2512220243f3 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2137282 Reviewed-by: Damien Neil <dneil@google.com> Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2174343 Reviewed-by: Carlos Amedee <amedee@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569235 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
… matches on IPv6 zones When deciding whether to forward cookies or sensitive headers across a redirect, do not attempt to interpret an IPv6 address as a domain name. Avoids a case where a maliciously-crafted redirect to an IPv6 address with a scoped addressing zone could be misinterpreted as a within-domain redirect. For example, we could interpret "::1%.www.example.com" as a subdomain of "www.example.com". Thanks to Juho Nurminen of Mattermost for reporting this issue. Fixes CVE-2023-45289 Fixes golang#65859 For golang#65065 Change-Id: I8f463f59f0e700c8a18733d2b264a8bcb3a19599 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2131938 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2174344 Reviewed-by: Carlos Amedee <amedee@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569236 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
…d read in MIME header mime/multipart.Reader.ReadForm allows specifying the maximum amount of memory that will be consumed by the form. While this limit is correctly applied to the parsed form data structure, it was not being applied to individual header lines in a form. For example, when presented with a form containing a header line that never ends, ReadForm will continue to read the line until it runs out of memory. Limit the amount of data consumed when reading a header. Fixes CVE-2023-45290 Fixes golang#65850 For golang#65383 Change-Id: I7f9264d25752009e95f6b2c80e3d76aaf321d658 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2134435 Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2174345 Reviewed-by: Carlos Amedee <amedee@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569237 Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
Change-Id: I9db641e2a029c4c9fa72d7b423b2b6b7f113d9a2 Reviewed-on: https://go-review.googlesource.com/c/go/+/569257 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
…est packages This patch fixes a bug in the code that reports coverage percentages and/or profiles for packages without tests. Specifically, the code added as part of the fix for issue 24570 (in CL 495447) didn't properly consider the -coverpkg selection and would look for the build action meta-data file for a package that wasn't actually selected for coverage. Updates golang#65653. Fixes golang#66137. Change-Id: I66ffac11783c00a8cbd855fd05b9a90e4e0ed402 Reviewed-on: https://go-review.googlesource.com/c/go/+/568835 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Bryan Mills <bcmills@google.com> (cherry picked from commit 2b22fc1) Reviewed-on: https://go-review.googlesource.com/c/go/+/569575
…elf_* symbols The runtime.elf_* symbols are assembly functions which are used to support the gcc/llvm -Os option when used with cgo. When compiling Go for shared code, we attempt to strip out the TOC regenation code added by the go assembler for these symbols. This causes the symbol to no longer appear as an assembly function which causes problems later on when handling other implicit symbols. Avoid adding a TOC regeneration prologue to these functions to avoid this issue. Fixes golang#66412 Change-Id: Icbf8e4438d177082a57bb228e39b232e7a0d7ada Reviewed-on: https://go-review.googlesource.com/c/go/+/571835 Reviewed-by: Than McIntosh <thanm@google.com> Run-TryBot: Paul Murphy <murp@ibm.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/572875
…ptimization CL 541715 added an optimization to copy SSA-able variables. When handling m[k] = append(m[k], ...) case, it uses ir.SameSafeExpr to check that m[k] expressions are the same, then doing type assertion to convert the map index to ir.IndexExpr node. However, this assertion is not safe for m[k] expression in append(m[k], ...), since it may be wrapped by ir.OCONVNOP node. Fixing this by un-wrapping any ir.OCONVNOP before doing type assertion. Fixes golang#66178 Change-Id: I9ff7165ab97bc7f88d0e9b7b31604da19a8ca206 Reviewed-on: https://go-review.googlesource.com/c/go/+/569716 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569818 Reviewed-by: David Chase <drchase@google.com>
…atement CL 517775 moved early deadcode into unified writer. with new way to handle dead code with label statement involved: any statements after terminating statement will be considered dead until next label statement. However, this is not safe, because code after label statement may still refer to dead statements between terminating and label statement. It's only safe to remove statements after terminating *and* label one. Fixes golang#66134 Change-Id: Idb630165240931fad50789304a9e4535f51f56e2 Reviewed-on: https://go-review.googlesource.com/c/go/+/565596 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/569717 Reviewed-by: Michael Knyszek <mknyszek@google.com>
…itution Fixes golang#65858. For golang#65778. // for x/tools/cmd/gotype Change-Id: I67d4644b28e831926fc6c233098aa1755c57162f Reviewed-on: https://go-review.googlesource.com/c/go/+/565835 Auto-Submit: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/565840 Run-TryBot: Robert Griesemer <gri@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
…t symbols for R_RISCV_CALL Correctly generate local text symbols needed for R_RISCV_CALL when external linking. R_RISCV_CALL was added in CL #520095 as a way of marking AUIPC+JALR pairs, instead of overloading R_RISCV_PCREL_ITYPE. However, genSymsLate was not updated to generate local text symbols for the new relocation type, leading to HI20 symbol lookup failures. This issue is detected by cmd/internal/obj/riscv.TestLargeCall, however this is unfortunately skipped in short mode. Fixes golang#66060 Change-Id: I8ee0f13791e0628f31657bf7dae2be8482b689b5 Reviewed-on: https://go-review.googlesource.com/c/go/+/567375 Reviewed-by: Mauri de Souza Meneguzzo <mauri870@gmail.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Run-TryBot: Joel Sing <joel@sing.id.au> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit b5a64ba) Reviewed-on: https://go-review.googlesource.com/c/go/+/568157 Reviewed-by: Than McIntosh <thanm@google.com>
…ws in the new tracer The value produced for the EvFrequency event on Windows is missing the fact that the cputicks clock gets divided. This results in durations that are consistently wrong by the same factor (about 256). For golang#65997. Fixes golang#66201. Change-Id: I930cbfce3499d435c20699f41c11e3227d84f911 Reviewed-on: https://go-review.googlesource.com/c/go/+/567937 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> (cherry picked from commit 707eba9) Reviewed-on: https://go-review.googlesource.com/c/go/+/570195 Reviewed-by: Than McIntosh <thanm@google.com>
… to git before subcommands I accidentally transposed the arguments in CL 556358, causing the shallow 'git fetch' attempt to always fail. That didn't break any tests because we fall back to a full fetch, which works for nearly all real Git servers, and we didn't have a test that checked for shallow fetches. Tested manually using: GOPROXY=direct go mod download -x -json gerrit.wikimedia.org/r/mediawiki@v0.0.0-20240202145822-67da0cbcfdf7 (I'm still thinking about how to add a proper regression test.) Fixes golang#66256. Updates golang#66147. Change-Id: I0bb17283bae856f369fd24f29375e507d0999933 Reviewed-on: https://go-review.googlesource.com/c/go/+/569422 Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> (cherry picked from commit 2ab9218) Reviewed-on: https://go-review.googlesource.com/c/go/+/570737 Reviewed-by: Sam Thanawalla <samthanawalla@google.com>
…le again The OID type is not exported data like most of the other x509 structs. Using it in x509.Certificate made Certificate not gob-compatible anymore, which breaks real-world code. As a temporary fix, make gob ignore that field, making it work as well as it did in Go 1.21. For Go 1.23, we anticipate adding a proper fix and removing the gob workaround. See golang#65633 and golang#66249 for more details. For golang#66249. For golang#65633. Fixes golang#66273. Change-Id: Idd1431d15063b3009e15d0565cd3120b9fa13f61 Reviewed-on: https://go-review.googlesource.com/c/go/+/571095 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/571715 Reviewed-by: David Chase <drchase@google.com>
When an opcode generates a known high bit state (typically, a sub-word operation that zeros the high bits), we can remove any subsequent extension operation that would be a no-op. x = (OP ...) y = (ZeroExt32to64 x) If OP zeros the high 32 bits, then we can replace y with x, as the zero extension doesn't do anything. However, x in this situation normally has a sub-word-sized type. The semantics of values in registers is typically that the high bits beyond the value's type size are junk. So although the opcode generating x *currently* zeros the high bits, after x is rewritten to another opcode it may not - rewrites of sub-word-sized values can trash the high bits. To fix, move the extension-removing rules to late lower. That ensures that their arguments won't be rewritten to change their high bits. I am also worried about spilling and restoring. Spilling and restoring doesn't preserve the high bits, but instead sets them to a known value (often 0, but in some cases it could be sign-extended). I am unable to come up with a case that would cause a problem here, so leaving for another time. Update golang#66076 Change-Id: I3b5c091b3b3278ccbb7f11beda8b56f4b6d3fde7 Reviewed-on: https://go-review.googlesource.com/c/go/+/568616 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> (cherry picked from commit a46ecdc) Reviewed-on: https://go-review.googlesource.com/c/go/+/573375
…o-extended On amd64, we always zero-extend when loading arguments from the stack. On arm64, we extend based on the type. This causes problems with zeroUpper*Bits, which reports the top bits are zero when they aren't. Fix it to use the type to decide if the top bits are really zero. For tests, only f32 currently fails on arm64. Added other tests just for future-proofing. Fixes golang#66076 Change-Id: I2f13fb47198e139ef13c9a34eb1edc932eea3ee3 Reviewed-on: https://go-review.googlesource.com/c/go/+/571135 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 6bf8b76) Reviewed-on: https://go-review.googlesource.com/c/go/+/573395 Reviewed-by: Cherry Mui <cherryyz@google.com>
Pulls in one HTTP/2 fix: ae3c50b55f http2: reject DATA frames after 1xx and before final headers For golang#65927 Fixes golang#66255 Change-Id: Ib810455297083fc0722a997d0aa675132c38393c Reviewed-on: https://go-review.googlesource.com/c/go/+/574935 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Disable cmd/internal/moddeps test, since this update includes PRIVATE track fixes. Fixes CVE-2023-45288 For golang#65051 Fixes golang#66298 Change-Id: I5bbf774ebe7651e4bb7e55139d3794bd2b8e8fa8 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/2197227 Reviewed-by: Tatiana Bradley <tatianabradley@google.com> Run-TryBot: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/576076 Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Change-Id: I9f348a8ddc79c65be86099839523548edef30095 Reviewed-on: https://go-review.googlesource.com/c/go/+/576118 Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Than McIntosh <thanm@google.com> Commit-Queue: Gopher Robot <gobot@golang.org>
…into tailscale.go1.22 Go 1.22.2
This replaces a map used as a set with a slice. We were using a surprising amount of CPU in this code, making mapiters to pull out a random element of the map. Instead, just rand.IntN to pick a random element of the slice. It also adds a benchmark: │ before │ after │ │ sec/op │ sec/op vs base │ ConnRequestSet-8 1818.0n ± 0% 452.4n ± 0% -75.12% (p=0.000 n=10) (whether random is a good policy is a bigger question, but this optimizes the current policy without changing behavior) Updates golang#66361 Change-Id: I3d456a819cc720c2d18e1befffd2657e5f50f1e7 Reviewed-on: https://go-review.googlesource.com/c/go/+/572119 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Brad Fitzpatrick <bradfitz@golang.org>
Zero out elements before shrinking the slice to avoid memory leaks. Fixes golang#66410 Change-Id: I8f64c21455761f7f7c8b6fee0b6450b98f691d91 GitHub-Last-Rev: b15586e GitHub-Pull-Request: golang#66419 Reviewed-on: https://go-review.googlesource.com/c/go/+/572956 TryBot-Result: Gopher Robot <gobot@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
bradfitz
changed the title
database/sql: fix memory leaks in Stmt.removeClosedStmtLocked
Go 1.22.2
Apr 3, 2024
raggi
approved these changes
Apr 3, 2024
dsnet
reviewed
Apr 3, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In light of recent supply chain attacks, I looked through the commits and LGTM.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Go 1.22.2