Repository navigation
Go 1.27.2 - #191
Merged
Merged
Go 1.27.2#191
Conversation
CL 729201 removed itablinks. The runtime now walks the itab section of a module when it starts and when it loads a plugin. A plugin has its own copy of the itabs that the main program also has. Before CL 729201, dynamic symbol resolution pointed the itablinks entries of the plugin at the itabs of the main program, so add skipped them. Now add puts the copies of the plugin into the table as second entries for the same interface/type pairs. Type switches and type assertions compare the itab pointer of a value with the itab that the linker put into the module. In the plugin, that itab also resolves to the copy of the main program. After the itab table grows and rehashes its entries, find can return the copy of the plugin, and type switches in the main program take the default case. With Go 1.27, golangci-lint panics in go/ast.Walk with "unexpected node type *ast.DeferStmt" after it loads its third linter plugin (kubernetes/kubernetes#141663). Make add skip an itab when the table already has one for the same interface/type pair. For golang#81303 Fixes golang#81324 Change-Id: Ia78e597fff9fd870924c1ebc94453523f3e7578b Reviewed-on: https://go-review.googlesource.com/c/go/+/826244 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Jordan Liggitt <liggitt@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> (cherry picked from commit 2d04c9d) Reviewed-on: https://go-review.googlesource.com/c/go/+/827664
…s used for tail call wrappers CL 751465 updated the compiler to use tail calls for embedded interface wrappers, but the underlying interface calls were not marked as used. As a result, the linker incorrectly drops the callee via DCE, triggering an unreachable method runtime panic. This change fixes the issue by marking the interface calls as used when walking tail call nodes. Fixes golang#81353 Change-Id: I3d433b645f95179698c4b739c89a4e9a2c908604 Reviewed-on: https://go-review.googlesource.com/c/go/+/827624 Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/830505 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
We were packing the size into an int32, which isn't valid for really large move/zero. Instead, put the alignment in the aux field so we can use the entire auxint field for the size. Cherry pick of CL 824984 (the main one) and CL 827324 (a small fixup). Fixes golang#81296 Change-Id: I552a5fc990a6fc1fcc4c72cd2d532011952e83e5 Reviewed-on: https://go-review.googlesource.com/c/go/+/828865 Reviewed-by: Meng Zhuo <mengzhuo1203@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Joel Sing <joel@sing.id.au> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
…amed string map keys In Go 1.26, MarshalText methods were never called on named string map keys, while it is called after the switch to using the v2 implementation. Adjust the legacy compatibility layer to preserve historical behavior. Updates golang#81355 Fixes golang#81362 Change-Id: I0bcc85da4bf933acebd7e2736d0f820c62f2201d Reviewed-on: https://go-review.googlesource.com/c/go/+/827864 Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 714d9af) Reviewed-on: https://go-review.googlesource.com/c/go/+/832764
…esponse body Read and Close In HTTP/1, if we close a response body early prior to EOF, while allowing a concurrent read to happen, a deadlock will occur if the read reaches EOF. This is because both calls wait on the same eofc channel, and the persistConn readLoop only sends one value to the channel. This problem only occurs after the implementation of automatic response body draining; prior to that, closing the response body early will cause the eofc channel to be closed, unblocking all calls. Fix this by making sure that bodyEOFSignal.earlyCloseFn and bodyEOFSignal.fn are mutually exclusive. Additionally, disambiguate between when a response body has been closed early vs when reading it returns a non-EOF error. Otherwise, when the body read returns a non-EOF error, persistConn readLoop will linger around trying to send to eofc until the response body is closed rather than exiting immediately. For golang#81404 Fixes golang#81411 Change-Id: I706ba39afd08b605fa80bb9d99114f4f6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/829984 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit e51216d) Reviewed-on: https://go-review.googlesource.com/c/go/+/830424
… in readLoop CL 829984 changed how readLoop waits for the caller to finish with a response body that is closed before EOF. In the errClosedEarly case it now sends on eofc first and reads resp.ContentLength after. The send is what lets the caller's Body.Close return, and the Response belongs to the caller from then on. Before CL 829984 the read came first, while the caller was still blocked in Close. Any caller that modifies the Response after closing its body races with that read. httputil.ReverseProxy.ModifyResponse callbacks that close the backend body and replace *resp do exactly that, and Kubernetes' apiserver proxy tests now fail under -race on Go tip (kubernetes/kubernetes#142079). Read ContentLength before signaling eofc, as before. For golang#81510 Fixes golang#81515 Change-Id: I900d92bed6c7cc34384ec483da07c3694cdf0012 Reviewed-on: https://go-review.googlesource.com/c/go/+/831964 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Nicholas Husin <nsh@golang.org> Reviewed-by: Nicholas Husin <husin@google.com> Auto-Submit: Nicholas Husin <nsh@golang.org> (cherry picked from commit 08cff59) Reviewed-on: https://go-review.googlesource.com/c/go/+/832344 Reviewed-by: Damien Neil <dneil@google.com>
…failed Read CL 829984 made bodyEOFSignal.condfn clear earlyCloseFn as well as fn. After a Read that returns a non-EOF error, Close therefore no longer takes the earlyCloseFn path, which returned nil. It falls through to (*body).Close, whose drain reads the body again, gets the same sticky error, and returns it. Before CL 829984 Close returned nil here. Callers that check the error from Close now see the Read error twice. Kubernetes' apiserver tests assert Close() == nil after an aborted response and fail on Go tip with "tls: bad record MAC" and "unexpected EOF" from Close (kubernetes/kubernetes#142079). Skip the drain when rerr is a non-EOF error and return nil; readLoop has already given up the connection. Unlike the old earlyCloseFn path this does not wait for readLoop to exit, but the connection is being torn down either way. CL 829984 added a TestTransportResponseBodyDrainReadAndClose case that expects the Read error from Close; this changes it to expect nil. For golang#81511 Fixes golang#81516 Change-Id: Ic3a8ff893230002bed2637c9b4ad4f524e25e831 Reviewed-on: https://go-review.googlesource.com/c/go/+/832464 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…ponse body When a server sends trailers, transport will automatically populate Response.Trailer upon reading the response body to EOF. When a user closes the response body early, it is possible that the transport will automatically drain the response body to EOF, and populate Response.Trailer at the same time as when a user might access it, resulting in a race condition. This is probably a pretty unlikely scenario, as reading trailers without reading a response body to completion does not really make sense (it will always be empty). It is nonetheless worth fixing. For golang#81521 Fixes golang#81522 Change-Id: Id0411a4c198a6fc7bfb7c97d550d57666a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/832264 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Nicholas Husin <husin@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit eeb35e6) Reviewed-on: https://go-review.googlesource.com/c/go/+/832444
…ming-related headers Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling. Therefore, delete malformed framing-related headers in our HTTP/2 transport, so they will not be forwarded to a potentially vulnerable HTTP/1 client. Thank you to TJ Barton for reporting this issue. For golang#81115 Fixes golang#81585 Fixes CVE-2026-78660 Change-Id: I43e1d124c1672549e47efa08756772836a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/836525 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…nt with the kernel header include/uapi/linux/eventpoll.h packs struct epoll_event only on amd64, so data is a plain __u64 everywhere else. Most ports copied the packed amd64 declaration anyway, which on the 64-bit ports was a bug: [8]byte is 1-aligned, leaving the struct 4-aligned while runtime.netpoll reads the field as a uintptr load that cause unaligned access on mips64x. Fixes golang#81437 Change-Id: Ia584f62e716dc49f880bd8df2ac877f97947f415 Reviewed-on: https://go-review.googlesource.com/c/go/+/819660 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit 1190f7d) Reviewed-on: https://go-review.googlesource.com/c/go/+/838365 Reviewed-by: Mark Freeman <mark@golang.org>
…se element interior escapes The slice backing store pass counts s[i] as exclusivity-preserving, so it gives up when it sees &s[i]. But that check only matched an OADDR directly over an OINDEX, so &s[i].f slipped through with an ODOT in between, and the backing store stayed in the frame while a pointer into it was returned. To fix this, walk down the field selectors and array indexes under an OADDR to find the object actually being addressed. ODOTPTR, ODEREF and indexing through a pointer to an array reach a different object, so the walk stops there. Fixes golang#81667 Change-Id: If8a105eab1f596901d8148fa9d2376669737f77d Reviewed-on: https://go-review.googlesource.com/c/go/+/836025 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> (cherry picked from commit 2b9e678) Reviewed-on: https://go-review.googlesource.com/c/go/+/837085 Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
…der Windows Windows 10 build 10240 rejects NtCreateFile calls using OBJ_DONT_REPARSE with STATUS_INVALID_PARAMETER. This breaks os.Root operations and, since CL 661575, recursive RemoveAll calls. When this occurs, retry single-component relative opens with FILE_OPEN_REPARSE_POINT and inspect the opened handle before truncation or enabling delete-on-close. For delete-on-close, reopen the validated file through its handle to avoid resolving the pathname again. Root and RemoveAll already walk paths one component at a time, so this fallback preserves their no-follow protections without implementing general multi-component traversal. Fixes golang#81402. Updates golang#78131. Change-Id: Idc766a8e8368062d5e9c73bbbc2de7b894a10e40 Reviewed-on: https://go-review.googlesource.com/c/go/+/828644 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> (cherry picked from commit 59ea07b) Reviewed-on: https://go-review.googlesource.com/c/go/+/832804 Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
…nary into the output When using a dictionary, fillWindow was not setting blockStart, which caused a non-compressed block in first position to write the dictionary. This mixup can happen because window stores both the look back window and the block we are about to write. Set blockStart to skip over the dictionary if we have to write the window. For golang#80538 Fixes golang#81233 Change-Id: I6e6784696f29591f2819fc3c9c461d73d3d6335b GitHub-Last-Rev: 469f26b GitHub-Pull-Request: golang#80539 Reviewed-on: https://go-review.googlesource.com/c/go/+/804680 Auto-Submit: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Mark Freeman <markfreeman@google.com> (cherry picked from commit 655a713) Reviewed-on: https://go-review.googlesource.com/c/go/+/829764 Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Klaus Post <klauspost@gmail.com>
…undled ios/arm64 binaries CL 769360 replaced CFBundleCopyResourceURL(Info.plist) with CFBundleCopyBundleURL when porting the ios/arm64 working directory setup from C to Go. The old call returned NULL for an executable that is not inside an app bundle, and that suppressed the chdir. CFBundleCopyBundleURL returns the directory holding the executable instead, so an ios/arm64 binary run outside an app bundle now chdirs there at startup and loses the working directory it inherited. cmd/go built for ios/arm64 no longer finds go.mod as a result. Restore the Info.plist check as the condition for the chdir, keeping CFBundleCopyBundleURL for the path itself. Updates golang#81465 Fixes golang#81469 Change-Id: I1b55ac476340176753dde19b65e28e37c896a260 Reviewed-on: https://go-review.googlesource.com/c/go/+/830864 Reviewed-by: Junyang Shao <shaojunyang@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Quim Muntal <quimmuntal@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> (cherry picked from commit 16e9662) Reviewed-on: https://go-review.googlesource.com/c/go/+/832224 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Mark Freeman <mark@golang.org>
…json mode Fix ANSI escape sequence corruption (ESC doubling) in t.Log output in plain (-test.v) mode introduced by CL 751940. For golang#81577 Fixes golang#81580 Change-Id: I968ac99d46280be16d88e867b8b6c651816715cf Reviewed-on: https://go-review.googlesource.com/c/go/+/834264 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Sean Liao <sean@liao.dev> Reviewed-on: https://go-review.googlesource.com/c/go/+/837405 Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Mark Freeman <mark@golang.org>
…call The OTAILCALL path ends its block with BlockRetJmp and never goes through state.exit, which is the only place that emits a call to runtime.racefuncexit. So a compiler-generated wrapper that ends in a tail call tells the race detector that it was entered but never that it returned, leaking an entry in the race detector's shadow stack on every call. To fix this, just emitting racefuncexit before the tail call. Fixes golang#81666 Change-Id: I4c3344d10ca239db1669ecf133704dd6cebca11b Reviewed-on: https://go-review.googlesource.com/c/go/+/832244 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org> (cherry picked from commit cd6dd4c) Reviewed-on: https://go-review.googlesource.com/c/go/+/836989 Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Mark Freeman <mark@golang.org>
Pull in changes from x/tools that affect go fix. Fixes golang#81389 Updates golang#81306 Change-Id: I195cfe8b5677fe977980869a93e28d99bebdf82c Reviewed-on: https://go-review.googlesource.com/c/go/+/837585 Reviewed-by: Mark Freeman <mark@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
…method indices) Unified V4 (go1.27.0) encoded nongeneric methods followed by generic methods, losing the source order of methods on a named type, breaking objectpath, and causing crashes (see golang#81188). This changes support for unified v5 (encoding in cmd/compile, decoding in go/internal). Once this is released in go1.27.0, applications built with the latest x/tools decoder will not crash. See CL 826064 for the x/tools unified V5 decoder. Updates golang#81188 Fixes golang#81306 Change-Id: I48073fde7af282addd128c536913511a171f9053 Reviewed-on: https://go-review.googlesource.com/c/go/+/826105 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-on: https://go-review.googlesource.com/c/go/+/842385 Reviewed-by: Michael Pratt <mpratt@google.com>
…r NewFile handles On Windows, handles to the same file object share completion notification modes. NewFile doesn't know who else is using the file object, so changing these modes can break their I/O, even in another process. For NewFile, leave the modes alone and check the skip-success flag so we know whether to wait for IOCP completions. Updates golang#80979 Fixes golang#81374 Change-Id: I9b84ad42d373b918a733aff180beb71b96474136 Reviewed-on: https://go-review.googlesource.com/c/go/+/828584 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com> (cherry picked from commit d889729) Reviewed-on: https://go-review.googlesource.com/c/go/+/832784 Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Quim Muntal <quimmuntal@gmail.com>
Vetting a package only as a dependency (VetxOnly) computes facts but reports no diagnostics. Its empty output was cached under the same action ID as a full vet of that package, so a later go vet of the package replayed the empty output and missed its findings. For golang#81757 Fixes golang#81861 Change-Id: Ibedaccaa4d344d7858ea8261a98106ead3a8e89a Reviewed-on: https://go-review.googlesource.com/c/go/+/839445 Auto-Submit: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> (cherry picked from commit 77881b0) Reviewed-on: https://go-review.googlesource.com/c/go/+/842065 Reviewed-by: Mark Freeman <mark@golang.org>
…arsing float If there is an error parsing a float (e.g., overflow) avoid setting the value. This matches the behavior for ints and uints. Updates golang#81062 Fixes golang#81084 Change-Id: I79be95d120cae44cf55fd943c428834b9e3a9425 Reviewed-on: https://go-review.googlesource.com/c/go/+/820580 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> (cherry picked from commit 94b71ff) Reviewed-on: https://go-review.googlesource.com/c/go/+/842145 Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: Joseph Tsai <joetsai@digital-static.net>
…nnection state The HTTP/2 server only sets Request.TLS for requests with an https :scheme. This leaves it nil for requests to http targets through a TLS proxy, and for CONNECT requests, which omit :scheme. In Go 1.27, CL 765360 started calling the internal HTTP/2 server directly, bypassing initALPNRequest, which previously filled in a missing TLS state. This exposed the scheme-dependent initialization to net/http handlers. Request.TLS describes the connection on which a request was received, while :scheme describes the request target. Set Request.TLS from the connection state regardless of the scheme. Unencrypted connections continue to have a nil TLS state. Test https and http targets and CONNECT requests over both TLS and unencrypted HTTP/2 connections. For golang#81384 Fixes golang#81816 Change-Id: Ibbb98dbe7183ac29b727aea30f989bf5e85a4242 Reviewed-on: https://go-review.googlesource.com/c/go/+/829184 Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit a14b543) Reviewed-on: https://go-review.googlesource.com/c/go/+/842445 Reviewed-by: Mark Freeman <mark@golang.org>
…e regression In Go1.27, where v1 is now implemented using v2, the UnsupportedValueError.Value field was no longer populated. However, there are reports that code depends on this field, so populate it in the compatibility shim layer. For golang#81176 Fixes golang#81229 Change-Id: Iaa18d9ed2978014e00c8825bf6da901cc92c4062 Reviewed-on: https://go-review.googlesource.com/c/go/+/824384 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit 1903bc2) Reviewed-on: https://go-review.googlesource.com/c/go/+/842008 Reviewed-by: Mark Freeman <mark@golang.org>
…rotate amounts On a 32-bit platform a Const64 rotate amount is rewritten to a Const32, but the new value kept the original 64-bit type. The rule that folds a rotate of a rotate compares the two amounts by type size, so it saw two 8-byte amounts and combined them with an Add64. decompose builtin then split that Add64 into an Int64Lo of a Const32, which no dec64 rule matches, and the compiler failed with "not lowered". For golang#81687 Fixes golang#81706 Change-Id: I2ad709c57ea7a59bcee6978459904a5a5300595d Reviewed-on: https://go-review.googlesource.com/c/go/+/837245 Reviewed-by: Jorropo <jorropo.pgm@gmail.com> Reviewed-by: Mark Freeman <mark@golang.org> Auto-Submit: Jorropo <jorropo.pgm@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> (cherry picked from commit 6b3800e) Reviewed-on: https://go-review.googlesource.com/c/go/+/842565
…epoint bug Frameless tail calls end with MOVD Rx, CTR; BR (CTR), but the compiler was not marking the point between those two instructions as unsafe for async preempt. The async preempt fundamentally smashes CTR (it needs some register to jump to, and LR is taken), so we have to mark the sequence as not-async-safe. This is the root cause of many linux-ppc64le flakes on the issue tracker. Reproduced using qemu-ppc64le with 1-instruction basic block translation (repro program on golang#78576). For golang#78576. For golang#78199. For golang#78821. For golang#78897. For golang#78915. Fixes golang#81818. Change-Id: I1bf851c3461160d1a685e189f518be766a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/821480 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit f0fb6be) Reviewed-on: https://go-review.googlesource.com/c/go/+/842465 Reviewed-by: Mark Freeman <mark@golang.org>
… stack LockOSThread call can reach newosproc on a goroutine stack while starting the template thread. CL 746300 changed newosproc from stdcall, which switches to the system stack, to createThread, which uses stdcall_no_g and does not switch stacks. Native CreateThread code can then overrun the goroutine stack and corrupt adjacent memory. Run createThread on the system stack, including its retry loop. Updates golang#81731 Fixes golang#81829 Change-Id: I41e7083bb916c86c7411718d9506d8fa777e2d5e Reviewed-on: https://go-review.googlesource.com/c/go/+/840525 Reviewed-by: Mark Freeman <mark@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit 9a5f58a) Reviewed-on: https://go-review.googlesource.com/c/go/+/841305 Reviewed-by: Cherry Mui <cherryyz@google.com>
…itting coverage blocks The comment and blank-line filtering in cmd/cover can split a straight-line basic block into multiple coverage ranges. The statement count passed to newCounter was still the count of the entire basic block, so every split range received the same NumStmt value. This duplicated statements in coverage profiles and inflated reported statement coverage. Count the statements belonging to each range before emitting its counter. Add a regression test covering a block split into multiple ranges. For golang#80974 Fixes golang#81832 Change-Id: I872cda3a4ba401764c700d3a36ad93fd6cacd38d Reviewed-on: https://go-review.googlesource.com/c/go/+/819000 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Junyang Shao <shaojunyang@google.com> (cherry picked from commit d67021d) Reviewed-on: https://go-review.googlesource.com/c/go/+/842585 Reviewed-by: Mark Freeman <mark@golang.org> Reviewed-by: shuang cui <imcusg@gmail.com>
…hen building plugin on macOS The dynamic linker in macOS 27 checks the number of segments recorded in the LC_DYLD_CHAINED_FIXUPS load command, and reject the shared object when there is a mismatch. When combining DWARF, we add a segment but currently don't fix up the recorded number. Pass -no_fixup_chains to the C linker, so it doesn't use LC_DYLD_CHAINED_FIXUPS. This is a minimal workaround that we can backport to Go 1.26 and Go 1.27. Long term, we should emit split DWARF (golang#62577). Updates golang#81793. Fixes golang#81890. Change-Id: I991e046348db9250b8d583b633d5502b1cf3502a Reviewed-on: https://go-review.googlesource.com/c/go/+/841665 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit 01e4798) Reviewed-on: https://go-review.googlesource.com/c/go/+/842007 Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com>
…expressions Ensure that regular expressions at the start of each expression receive regular expression escaping. Fixes CVE-2026-94448 For golang#81821 Fixes golang#81924 Change-Id: Ia0bcb01f38d011035553a46375748d7433185889 Reviewed-on: https://go-review.googlesource.com/c/go/+/839866 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> (cherry picked from commit cb1e5f4) Reviewed-on: https://go-review.googlesource.com/c/go/+/843225 Reviewed-by: Michael Pratt <mpratt@google.com>
…eceder keyword Ensure that yield receives regular expression escaping when used as a keyword. Similarly, ensure that non-keyword uses are not escaped. A trusted template author has no reason to write `await` followed by a regular expression since they are not a promise; additionally, there is no valid JS+html/template context in which `default` followed by a regular expression is plausibly correct. Fixes CVE-2026-97030 For golang#81823 Fixes golang#81910 Change-Id: I5dc76cf958cdc2a43d02c8683da589aff1296225 Reviewed-on: https://go-review.googlesource.com/c/go/+/840925 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Damien Neil <dneil@google.com> (cherry picked from commit 47cf464) Reviewed-on: https://go-review.googlesource.com/c/go/+/843645 Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
…g/fips140 Instead of providing a carve-out for the golang.org/fips module, add the canonical go.sum h1 hash to its trusted fips140.sum file. When a modfetch would normally see this bundled module, use the trusted ziphash in fips140.sum to populate its entry in the GOMODCACHE. Fixes CVE-2026-94444 For golang#81833 Fixes golang#81912 Change-Id: Ib8ebf0837e56fb8825e4526a7114b61ac843fd0b Reviewed-on: https://go-review.googlesource.com/c/go/+/843646 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Neal Patel <nealpatel@google.com>
…h sumdb Instead of allowing a matching entry that specifies golang.org/toolchain, always go to the network to obtain the canonical checksum. Fixes CVE-2026-94447 For golang#81834 Fixes golang#81914 Change-Id: I5bffb80f7f18e3c1ac7b5e7ef027a4acf1f2a7e1 Reviewed-on: https://go-review.googlesource.com/c/go/+/843587 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
…rences Using a single cursor, reject malformed encodings and esnure that each outer extension is copied at most once. Fixes CVE-2026-97031 For golang#81855 Fixes golang#81916 Change-Id: I5b09f2b6275d42f7701fae4e583eb3a2caeaa44d Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5320 Reviewed-by: Roland Shoemaker <bracewell@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6140 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/847025 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Gopher Robot <gobot@golang.org> TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
…irst line readMIMEHeader subtracted 400 bytes from its maxMemory parameter, for overhead accounting, but did not check to see if this caused maxMemory to become negative. When called with a small maxMemory limit, this disabled the memory limit (<0: unlimited) for the first line read. Drop the 400 byte adjustment entirely, as serving no useful purpose: If the caller wants to deduct some amount per MIMEHeader, they may do so. Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue. Fixes CVE-2026-94440 For golang#81741 Fixes golang#81902 Change-Id: I0f42d331b2355346b07d1b9987a488996a6a6964 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5680 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6141 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/847026 Auto-Submit: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
…CT pool corruption
When the HTTP/1 transport sends a CONNECT request, it sends the
Request.Body along with the headers.
CONNECT requests do not contain data.
If the server accepts the CONNECT, the Request.Body becomes the
outbound tunneled data. If the server rejects the CONNECT, however,
the Request.Body becomes the start of a new request on the connection.
The transport improperly returns the connection to the pool. If the
data on the connection is a valid request, the next request sent
on the connection will read the response to that prior request.
There are a number of problems in net/http's handling of CONNECT
requests. This CL is a minimal change to avoid exploitable misbehavior
in the transport.
- Transport closes a connection after making a CONNECT request,
regardless of the response it gets.
- ReverseProxy rejects CONNECT requests with 405 Method Not Allowed.
Thanks to Xclow3n (Rajat Raghav) for reporting this issue.
Fixes CVE-2026-56866
For golang#81740
Fixes golang#81900
Change-Id: Ie101b9345a9c4b3525476c0627fa0b736a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5640
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6180
Reviewed-on: https://go-review.googlesource.com/c/go/+/847027
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
…ter CONNECT When a server HTTP handler responds to an HTTP/1 CONNECT request with a 2xx response and returns without taking ownership of (hijacking) the connection, the server incorrectly continues to read requests from the connection. Since a 2xx response to a CONNECT converts the connection into a tunnel, this can result in parser misalignment between the net/http server and intermediate proxies, and a potential request smuggling vector. There are a number of problems in net/http's handling of CONNECT requests. This CL is a minimal change to avoid exploitable misbehavior in the server. The HTTP/1 server now always closes a connection after handling a CONNECT request, if the handler did not hijack the connection. Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue. Fixes CVE-2026-94439 For golang#81744 Fixes golang#81908 Change-Id: I260f23ca8c8fbe51abb2bdfef5afb2d96a6a6964 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5641 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6142 Reviewed-on: https://go-review.googlesource.com/c/go/+/847028 Auto-Submit: Gopher Robot <gobot@golang.org> TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
… (avoid mkdir escape)
Avoid an escape from the root on Windows when the target of Root.Mkdir
or Root.MkdirAll is a dangling junction. This would incorrectly create
a new directory at the target of the junction, even when this is a
location outside of the root.
Also fix a more minor issue where various operations on a junction
would fail when the target name ended in a trailing slash. For example,
Root.Lstat("target/") would return ENOTDIR when "target" is a junction,
instead of following the junction or returning a path-escapes error.
Thanks to Daniele Ballarini for reporting this issue.
Fixes CVE-2026-56857
For golang#81739
Fixes golang#81898
Change-Id: If92a6b425ff33af6fb05c94b0d3d98e26a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5580
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6200
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/847029
Auto-Submit: Gopher Robot <gobot@golang.org>
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
…sed in ServeContent Set a limit on the number of ranges in a Range header, avoiding excessive allocations/CPU when parsing a header containing a large number of small ranges. The limit is controlled by GODEBUG=httpservecontentmaxranges. The default is 200 (same as Apache). GODEBUG=httpservecontentmaxranges=0 disables the limit. Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue. Fixes CVE-2026-78667 For golang#81858 Fixes golang#81920 Change-Id: Id7df8059e2a406e3a401bb5cb767b4d16a6a6964 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5560 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6220 Reviewed-on: https://go-review.googlesource.com/c/go/+/847030 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Gopher Robot <gobot@golang.org>
… on initial window changes
Defend against a malicious peer sending many adjustments to the initial
flow control window.
The flow control window for a stream is:
initial_window + sum(window_updates) - sum(bytes_sent)
The initial window starts at 64k, but may be adjusted at any time
by a SETTINGS frame.
A decrease in the initial window might cause a stream's current
window to become negative, which is fine. (This happens when a
stream has already consumed some portion of its existing window.)
An increase in the initial window MUST NOT cause the window of
any stream to exceed the maximum of (2^31-1). RFC 9113 requires
us to check for this:
An endpoint MUST treat a change to SETTINGS_INITIAL_WINDOW_SIZE
that causes any flow-control window to exceed the maximum size as
a connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR.
We enforced this by iterating over every active stream to adjust its
window and verify that the new window is not too large. While iterating
over streams is O(N), a malicious peer could send many small SETTINGS frames
and cause a large amount of CPU consumption when the number of open
streams is high.
The new implementation enforces the window less strictly, but performs
O(1) work in response to a change in the initial window.
Individual streams now maintain a delta from the initial window:
delta = sum(window_updates) - sum(bytes_sent)
The current stream window is computed on-demand by adding the
current initial window to the delta.
Overflow is detected lazily, when trying to write data for a stream
or when processing a WINDOW_UPDATE. This is technically speaking
a violation of RFC 9113's requirements, but it's a harmless one
and ensures we never do excessive work in reaction to a change
in the initial window.
Alternatives considered:
- Maintain a heap of streams, sorted by current window size.
Too complicated. Too much overhead. The juice is not worth the squeeze.
- Maintain a high-water mark for the stream delta, and only do an O(N)
iteration over all streams when the high-water mark indicates that
overflow might have happened. Avoids expensive processing in most
cases, but is vulnerable to a peer sending a rapid sequence of:
create stream
update stream window (updating the high-water mark)
reset stream
increase initial window to cause iteration (no violation)
decrease initial window
This scenario is more work than just a sequence of changes to the
initial window, and there are possibly ways to defend against it,
but lazy overflow detection is simpler and extremely robust.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
Fixes CVE-2026-78669
Fixes golang#81904
For golang#81742
Change-Id: I5667b01f81427141a0d873e2ec47052a6a6a6964
Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5921
Reviewed-by: Nicholas Husin <husin@google.com>
Reviewed-by: Neal Patel <nealpatel@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/847031
TryBot-Bypass: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
…tream close with buffered data Fix the following bug: - client opens a stream and sends data - client resets the stream, and server refunds flow control - handler reads the sent data, and server refunds flow control again This double-refund allows a malicious client to exceed the server's flow control limits, potentially causing the server to buffer much more data than those limits should allow. Thanks to Ali Sherif (https://www.linkedin.com/in/ali-sherif-13812b276/) for reporting this issue. Fixes CVE-2026-78663 Fixes golang#81906 For golang#81743 Change-Id: I86159053f7ce509d1ee93de55697f7ef6a6a6964 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/6020 Reviewed-by: Nicholas Husin <husin@google.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/847032 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Gopher Robot <gobot@golang.org>
… HPACK encoder race Our HTTP/2 server could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGS_HEADER_TABLE_SIZE that a client sends. As a result, a malicious client can repeatedly send a request while changing the header table size to crash the server. Fix this issue by not applying SETTINGS_HEADER_TABLE_SIZE immediately. Instead, buffer any SETTINGS_HEADER_TABLE_SIZE received, and only apply the new value prior to the next time the server writes a frame. Thank you to RyotaK (https://ryotak.net) of GMO Flatt Security Inc. for reporting this issue. Fixes CVE-2026-97032 For golang#81867 Fixes golang#81922 Change-Id: Ife977865a8bb190ae2cf6f462979ae406a6a6964 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5940 Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/847033 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Bypass: Gopher Robot <gobot@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
…ers too When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes is calculated differently. Fix this by applying MaxHeaderValueCount to the trailer fields declared in the "Trailer" header in both HTTP/1 and HTTP/2, and MaxHeaderBytes in HTTP/2. Thank you to RyotaK (https://ryotak.net) of GMO Flatt Security Inc. for reporting this issue. Fixes CVE-2026-78659 For golang#81857 Fixes golang#81918 Change-Id: I01f52e9873be80ac72d88f9e4d96f6096a6a6964 Reviewed-on: https://go-internal-review.googlesource.com/c/go/+/5980 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Neal Patel <nealpatel@google.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/847034 TryBot-Bypass: Gopher Robot <gobot@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: Ic0b65cb1b99dfa414ec1c8b11360114db21b7530 Reviewed-on: https://go-review.googlesource.com/c/go/+/846986 Auto-Submit: Gopher Robot <gobot@golang.org> TryBot-Bypass: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
tomhjp
approved these changes
Oct 9, 2026
dsnet
approved these changes
Oct 9, 2026
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
Update to Go 1.27.2
yieldas regexp preceder keyword