Repository navigation
Cockroach go1.27.2 - #19
Closed
yuvraj-crl wants to merge 2765 commits into
Closed
yuvraj-crl wants to merge 2765 commits into
yuvraj-crl wants to merge 2765 commits into
Conversation
Fixes golang#74451 Change-Id: I61e6339199c32ee160a8a4b55ddd668b6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/778621 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
While functions are not valid map keys, we can still infer the intended type arguments. Avoid reporting a follow-on "cannot use generic function without instantiation" error. This will be more relevant when implementing golang#12854, since we will want to have such type inference work for untyped composite literals used as keys to maps. For golang#12854 Fixes golang#80042 Change-Id: I703247d0eaf58410b04ccd7e3b2f4389faac8788 Reviewed-on: https://go-review.googlesource.com/c/go/+/791946 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Robert Griesemer <gri@google.com>
Fix "nor" to "not" in genericExprList comment in src/cmd/compile/internal/types2/call.go. Change-Id: Ibf4f363e3191a8196c08bfdaa500f0d5ef6a4285 GitHub-Last-Rev: 5f11da9 GitHub-Pull-Request: golang#77668 Reviewed-on: https://go-review.googlesource.com/c/go/+/746500 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
Since last time the default.pgo profile is collected, there has
been a lot of development in the compiler. It's time to refresh
the compiler's PGO profile.
Profile collected by running the cmd/compile/profile.sh script on
the gotip-linux-amd64_c2s16-perf_vs_release gomote.
There is a slight improvement on benchmark results. On Linux/AMD64,
│ nopgo.txt │ old.txt │ new.txt │
│ sec/op │ sec/op vs base │ sec/op vs base │
Template 142.5m ± 1% 140.8m ± 1% -1.23% (p=0.017 n=20) 141.3m ± 1% -0.87% (p=0.011 n=20)
Unicode 122.7m ± 1% 116.6m ± 1% -4.95% (p=0.000 n=20) 114.9m ± 1% -6.28% (p=0.000 n=20)
GoTypes 889.1m ± 0% 872.3m ± 1% -1.89% (p=0.000 n=20) 864.9m ± 1% -2.73% (p=0.000 n=20)
Compiler 161.0m ± 1% 151.9m ± 1% -5.65% (p=0.000 n=20) 151.5m ± 1% -5.90% (p=0.000 n=20)
SSA 8.626 ± 0% 8.337 ± 0% -3.34% (p=0.000 n=20) 8.294 ± 0% -3.85% (p=0.000 n=20)
Flate 148.1m ± 2% 145.3m ± 1% -1.91% (p=0.005 n=20) 145.8m ± 2% -1.56% (p=0.026 n=20)
GoParser 160.7m ± 2% 160.0m ± 1% ~ (p=0.174 n=20) 158.7m ± 1% -1.23% (p=0.001 n=20)
Reflect 389.9m ± 1% 383.9m ± 1% -1.55% (p=0.000 n=20) 382.2m ± 1% -1.97% (p=0.000 n=20)
Tar 159.6m ± 1% 157.2m ± 1% -1.48% (p=0.000 n=20) 157.7m ± 1% -1.18% (p=0.015 n=20)
XML 186.2m ± 2% 183.4m ± 2% ~ (p=0.056 n=20) 182.4m ± 1% -2.03% (p=0.001 n=20)
geomean 300.2m 293.0m -2.41% 291.9m -2.78%
For golang#60234.
Change-Id: I4101115f9c8005c3180db7a1600c0bc81bef7d5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/792120
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>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
When writing an HTTP/1 request or response, trailer names were copied verbatim onto the "Trailer:" declaration line by writeHeader. The only prior filtering was a switch rejecting the three reserved keys, and CanonicalHeaderKey returns a key containing invalid bytes unchanged, so a trailer name such as "X-Trailer\r\nInjected: 1" was written to the wire as written, permitting header injection on the Trailer line. Validate trailer names and values in newTransferWriter, which is the shared HTTP/1 serialization path for Request.Write and Response.Write, before any trailer is written. Names that fail httpguts.ValidHeaderFieldName and values that fail httpguts.ValidHeaderFieldValue now cause the write to return an error. This path is distinct from Transport.roundTrip, which already validates req.Trailer for client requests, and from the HTTP/2 and server ResponseWriter trailer paths, which validate separately. The gap closed here is the direct Request.Write / Response.Write serialization used by callers such as httputil and code that writes a request to a connection directly. Rejecting invalid trailer values is stricter than the previous behavior, in which the final trailer block sanitized CR and LF to spaces via Header.writeSubset rather than erroring. Values whose final value is set while the request body is read are still written through that sanitizing path; the new check covers values present when the write begins. Fixes golang#78775 Change-Id: I3ed66185ab262a215d0c8bbba005fd8b3df69acb GitHub-Last-Rev: 9337c9d GitHub-Pull-Request: golang#79971 Reviewed-on: https://go-review.googlesource.com/c/go/+/789960 Reviewed-by: Nicholas Husin <husin@google.com> Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Sayer Turner <sayerturner65@gmail.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Nicholas Husin <nsh@golang.org> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
…ch.go1.27 Merge List: + 2026-06-18 cabdf7f net/http: validate trailers when writing requests and responses + 2026-06-18 ac2b8fc cmd/compile: update default PGO profile + 2026-06-18 15929d1 cmd/compile: fix typo in comment + 2026-06-17 96bc97f go/types, types2: permit function type argument inference for map keys + 2026-06-17 8931a19 cmd/go: link and clarify docs for GOCACHEPROG + 2026-06-17 c83d55f simd: add doc.go + 2026-06-17 cc1ee09 cmd/compile: rename types with dependent methods instead of renaming methods + 2026-06-17 f22ebe8 simd: repair doc comment for Store, StorePart Change-Id: Ia237abee6a1de7911fcfa10571397959eaa19f42
It is possible for a Float.Text result to not match the strconv.FormatFloat result for corresponding arguments if the float32/64 argument is denormalized. Comment change only. For golang#71245. Change-Id: I153d4074388d4a5c87d3bf0b202a8ca77d13ffb1 Reviewed-on: https://go-review.googlesource.com/c/go/+/792040 Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com> 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>
added a complete test of the bug that was fixed. Change-Id: I733e928c78d3ffa3236d569e0634f928b97d4586 Reviewed-on: https://go-review.googlesource.com/c/go/+/792101 Auto-Submit: 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: Cherry Mui <cherryyz@google.com> Reviewed-by: Junyang Shao <shaojunyang@google.com>
The TestIFace, TestSizeof, TestCompileOk and TestCompileError tests run "go test" as a subprocess to build the testdata packages that import simd, which only builds with GOEXPERIMENT=simd. The subprocess is expected to inherit the experiment from the environment. However, on Plan 9, it is not inherited, so the simd package has no buildable files and the subprocess fails with "build constraints exclude all Go files in src/simd". This change sets GOEXPERIMENT explicitly in the subprocess environment, instead of relying on inheritance, as cmd/internal/testdir already does. Change-Id: I40ddc85296bb10320804804a53cef891b7901102 Reviewed-on: https://go-review.googlesource.com/c/go/+/792280 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I140d62e6b20672d5e0283f042338017997fe1c69 Reviewed-on: https://go-review.googlesource.com/c/go/+/792340 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Bypass: Gopher Robot <gobot@golang.org> Auto-Submit: Gopher Robot <gobot@golang.org>
…bnormal When fadd64/fsub64 cancel two near-equal, opposite-sign normal operands into a subnormal result, fpack64 is handed a mantissa far below 1<<mantbits64 while exp is still a normal-range exponent. fpack64 saved mant0/exp0/trunc0 before its normalization loop, so the denormal branch restored an un-normalized mantissa and right-shifted it to align to the subnormal exponent (the wrong direction here), returning the un-normalized cancellation mantissa at the wrong scale instead of the correctly rounded subnormal. Save mant0/exp0/trunc0 after the normalization loop so the denormal path restores a normalized mantissa and aligns correctly. This is a no-op for callers that already pass a normalized mantissa (fmul64, fdiv64, conversions). fpack32 is updated identically for parity, though its denormal branch is not reachable with an un-normalized mantissa through any current caller. This only manifests on softfloat targets (e.g. GOMIPS=softfloat), which is why it has gone unnoticed on hardware-float platforms. A randomized differential check against hardware found the previous code wrong on >50% of normal pairs that cancel into a subnormal; with this change those cases match hardware. Fixes golang#79964 Change-Id: I29f7ec79905ddb98af4f997a69b0a2f0574c3c9d GitHub-Last-Rev: 42a73cd GitHub-Pull-Request: golang#79965 Reviewed-on: https://go-review.googlesource.com/c/go/+/789861 Reviewed-by: Sayer Turner <sayerturner65@gmail.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
TestCtrlBreak relied on a fixed sleep to wait for a testing child program to be ready to receive the signal. This may cause flaky timeouts on slow machines. Instead, wait for the child to print a "ready" message like other signal tests, particularly runtime.TestLibraryCtrlHandler. Also fix a typo in the child program's file name to ensure it's easy to associate with the test. Fixes golang#80036 Change-Id: Ib3d8e6194538df95e76548771b401cf9b9de5674 Reviewed-on: https://go-review.googlesource.com/c/go/+/792020 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: Hongxiang Jiang <hxjiang@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The Go specification uses the term "rune literal" (not "character literal") for single-quoted literals like 'a'. The %q verb documentation in the fmt package uses the outdated term "character literal". This change updates it to use the correct Go terminology. As noted by @adonovan in golang#78486, %q works with rune and byte types but not general int types (which is enforced by go vet since Go 1.26). Fixes golang#78486 Change-Id: I894f339d6242331f8b02df3cf3d432df41e50772 GitHub-Last-Rev: 1f65e43 GitHub-Pull-Request: golang#78521 Reviewed-on: https://go-review.googlesource.com/c/go/+/762580 Reviewed-by: Rob Pike <r@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Reviewed-by: Alex Putman <aputman@golang.org> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Alan Donovan <adonovan@google.com>
The comment was correct when written but became obsolete when the mu field changed to a pointer to a Mutex. The code is clear in any case. Change-Id: Ibef2c2c4df07050e73e92bd14fabccdd3b48b0da Reviewed-on: https://go-review.googlesource.com/c/go/+/789400 LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Jonathan Amsterdam <jba@google.com> Auto-Submit: Ian Lance Taylor <iant@golang.org>
Conn.ConnectionState reports details that are only populated once the TLS handshake has completed. Callers that read it immediately after Accept (for example via tls.NewListener) instead observe an unpopulated ConnectionState whose HandshakeComplete field is false. Document this precondition on Conn.ConnectionState and point to ConnectionState.HandshakeComplete and Conn.Handshake, which the first Conn.Read or Conn.Write runs automatically. Fixes golang#79828. Change-Id: Iad8a446ae45c7eb45efba6f8c1ce50fa727db989 GitHub-Last-Rev: a9ea872 GitHub-Pull-Request: golang#80081 Reviewed-on: https://go-review.googlesource.com/c/go/+/792720 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> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Matches os.Symlink behavior. Windows accepts forward and backward slash as interchangeable in most contexts, but not in symlink targets. Fixes golang#80073 Change-Id: I62fdf301c7a2e713faaa5fbe4654d06e6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/793020 Reviewed-by: Quim Muntal <quimmuntal@gmail.com> 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>
During inlining of instantiations of imported generic functions, the compiler reads the generic function body which can trigger CanInlineFuncs on newly instantiated functions. Currently, on this code path CanInlineFuncs is called with a nil profile, even if PGO is enabled, which causes some inconsistency. In particular, with newinliner, CanInlineFuncs calls analyzeFuncProps, which calls inlheur.AnalyzeFunc, which calls revisitInlinability, which could set fn.Inl to nil if it determined it is not inlineable (without the profile) whereas the function is actually to be inlined (because of PGO). This causes compiler crash. Fix this by plumbing the profile through. Fixes golang#80064. Change-Id: Ifd6b93ba4cbfae1f65334e1338ef23ef8ead0b57 Reviewed-on: https://go-review.googlesource.com/c/go/+/793042 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This improves the documentation of: * Unmarshal regarding handling of non-addressable values. * GetOption regarding the return value when presence is false. * MarshalFunc regarding ownership of the returned []byte. * MatchCaseInsensitiveNames regarding how this might affect marshaling. Updates golang#79733 Change-Id: I885ddfa6f15a809ee94fb8983d4c77c71d6ae738 Reviewed-on: https://go-review.googlesource.com/c/go/+/792060 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
…f fields When MatchCaseInsensitiveNames is specified, an incoming JSON name may match multiple Go struct fields to prospectively unmarshal into. The v1 default behavior is to select the first field declared. This change makes it such that the v2 default is to report an error if multiple candidate fields exist. The ReportErrorsWithLegacySemantics options opts into v1 behavior. Updates golang#79733 Change-Id: Idcfca4fe0a21c7675c61ee836c51da1b1a719c7b Reviewed-on: https://go-review.googlesource.com/c/go/+/792780 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> Reviewed-by: Michael Pratt <mpratt@google.com>
Currently, when performing path sanitization and trailing-slash redirects, we do not populate the RawPath field of the returned URL. As a result, when a URL path is already escaped, our redirect behavior can be rather surprising: - When "/a//b%2fc" is sanitized, it is double-escaped, becoming "/a/b/%252fc". - When doing trailing slash-redirect, "/a%2fb" will lose its escaping, becoming "/a/b/" instead of "/a%2fb/". Fix this by populating the RawPath field. Also updated TestServeWithSlashRedirectForHostPatterns that still uses the old 301 status code rather than 307 after CL 720820. Fixes golang#79897 Change-Id: Ibdd1f119afdd6824e52185be3852234a6a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/792860 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> Reviewed-by: Nicholas Husin <husin@google.com>
FetchModule runs "go mod download -json" and unmarshals the result.
The JSON contract is on stdout, but the go command can also print
non-fatal diagnostics to stderr.
On Windows builders, a module cache write warning such as
go: writing go.mod cache: rename ... Access is denied.
can be printed while the command still succeeds and emits valid JSON.
Because FetchModule used CombinedOutput, that stderr text was mixed into
the JSON stream, causing json.Unmarshal to fail with "invalid character
'g' looking for beginning of value".
Capture stderr separately, parse only stdout, and include both streams
in failure messages. Log stderr on successful downloads so the warning
is still visible without corrupting the JSON output.
Fixes golang#79954.
Fixes golang#79956.
Cq-Include-Trybots: luci.golang.try:gotip-windows-amd64-longtest
Change-Id: I21032da33cb0009e0eaf557903880d0188c18f4b
Reviewed-on: https://go-review.googlesource.com/c/go/+/793260
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: Cherry Mui <cherryyz@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
Put tests that can run on all supported architectures (AMD64, ARM64, and Wasm) in common files. Only use architecture-specific files for architecture-specific operations. Change-Id: I7be5dd6afd1f3186fb3fff3dc2817024b67c6fa9 Reviewed-on: https://go-review.googlesource.com/c/go/+/792161 Reviewed-by: Junyang Shao <shaojunyang@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
During conversion checking, assignableTo probes pointer-to-interface targets to produce a helpful diagnostic. Because type parameters have interface underlying types, that probe also matches targets such as *P where P is a type parameter. Use interfacePtrError when Checker.implements formats this diagnostic so that pointer-to-type-parameter targets are reported accurately instead of as plain pointer-to-interface targets. Add a fixedbugs test for conversions to *P. Fixes golang#79883 Change-Id: Ie2c5860b6a13a782442716eac6276a97310f6ee3 Reviewed-on: https://go-review.googlesource.com/c/go/+/787900 Reviewed-by: Mark Freeman <markfreeman@google.com> Reviewed-by: Robert Griesemer <gri@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Mark Freeman <markfreeman@google.com>
Augment existing test coverage by adding a harness for C2SP/x509-limbo. This test suite is quite extensive, and it also subsumes the entirety of the Netflix BetterTLS suite, allowing us to delete that harness. x509-limbo publishes a JSON schema describing the test data. Similar to Wycheproof, to avoid by-hand maintenance of corresponding Go structs, while also avoiding a stdlib dependency on a generator, a separate Go module is provided for generating the Go representation of the schema. The resulting schema is vendored so it can be used without the generator. The upstream x509-limbo project has been running the test corpus against the Go standard library x509 package for some time (using Go 1.25.5). To get started we've allowed the unexpected verifications and unexpected failures based on the upstream results that predate running the suite ourselves. In some cases we will want to fix the behavior on our side and remove these allows, in other cases we have chosen to diverge from the upstream expectations and will leave the allow with a justifying comment. This will let us catch new regressions while also allowing landing the test without fixing these findings up-front. Change-Id: Ib0d3876da7daf864571b6b0924a36e46bf446d45 Reviewed-on: https://go-review.googlesource.com/c/go/+/728320 Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Filippo Valsorda <filippo@golang.org> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net> TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Neal Patel <nealpatel@google.com>
This commit updates the allowedUnexpectedVerifications and allowedUnexpectedFailures maps with justification/TODOs for the various test cases in x509-limbo where our produced behaviour doesn't match expected. In many cases these are deliberate choices, but in some others we may want to revisit the implementation in the future. Change-Id: I889de14a0f7e9c42dc3f4f9116ce9aa8a68e0e21 Reviewed-on: https://go-review.googlesource.com/c/go/+/783980 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Roland Shoemaker <roland@golang.org> TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net>
DWARF generation's createConservativeVar asserts that every variable marked ir.EscHeap has a non-nil Heapaddr. This assumption only holds for reachable declarations. Escape analysis runs before SSA generation and is not reachability-aware, so it can mark a variable declared in dead code as heap-escaped. During SSA generation the ODCL for such a variable lands in an unreachable block, where stmt() returns early and never calls newHeapaddr. The variable is therefore left with Esc()==EscHeap but Heapaddr==nil, a legitimate state: the allocation was never generated, so there is no heap address to point at. Only build the heap-deref location list when Heapaddr is present, and otherwise emit a conservative variable with no location list, as was done before CL 684377. A reachable heap-escaped variable always gets a Heapaddr via newHeapaddr, so a nil Heapaddr uniquely identifies the dead-code case. Fixes golang#80097. Change-Id: I91e475d0256c0f5e4d2dfabcacff92904469087a Reviewed-on: https://go-review.googlesource.com/c/go/+/792960 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: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
CL 736020 replaced calls to mapaccess1 with mapaccess2*. The main purpose is reducing the code duplication in runtime, since they are shared the same implementation. However, inside the compiler, OINDEXMAP is used in expression context. Thus it's not safe to replace the mapaccess1 by mapaccess2 calls late in the compiler frontend. Updates golang#73196 Fixes golang#80096 Change-Id: Ia510b947dc362168dacd55b0b57ad875f8a58bcf Reviewed-on: https://go-review.googlesource.com/c/go/+/793000 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> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@google.com>
ARM64's IfElse behavior is reversed from other platforms. Reverse it. Internally, its bitSelect is also the reverse of Wasm's BitSelect. Reverse the ARM64 one to match. Make Masked and IfElse tests portable. Change-Id: Icd2dbcb3383b2be642fd6fc7115ef1cbef0f9b78 Reviewed-on: https://go-review.googlesource.com/c/go/+/793361 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>
ShiftAll operations are supported on all platforms. Test them in portable files. Remove the redundant ShiftConst tests, as they are essentually the same as ShiftAll tests. Add more ShiftAll tests for AMD64. Change-Id: Ic1059341670019c31cc325641ede51b405e9636a Reviewed-on: https://go-review.googlesource.com/c/go/+/793364 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>
A missing synctest.Wait in TestConnPartialWrite seems to cause a test flake: in rare cases, the reader goroutine might call Close before the writer is able to write the final buffered byte. Fixes golang#79508 Change-Id: Ia57eddf94c1a826525657c8ec6f3e9f26a6a6964 Reviewed-on: https://go-review.googlesource.com/c/go/+/793440 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> Reviewed-by: Nicholas Husin <husin@google.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>
(cherry picked from commit bf17271)
Add a routine that returns the wall time spent by current goroutine in the running state. (cherry picked from commit 296a340) [go1.27.2 rebase, needs owner review] Upstream moved deductAssistCredit from malloc.go to malloc_stubs.go, and runtime/_mkmalloc now inlines it into malloc_generated.go. The gcnoassist check was ported into the stub and malloc_generated.go was regenerated with 'go run .' in runtime/_mkmalloc.
(cherry picked from commit fba0098)
This test requires the use of `SYS_getrandom`, which is not available to some of our cross-compilers. (cherry picked from commit 70a0c20)
Memmove/Memcpy routine of s390x architecture is optimized using better instructions
for particular sizes.
goos: linux
goarch: s390x
pkg: runtime
│ Orig_Memmove_for_benchstat.log │ New_backwards_and_forwards_Memmove_for_benchstat.log │
│ sec/op │ sec/op vs base │
Memmove/0 2.138n ± 4% 2.020n ± 0% -5.52% (p=0.000 n=10)
Memmove/1 2.076n ± 1% 2.079n ± 1% ~ (p=0.592 n=10)
Memmove/2 2.115n ± 3% 2.123n ± 1% ~ (p=0.325 n=10)
Memmove/3 2.414n ± 0% 2.401n ± 1% ~ (p=0.158 n=10)
Memmove/4 2.116n ± 0% 2.127n ± 18% +0.52% (p=0.000 n=10)
Memmove/5 2.419n ± 0% 2.414n ± 1% -0.21% (p=0.034 n=10)
Memmove/6 2.351n ± 1% 2.337n ± 1% ~ (p=0.137 n=10)
Memmove/7 2.833n ± 4% 2.764n ± 1% -2.42% (p=0.003 n=10)
Memmove/8 2.010n ± 0% 2.001n ± 1% ~ (p=0.100 n=10)
Memmove/9 2.380n ± 0% 2.388n ± 0% +0.34% (p=0.000 n=10)
Memmove/10 2.617n ± 1% 2.612n ± 1% ~ (p=0.564 n=10)
Memmove/11 2.827n ± 3% 2.792n ± 0% -1.24% (p=0.001 n=10)
Memmove/12 2.397n ± 0% 2.400n ± 1% ~ (p=0.781 n=10)
Memmove/13 2.705n ± 0% 2.704n ± 0% ~ (p=0.136 n=10)
Memmove/14 3.000n ± 0% 2.991n ± 1% -0.28% (p=0.035 n=10)
Memmove/15 3.118n ± 0% 3.142n ± 1% ~ (p=0.210 n=10)
Memmove/16 2.390n ± 0% 2.391n ± 0% ~ (p=0.611 n=10)
Memmove/32 5.128n ± 6% 4.287n ± 0% -16.41% (p=0.000 n=10)
Memmove/64 8.425n ± 3% 4.100n ± 0% -51.33% (p=0.000 n=10)
Memmove/128 5.197n ± 0% 4.857n ± 0% -6.53% (p=0.001 n=10)
Memmove/256 5.774n ± 0% 5.920n ± 2% +2.52% (p=0.000 n=10)
Memmove/512 10.79n ± 0% 10.70n ± 1% -0.88% (p=0.000 n=10)
Memmove/1024 19.86n ± 0% 19.79n ± 0% -0.30% (p=0.000 n=10)
Memmove/2048 36.38n ± 0% 35.94n ± 0% -1.20% (p=0.000 n=10)
Memmove/4096 72.12n ± 3% 69.65n ± 0% -3.42% (p=0.000 n=10)
MemmoveOverlap/32 4.481n ± 1% 4.430n ± 0% -1.13% (p=0.002 n=10)
MemmoveOverlap/64 5.932n ± 1% 5.886n ± 0% -0.78% (p=0.000 n=10)
MemmoveOverlap/128 7.950n ± 10% 6.591n ± 0% -17.10% (p=0.000 n=10)
MemmoveOverlap/256 11.24n ± 1% 10.20n ± 0% -9.25% (p=0.000 n=10)
MemmoveOverlap/512 18.49n ± 0% 16.80n ± 2% -9.11% (p=0.000 n=10)
MemmoveOverlap/1024 32.64n ± 0% 28.68n ± 0% -12.13% (p=0.000 n=10)
MemmoveOverlap/2048 62.79n ± 0% 56.34n ± 1% -10.28% (p=0.000 n=10)
MemmoveOverlap/4096 123.2n ± 0% 105.8n ± 0% -14.12% (p=0.000 n=10)
MemmoveUnalignedDst/0 2.571n ± 10% 2.225n ± 2% -13.46% (p=0.000 n=10)
MemmoveUnalignedDst/1 2.323n ± 0% 2.322n ± 0% -0.04% (p=0.000 n=10)
MemmoveUnalignedDst/2 2.370n ± 0% 2.373n ± 0% +0.13% (p=0.020 n=10)
MemmoveUnalignedDst/3 2.701n ± 0% 2.700n ± 0% -0.04% (p=0.006 n=10)
MemmoveUnalignedDst/4 2.350n ± 4% 2.318n ± 2% ~ (p=0.076 n=10)
MemmoveUnalignedDst/5 2.654n ± 6% 2.673n ± 3% ~ (p=0.738 n=10)
MemmoveUnalignedDst/6 2.764n ± 1% 2.744n ± 0% -0.71% (p=0.000 n=10)
MemmoveUnalignedDst/7 3.118n ± 5% 3.107n ± 7% ~ (p=0.971 n=10)
MemmoveUnalignedDst/8 2.399n ± 0% 2.399n ± 0% 0.00% (p=0.037 n=10)
MemmoveUnalignedDst/9 2.704n ± 0% 2.861n ± 4% +5.79% (p=0.000 n=10)
MemmoveUnalignedDst/10 2.972n ± 5% 2.976n ± 6% ~ (p=0.778 n=10)
MemmoveUnalignedDst/11 3.156n ± 4% 3.118n ± 0% -1.22% (p=0.001 n=10)
MemmoveUnalignedDst/12 2.704n ± 0% 2.703n ± 0% -0.04% (p=0.000 n=10)
MemmoveUnalignedDst/13 3.101n ± 0% 3.102n ± 0% ~ (p=0.690 n=10)
MemmoveUnalignedDst/14 3.188n ± 0% 3.186n ± 0% -0.05% (p=0.000 n=10)
MemmoveUnalignedDst/15 3.613n ± 3% 3.547n ± 2% ~ (p=0.085 n=10)
MemmoveUnalignedDst/16 2.772n ± 0% 2.771n ± 0% -0.04% (p=0.001 n=10)
MemmoveUnalignedDst/32 5.401n ± 10% 4.426n ± 0% -18.06% (p=0.000 n=10)
MemmoveUnalignedDst/64 9.037n ± 11% 4.381n ± 0% -51.51% (p=0.000 n=10)
MemmoveUnalignedDst/128 5.239n ± 0% 5.580n ± 0% +6.52% (p=0.000 n=10)
MemmoveUnalignedDst/256 6.563n ± 1% 6.372n ± 3% -2.90% (p=0.004 n=10)
MemmoveUnalignedDst/512 10.99n ± 1% 10.32n ± 4% -6.10% (p=0.000 n=10)
MemmoveUnalignedDst/1024 20.55n ± 2% 20.18n ± 0% ~ (p=0.125 n=10)
MemmoveUnalignedDst/2048 37.62n ± 1% 36.52n ± 0% -2.92% (p=0.000 n=10)
MemmoveUnalignedDst/4096 72.48n ± 1% 70.33n ± 0% -2.98% (p=0.000 n=10)
MemmoveUnalignedDstOverlap/32 5.032n ± 7% 4.823n ± 3% ~ (p=0.342 n=10)
MemmoveUnalignedDstOverlap/64 6.021n ± 11% 6.197n ± 7% ~ (p=0.085 n=10)
MemmoveUnalignedDstOverlap/128 7.979n ± 1% 6.742n ± 0% -15.51% (p=0.000 n=10)
MemmoveUnalignedDstOverlap/256 11.51n ± 1% 10.20n ± 0% -11.38% (p=0.000 n=10)
MemmoveUnalignedDstOverlap/512 19.72n ± 1% 16.50n ± 1% -16.38% (p=0.000 n=10)
MemmoveUnalignedDstOverlap/1024 34.94n ± 0% 28.73n ± 0% -17.76% (p=0.000 n=10)
MemmoveUnalignedDstOverlap/2048 64.63n ± 0% 57.02n ± 1% -11.77% (p=0.000 n=10)
MemmoveUnalignedDstOverlap/4096 124.8n ± 0% 106.6n ± 0% -14.62% (p=0.000 n=10)
MemmoveUnalignedSrc/0 2.571n ± 13% 2.235n ± 1% -13.05% (p=0.000 n=10)
MemmoveUnalignedSrc/1 2.375n ± 3% 2.374n ± 0% -0.04% (p=0.000 n=10)
MemmoveUnalignedSrc/2 2.389n ± 0% 2.389n ± 0% ~ (p=0.721 n=10)
MemmoveUnalignedSrc/3 2.704n ± 0% 2.703n ± 0% -0.04% (p=0.003 n=10)
MemmoveUnalignedSrc/4 2.345n ± 5% 2.325n ± 3% ~ (p=0.170 n=10)
MemmoveUnalignedSrc/5 2.716n ± 5% 2.654n ± 8% ~ (p=0.383 n=10)
MemmoveUnalignedSrc/6 2.772n ± 1% 2.759n ± 0% -0.49% (p=0.001 n=10)
MemmoveUnalignedSrc/7 3.123n ± 9% 3.127n ± 4% ~ (p=0.315 n=10)
MemmoveUnalignedSrc/8 2.407n ± 0% 2.406n ± 0% -0.04% (p=0.000 n=10)
MemmoveUnalignedSrc/9 2.705n ± 0% 2.724n ± 5% ~ (p=0.694 n=10)
MemmoveUnalignedSrc/10 2.978n ± 4% 2.933n ± 6% ~ (p=0.280 n=10)
MemmoveUnalignedSrc/11 3.166n ± 7% 3.130n ± 0% -1.14% (p=0.007 n=10)
MemmoveUnalignedSrc/12 2.704n ± 0% 2.704n ± 0% ~ (p=0.054 n=10)
MemmoveUnalignedSrc/13 3.132n ± 0% 3.141n ± 1% ~ (p=0.565 n=10)
MemmoveUnalignedSrc/14 3.224n ± 0% 3.224n ± 0% ~ (p=1.000 n=10)
MemmoveUnalignedSrc/15 3.589n ± 4% 3.547n ± 3% ~ (p=0.060 n=10)
MemmoveUnalignedSrc/16 2.762n ± 0% 2.754n ± 0% -0.29% (p=0.000 n=10)
MemmoveUnalignedSrc/32 5.402n ± 9% 4.603n ± 0% -14.79% (p=0.000 n=10)
MemmoveUnalignedSrc/64 8.548n ± 10% 4.604n ± 1% -46.13% (p=0.000 n=10)
MemmoveUnalignedSrc/128 5.204n ± 0% 5.381n ± 0% +3.41% (p=0.000 n=10)
MemmoveUnalignedSrc/256 6.221n ± 0% 6.231n ± 0% +0.14% (p=0.004 n=10)
MemmoveUnalignedSrc/512 11.18n ± 2% 10.17n ± 0% -9.03% (p=0.000 n=10)
MemmoveUnalignedSrc/1024 20.45n ± 1% 20.84n ± 3% +1.86% (p=0.016 n=10)
MemmoveUnalignedSrc/2048 37.54n ± 5% 36.46n ± 0% -2.88% (p=0.000 n=10)
MemmoveUnalignedSrc/4096 73.55n ± 5% 69.93n ± 0% -4.92% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_16_0 3.465n ± 0% 3.464n ± 0% -0.03% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_16_0 3.465n ± 0% 3.464n ± 0% -0.03% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_16_1 3.465n ± 0% 3.464n ± 0% -0.03% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_16_1 3.465n ± 0% 3.464n ± 0% -0.03% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_16_4 3.465n ± 0% 3.464n ± 0% -0.03% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_16_4 3.465n ± 0% 3.464n ± 0% -0.03% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_16_7 3.465n ± 0% 3.464n ± 0% -0.03% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_16_7 3.465n ± 0% 3.464n ± 0% -0.03% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_64_0 7.997n ± 6% 5.292n ± 0% -33.83% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_64_0 8.261n ± 10% 5.398n ± 0% -34.66% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_64_1 8.193n ± 6% 5.388n ± 0% -34.24% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_64_1 8.990n ± 12% 5.398n ± 0% -39.96% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_64_4 8.585n ± 3% 5.388n ± 0% -37.24% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_64_4 8.508n ± 2% 5.398n ± 0% -36.55% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_64_7 8.440n ± 5% 5.388n ± 0% -36.16% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_64_7 8.469n ± 5% 5.398n ± 0% -36.26% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_256_0 6.849n ± 0% 7.089n ± 0% +3.50% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_256_0 7.067n ± 0% 7.090n ± 1% ~ (p=0.748 n=10)
MemmoveUnalignedSrcDst/f_256_1 7.036n ± 0% 7.316n ± 0% +3.99% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_256_1 7.064n ± 0% 7.106n ± 1% ~ (p=0.096 n=10)
MemmoveUnalignedSrcDst/f_256_4 7.035n ± 0% 7.318n ± 0% +4.02% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_256_4 7.067n ± 0% 7.105n ± 1% ~ (p=0.389 n=10)
MemmoveUnalignedSrcDst/f_256_7 7.035n ± 0% 7.317n ± 0% +4.01% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_256_7 7.064n ± 0% 7.103n ± 1% +0.56% (p=0.011 n=10)
MemmoveUnalignedSrcDst/f_4096_0 72.34n ± 1% 69.97n ± 0% -3.27% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_4096_0 72.27n ± 1% 69.99n ± 0% -3.15% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_4096_1 73.70n ± 1% 72.84n ± 0% -1.16% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_4096_1 71.24n ± 2% 69.80n ± 0% -2.03% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_4096_4 73.90n ± 0% 72.85n ± 0% -1.42% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_4096_4 70.58n ± 0% 69.79n ± 0% -1.11% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_4096_7 73.71n ± 0% 72.82n ± 0% -1.20% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_4096_7 70.58n ± 0% 69.77n ± 0% -1.14% (p=0.000 n=10)
MemmoveUnalignedSrcDst/f_65536_0 1.204µ ± 0% 1.210µ ± 0% +0.50% (p=0.000 n=10)
MemmoveUnalignedSrcDst/b_65536_0 1.268µ ± 0% 1.275µ ± 0% +0.55% (p=0.001 n=10)
MemmoveUnalignedSrcDst/f_65536_1 1.253µ ± 3% 1.259µ ± 0% ~ (p=0.439 n=10)
MemmoveUnalignedSrcDst/b_65536_1 1.246µ ± 2% 1.256µ ± 0% +0.80% (p=0.021 n=10)
MemmoveUnalignedSrcDst/f_65536_4 1.254µ ± 1% 1.259µ ± 0% +0.40% (p=0.019 n=10)
MemmoveUnalignedSrcDst/b_65536_4 1.246µ ± 0% 1.256µ ± 0% +0.76% (p=0.001 n=10)
MemmoveUnalignedSrcDst/f_65536_7 1.253µ ± 1% 1.259µ ± 0% +0.48% (p=0.032 n=10)
MemmoveUnalignedSrcDst/b_65536_7 1.270µ ± 6% 1.256µ ± 0% ~ (p=0.614 n=10)
MemmoveUnalignedSrcOverlap/32 4.712n ± 5% 4.433n ± 1% -5.91% (p=0.001 n=10)
MemmoveUnalignedSrcOverlap/64 6.043n ± 3% 5.895n ± 0% -2.44% (p=0.000 n=10)
MemmoveUnalignedSrcOverlap/128 7.869n ± 5% 8.031n ± 1% ~ (p=0.256 n=10)
MemmoveUnalignedSrcOverlap/256 11.41n ± 1% 10.59n ± 0% -7.19% (p=0.000 n=10)
MemmoveUnalignedSrcOverlap/512 21.14n ± 1% 16.92n ± 0% -20.00% (p=0.000 n=10)
MemmoveUnalignedSrcOverlap/1024 39.55n ± 1% 29.91n ± 1% -24.36% (p=0.000 n=10)
MemmoveUnalignedSrcOverlap/2048 77.01n ± 0% 58.59n ± 0% -23.93% (p=0.000 n=10)
MemmoveUnalignedSrcOverlap/4096 152.0n ± 0% 112.6n ± 0% -25.95% (p=0.000 n=10)
MemmoveKnownSize112 2.310n ± 0% 2.309n ± 0% -0.04% (p=0.000 n=10)
MemmoveKnownSize128 2.502n ± 0% 2.502n ± 0% ~ (p=0.139 n=10)
MemmoveKnownSize192 3.850n ± 0% 3.849n ± 0% -0.03% (p=0.000 n=10)
MemmoveKnownSize248 4.042n ± 0% 4.041n ± 0% -0.04% (p=0.000 n=10)
MemmoveKnownSize256 4.042n ± 0% 4.041n ± 0% -0.02% (p=0.001 n=10)
MemmoveKnownSize512 8.116n ± 0% 8.114n ± 0% -0.02% (p=0.002 n=10)
MemmoveKnownSize1024 16.20n ± 0% 16.18n ± 0% -0.09% (p=0.001 n=10)
geomean 9.386n 8.773n -6.54%
Change-Id: I9476a27bc8aa935a977767bec6aafd6d721f9924
(cherry picked from commit e9e97ae)
Add a simple function that returns the index of the P the goroutine is running on. This will be used for efficient sharding of data structures. (cherry picked from commit 4a98392)
Change-Id: Idbe3438f5f06cae82dc5dcc56c52347d20e3e20a (cherry picked from commit 0701ca7)
This adds a new goroutine profile debug mode, debug=3.
This mode emits in the same binary proto output format as debug=0, with
the only difference being that it does not aggregate matching
stack/label combinations into a single count, and instead emits a sample
per goroutine with additional synthesized labels to communicate some of
the details of each goroutine, specifically:
- go::goroutine: the goroutine's ID
- go::goroutine_created_by: ID of the goroutine's creator (if any)
- go::goroutine_state: current state of the goroutine (e.g. runnable)
- go::goroutine_wait_minutes: approximate minutes goroutine has spent
waiting (if applicable)
Previously the debug=2 mode was the only way to get this kind of
per-goroutine information, that is sometimes vital to understanding the
state of a process. However debug=2 has two major drawbacks:
1) its collection incurs a lengthy and disruptive stop-the-world pause and
2) it does not include user-set labels along side per-goroutine details in the same profile.
This new debug=3 mode uses the same concurrent collection mechanism used
to produce debug=0 and debug=1 profiles, meaning it has the same minimial
stop-the-world penalty. At the same time, it includes the per-goroutine
details like status and wait time that make debug=2 so useful, providing
a "best-of-both-worlds" option.
A new mode is introduced, rather than changing the implementation of the
debug=2 format in-place, as it is not clear that debug=2 can utilize a
concurrent collection mechanism while maintaining the correctness of its
existing output, which includes argument values in its printed stacks.
The difference in STW latency observed by running goroutines during
profile collection is demonstrated by an included benchmark which spawns
a number of goroutines to be profiled and then measures the latency of a
short timer while collecting goroutine profiles.
BenchmarkGoroutineProfileLatencyImpact
│ debug=2 │ debug=3 │
│ max_latency_ns │ max_latency_ns vs base │
goroutines=100x3-14 422.2k ± 13% 190.3k ± 38% -54.93% (p=0.002 n=6)
goroutines=100x10-14 619.7k ± 10% 171.1k ± 43% -72.38% (p=0.002 n=6)
goroutines=100x50-14 1423.6k ± 7% 174.3k ± 44% -87.76% (p=0.002 n=6)
goroutines=1000x3-14 2424.8k ± 8% 298.6k ± 106% -87.68% (p=0.002 n=6)
goroutines=1000x10-14 7378.4k ± 2% 268.2k ± 146% -96.36% (p=0.002 n=6)
goroutines=1000x50-14 23372.5k ± 10% 330.1k ± 173% -98.59% (p=0.002 n=6)
goroutines=10000x3-14 42.802M ± 47% 1.991M ± 105% -95.35% (p=0.002 n=6)
goroutines=10000x10-14 36668.2k ± 95% 743.1k ± 72% -97.97% (p=0.002 n=6)
goroutines=10000x50-14 120639.1k ± 2% 188.2k ± 2582% -99.84% (p=0.002 n=6)
geomean 6.760M 326.2k -95.18%
The per-goroutine details are included in the profile as labels, along
side any user-set labels. While the pprof format allows for multi-valued
labels, so a collision with a user-set label would preserve both values,
it also discourages them, thus the 'go::' namespace prefix is used to
minimize collisions with user-set labels. The form 'go::' follows the
convention established in the pprof format, which reserves 'pprof::'.
(cherry picked from commit b2f6f9c)
This installs versioned crypto libraries in the appropriate place under the `GOROOT`. (cherry picked from commit 973a74e)
Given the frequency with which we expect callers to call Yield, it is not feasible to expect them to record the current time before every call just to detect how much time elapsed, if any, in the call, when most calls are expected to be near-instantanious no-ops. Instead, if we want to track how much time is spent in Yield, we need Yield itself to measure this when and only when it internally takes the slow, non-noop path and return it to its caller, so that these (relatively) more expensive clock reads can be restricted to and only to its rare slow paths where it actually does yield. (cherry picked from commit 213ea89)
Change debug.gcnoassist from int32 to atomic.Int32 so it can be safely read on the allocation fast path while being updated concurrently. Update the dbgvars registration from value: to atomic: so GODEBUG changes via os.Setenv also take effect dynamically. Add runtime.SetGCAssistEnabled for programmatic toggling at runtime without a process restart, and runtime.GCAssistEnabled as a getter. Add end-to-end tests exercising both the dynamic toggle and the GODEBUG=gcnoassist=1 startup path. Co-Authored-By: roachdev-claude <roachdev-claude-bot@cockroachlabs.com> (cherry picked from commit ff2b716) [go1.27.2 rebase, needs owner review] deductAssistCredit now lives in malloc_stubs.go (see the grunningnanos commit); the atomic Load was applied there and malloc_generated.go was regenerated with 'go run .' in runtime/_mkmalloc.
The debug=3 protobuf profile unconditionally emits go::goroutine_created_by from parentGoid, while debug=2 text output only prints "created by" when the creating function passes showframe. Allow debug=3 to be a superset of debug=2's created_by data instead of requiring an exact match. Fixes cockroachdb/cockroach#165528. (cherry picked from commit fd7fb9c)
Run the full dist test suite on pushes and PRs to master and cockroach-* branches. Skip only: - :race/:race-external (need dist test -race) - testfortran (needs gfortran) - relnote:check (needs doc/next/ fragments, absent on release branches) Includes workflow_dispatch trigger for manual testing. Co-Authored-By: roachdev-claude <roachdev-claude-bot@cockroachlabs.com> (cherry picked from commit e18c1f3)
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.
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
Please ensure you adhere to every item in this list.
More info can be found at https://github.com/golang/go/wiki/CommitMessage
net/http: frob the quux before blarfing"This change modifies Go to ___________"
really needed (ASCII art, table, or long link)
Fixes #1234orUpdates #1234(the latter if this is not a complete fix) to this comment
golang/goyou can use theowner/repo#issue_numbersyntax:Fixes golang/tools#1234Our Gerrit server & GitHub bots enforce CLA compliance instead.