aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-20internal/testenv: exclude GOMAXPROCS when building test programfix-runtime-test-GOMAXPROCSShulhan
In the environment where GOMAXPROCS set explicitly, for example to 3 in shell profile, the runtime tests will fail with the following error, ---- ok regexp/syntax 0.428s --- FAIL: TestCgroupGOMAXPROCS (0.81s) crash_test.go:186: running /home/ms/src/go/bin/go build -o /tmp/go-build1753772192/testprog.exe crash_test.go:208: built testprog in 796.664277ms --- FAIL: TestCgroupGOMAXPROCS/containermaxprocs=0 (0.00s) cgroup_linux_test.go:60: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (907.06µs): ok cgroup_linux_test.go:63: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSNoLimit (0.00s) cgroup_linux_test.go:82: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (879.194µs): ok cgroup_linux_test.go:85: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSHigherThanNumCPU (0.00s) cgroup_linux_test.go:102: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.396µs): ok cgroup_linux_test.go:105: output got "3\n" want "4\n" --- FAIL: TestCgroupGOMAXPROCSRound (0.01s) --- FAIL: TestCgroupGOMAXPROCSRound/50000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (852.099µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/100000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (894.001µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSRound/150000 (0.00s) cgroup_linux_test.go:156: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (850.897µs): ok cgroup_linux_test.go:159: output got "3\n" want "2\n" --- FAIL: TestCgroupGOMAXPROCSSchedAffinity (0.00s) cgroup_linux_test.go:229: /tmp/go-build1753772192/testprog.exe PrintGOMAXPROCS (867.987µs): ok cgroup_linux_test.go:232: output got "3\n" want "2\n" FAIL FAIL runtime 23.088s ---- This changes exclude the GOMAXPROCS when building program for testing so it does not affect the tests. Change-Id: I590d9eca57026539413cf4c93b37f624f179d534
2025-07-19cmd/internal/obj: enable got pcrel itype in fips140 for riscv64Meng Zhuo
This CL enable R_RISCV_GOT_PCREL_ITYPE in fips140 Fixes #74662 Change-Id: Ic189c4e352517ae74034f207a5f944b610f2eb73 Reviewed-on: https://go-review.googlesource.com/c/go/+/688635 Reviewed-by: Mark Ryan <markdryan@rivosinc.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Julian Zhu <jz531210@gmail.com>
2025-07-19cmd/compile/internal/ssa: restrict architectures for TestDebugLines_74576thepudds
CL 687815 recently added TestDebugLines_74576. The pre-existing debug_lines_test.go file generally restricts the tested architectures and contains multiple warnings that the testing approach is useful but fragile, such as: "These files must all be short because this is super-fragile." Despite that, initially I wanted to see what happened on the different architectures on the trybots in case it might show something surprising, and I let TestDebugLines_74576 run on all architectures. That seemed to initially work, but the test is now failing on a linux/risc64 builder (#74669), so it is likely more prudent to be more conservative and restrict the platforms like many of the other pre-existing tests, which is what this CL now does. Fixes #74669 Change-Id: I9e5a7d3ee901f58253cf72e03c2239df338479e6 Reviewed-on: https://go-review.googlesource.com/c/go/+/688856 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: David Chase <drchase@google.com>
2025-07-18os: revert the use of AddCleanup to close files and rootsCarlos Amedee
This reverts commit fdaac84480b02e600660d0ca7c15339138807107. Updates #70907 Updates #74574 Updates #74642 Reason for revert: Issue #74574 Change-Id: I7b55b85736e4210d9b6f3fd7a24050ac7bdefef9 Reviewed-on: https://go-review.googlesource.com/c/go/+/688435 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-07-18go/types: infer correct type for y in append(bytes, y...)Alan Donovan
The type-checking logic for append has a special case for append(bytes, s...) where the typeset for s contains string. However, this case was triggering even when the typeset contained only []byte, causing the creation of Signature types of the form func([]byte, Y) []byte, with the variadic flag set, where Y is the type of Y (e.g. a type parameter constrained to ~[]byte). This is an illegal combination: a variadic signature's last parameter must be a slice, or its typeset must contain string. This caused x/tools/go/ssa to crash. This CL narrows the special case to only typesets that contain string, and adds a test for the inferred signature. (There's little point in testing that a subsequent NewSignatureType call would succeed, because the inferred type plainly has no free type parameters.) Fixes #73871 Change-Id: Id7641104133371dd6b0077f281cdaa9db84cc1c7 Reviewed-on: https://go-review.googlesource.com/c/go/+/688815 Reviewed-by: Mark Freeman <mark@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-17cmd/compile/internal/escape: improve DWARF .debug_line numbering for literal ↵thepudds
rewriting optimizations The literal rewriting optimizations to reduce user allocations that were implemented in CL 649079 and related CLs like CL 684116 could produce .debug_line tables such that the line numbers sometimes jumped back to a variable's declaration. This CL adjusts the positions of the IR nodes to avoid this. For the first test added here in i74576a.go: 11 func main() { 12 a := 1 13 runtime.Breakpoint() 14 sink = a 15 } Without this fix, the test reports debug lines of 12, 13, 13, 12, 14. Note it goes backwards from 13 to a second 12. With this fix, the test reports debug lines of 12, 13, 13, 14 without going backwards. The test added in i74576b.go creates a slice via make with a non-constant argument, which similarly shows debug lines going backwards before this fix but not after. To address the slice make case, we create a new BasicLit node to then set its position. There were some related allocation optimizations for struct literals such as CL 649555 during the Go 1.25 dev cycle, but at least in some basic test cases, those optimizations did not seem to produce debug line issues. The struct literal interface conversion test added in i74576c.go has the same behavior before and after this change. Finally, running 'go test ./...' in the delve repo root (4a2a6e1aeb) seems to have many failures with go1.25rc2, but seems to pass with this CL. Fixes #74576 Updates #71359 Change-Id: I31faf5fe4bb352fdcd06bdc8606dbdbc4bbd65f0 Reviewed-on: https://go-review.googlesource.com/c/go/+/687815 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com> Reviewed-by: Keith Randall <khr@google.com>
2025-07-16runtime: fix idle time double-counting bugMichael Anthony Knyszek
This change fixes a bug in the accounting of sched.idleTime. In just the case where the GC CPU limiter needs up-to-date data, sched.idleTime is incremented in both the P-idle-time and idle-mark-work paths, but it should only be incremented in the former case. Fixes #74627. Change-Id: If41b03da102d47d25bec48ff750a9da27019b71d Reviewed-on: https://go-review.googlesource.com/c/go/+/687998 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-07-16cmd/compile/internal/escape: speed up analyzing some functions with many ↵thepudds
closures Escape analysis examines functions in batches. In some cases, closures are in the same batch as their parent function, but in other cases, the closures are in different batches. This can mean the per-batch ir.ReassignOracle cache is not as effective. For example, #74615 has 4,000 closures in a single function that are all in different batches. For that example, these caches had an ~80% hit rate. This CL makes the ir.ReassignOracle cache more broadly scoped, instead of per batch. This speeds up escape analysis when a function has many closures that end up in different batches, including this resolves #74615. For that example, this cache now has a ~100% hit rate. In addition, in (*batch).rewriteWithLiterals, we also slightly delay checking the ir.ReassignOracle cache, which is more natural to do now compared to when rewriteWithLiterals was first merged. This means we can avoid consulting or populating the cache in more cases. (We also leave a new type-related TODO there. If we were to also implement that TODO, a quick test suggests we could independently resolve the specific example in #74615 even without making the cache more broadly scoped, though other conceivable examples would not be helped; the scoping of the cache is the more fundamental improvement.) If we look at cumulative time spent via pprof for the #74615 example using this CL, the work of ir.ReassignOracle escape analysis cache now typically shows zero cpu samples. This CL passes "go build -toolexec 'toolstash -cmp' -a std cmd". Fixes #74615 Change-Id: I3c17c527fbb546ffb8a4fa52cd61e41ff3cdb869 Reviewed-on: https://go-review.googlesource.com/c/go/+/688075 Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-16cmd/link, runtime: on Wasm, put only function index in method table and func ↵Cherry Mui
table In the type descriptor's method table, it contains relative PCs of the methods (relative to the start of the text section) stored as 32-bit offsets. On Wasm, a PC is PC_F<<16 + PC_B, where PC_F is the function index, and PC_B is the block index. When there are more than 65536 functions, the PC will not fit into 32-bit (and relative to the section start doesn't help). Since there are no more bits for the function index, and the method table always targets the entry of a method, we put just the PC_F there, and rewrite back to a full PC at run time when we need the PC. This way we can have more than 65536 functions. The func table also contains 32-bit relative PCs, and it also always points to function entries. Do the same there, as well as other places where we use relative text offsets. Also add the relocation type in the relocation overflow error message. Also add check for function too big on Wasm. If a function has more than 65536 blocks, PC_B will overflow and PC = PC_F<<16 + PC_B will points to the wrong function. Fixes #64856. Change-Id: If9c307e9fb1641f367a5f19c39f88f455805d0bb Reviewed-on: https://go-review.googlesource.com/c/go/+/552835 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-16runtime: use 32-bit function index on WasmCherry Mui
Following CL 567896, this is one more place we used only 16 bits for the function index. Change it to load 32 bits. For #64856. Change-Id: I66a78c086e67165604053313751c097a70c50ba9 Reviewed-on: https://go-review.googlesource.com/c/go/+/609118 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-07-16cmd/internal/obj/wasm: use 64-bit instructions for indirect callsCherry Mui
Currently, on Wasm, an indirect call is compiled to // function index = PC>>16, PC is already on stack I32WrapI64 I32Const $16 ShrU // set PC_B to 0 ... // actual call CallIndirect Specifically, the function index is extracted from bits 16-31 of the "PC". When there are more than 65536 functions, this will overflow and wrap around, causing wrong function being called. This CL changes it to use 64-bit operations to extract the function index from the "PC", so there are enough bits to for it. For #64856. Change-Id: I83c11db4b78cf66250e88ac02a82bd13730a8914 Reviewed-on: https://go-review.googlesource.com/c/go/+/567896 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-07-15cmd/internal/doc: upgrade godoc pkgsite to 01b046eMichael Matloob
Increase the dependency on the doc tool to bring in the fixes to CL 687918 and CL 687976. Fixes golang/go#74459 Change-Id: I9cdefdfd9792a142ad14bae3d4f7bb9d8256a246 Reviewed-on: https://go-review.googlesource.com/c/go/+/687997 Reviewed-by: Jonathan Amsterdam <jba@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Matloob <matloob@google.com>
2025-07-15runtime: use memclrNoHeapPointers to clear inline mark bitsMichael Anthony Knyszek
Clearing the inline mark bits with memclrNoHeapPointers is slightly better than having the compiler insert, e.g. duffzero, since it can take advantage of wider SIMD instructions. duffzero is likely going away, but we know things the compiler doesn't, such as the fact that this memory is nicely aligned. In this particular case, memclrNoHeapPointers does a better job. For #73581. Change-Id: I3918096929acfe6efe6f469fb089ebe04b4acff5 Reviewed-on: https://go-review.googlesource.com/c/go/+/687938 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2025-07-15runtime: only clear inline mark bits on span alloc if necessaryMichael Anthony Knyszek
This change modifies initInlineMarkBits to only clear mark bits if the span wasn't just freshly allocated from the OS, where we know the bits are already zeroed. This probably doesn't make a huge difference most of the time, but it's an easy optimization and helps rule it out as a source of slowdown. For #73581. Change-Id: I78cd4d8968bb0bf6536c0a38ef9397475c39f0ad Reviewed-on: https://go-review.googlesource.com/c/go/+/687937 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-07-15runtime: have mergeInlineMarkBits also clear the inline mark bitsMichael Anthony Knyszek
This is conceptually simpler, as the sweeper doesn't have to worry about clearing them separately. It also doesn't have a use for them. This will also be useful to avoiding unnecessary zeroing in initInlineMarkBits at allocation time. Currently, because it's used in both span allocation and at sweep time, we cannot blindly trust needzero. This change also renames mergeInlineMarkBits to moveInlineMarkBits to make this change in semantics clearer from the name. For #73581. Change-Id: Ib154738a945633b7ff5b2ae27235baa310400139 Reviewed-on: https://go-review.googlesource.com/c/go/+/687936 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-07-15runtime: merge inline mark bits with gcmarkBits 8 bytes at a timeMichael Anthony Knyszek
Currently, with Green Tea GC, we need to copy (really bitwise-or) mark bits back into mspan.gcmarkBits, so that it can propagate to mspan.allocBits at sweep time. This function does actually seem to make sweeping small spans a good bit more expensive, though sweeping is still relatively cheap. There's some low-hanging fruit here though, in that the merge is performed one byte at a time, but this is pretty inefficient. We can almost as easily perform this merge one word at a time instead, which seems to make this operation about 33% faster. For #73581. Change-Id: I170d36e7a2193199c423dcd556cba048ebd698af Reviewed-on: https://go-review.googlesource.com/c/go/+/687935 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2025-07-15runtime/maps: fix typo in group.go comment (instrinsified -> intrinsified)dyma solovei
Several comments refer to bitset as 'instrinsified', which is likely a typo, because it refers to the output of the intrinsics implemented with SIMD. Change-Id: I00f26b8d8128592ee0e9dc8a1b1480c93a9542d6 GitHub-Last-Rev: 8a4236710979f2f969210e0b261bdb9ae44f3321 GitHub-Pull-Request: golang/go#74624 Reviewed-on: https://go-review.googlesource.com/c/go/+/688016 Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@google.com>
2025-07-15os: remove useless error checkguoguangwu
Change-Id: Ifeb5fecc6e28b79ac03e7dc2ce9531fe5eed3097 GitHub-Last-Rev: 087cf95965920c96befad5adb9e481bdf913d50a GitHub-Pull-Request: golang/go#66260 Reviewed-on: https://go-review.googlesource.com/c/go/+/570895 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Sean Liao <sean@liao.dev> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Florian Lehner <lehner.florian86@gmail.com> Reviewed-by: Rob Pike <r@golang.org>
2025-07-14runtime: expand GOMAXPROCS documentationMichael Pratt
Expand the GOMAXPROCS documentation to include details of how defaults are selected, as this is something that inquisitive minds will want to know. I've added an additional warning that these details may changed. While we are here, add a bit more structure to make it easier to find the relevant parts of the documentation. For #73193. Change-Id: I6a6a636cae93237e3e3174822490d51805e70990 Reviewed-on: https://go-review.googlesource.com/c/go/+/685318 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Sean Liao <sean@liao.dev> Reviewed-by: Sean Liao <sean@liao.dev> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-07-14encoding/json: decompose legacy optionsJoe Tsai
WARNING: This commit contains breaking changes for those already using GOEXPERIMENT=jsonv2. This decomposes FormatBytesWithLegacySemantics as: * FormatBytesWithLegacySemantics * FormatByteArrayAsArray * ParseBytesWithLooseRFC4648 This decomposes FormatTimeWithLegacySemantics as: * FormatDurationAsNano * ParseTimeWithLooseRFC3339 In particular, it splits out specific behaviors from the option that may need to be specified on a finer-grain level. FormatByteArrayAsArray and FormatDurationAsNano are targeted to just the default representation of a [N]byte or time.Duration type. Both of these are not necessary if the `format` tag is explicitly specified. However, we want to isolate their behavior from other behaviors that used to be part of FormatBytesWithLegacySemantics and FormatTimeWithLegacySemantics. ParseBytesWithLooseRFC4648 and ParseTimeWithLooseRFC3339 are targeted to just historically buggy parsing according to the relevant RFCs, which may need to be enabled by some services for backwards compatibility. While FormatTimeWithLegacySemantics is deleted, we still need FormatBytesWithLegacySemantics to configure highly esoteric aspects of how v1 used to handle byte slices. We rename OmitEmptyWithLegacyDefinition as OmitEmptyWithLegacySemantics to be consistent with other options with the WithLegacySemantics suffix. Updates #71497 Change-Id: Ic660515fb086fe3af237135f195736de99c2bd33 Reviewed-on: https://go-review.googlesource.com/c/go/+/685395 Auto-Submit: Joseph Tsai <joetsai@digital-static.net> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
2025-07-14encoding/json/v2: add security section to docJoe Tsai
This follows up CL 684315 with an expanded section in the v2 doc. Updates #14750 Updates #71845 Change-Id: I1ffa97e030f5f2b709e8142028e3c8e0e38b80ce Reviewed-on: https://go-review.googlesource.com/c/go/+/685195 Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-07-11runtime: gofmt after CL 643897 and CL 662455Tobias Klauser
Change-Id: I3103325ebe29509c00b129a317b5708aece575a0 Reviewed-on: https://go-review.googlesource.com/c/go/+/687715 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
2025-07-11encoding/json: remove legacy option to EscapeInvalidUTF8Joe Tsai
In the presence of invalid UTF-8, the AllowInvalidUTF8 option allows such bytes to be present, but silently mangles them using the Unicode replacement character. The v2 default is to emit the replacement character verbatim (which is valid UTF-8 and exactly what it is for). However, the v1 behavior has historically been to emit the escaped form of the replacement character. This behavior was introduced in https://go.dev/cl/11211045 where the documentation says that it is: replacing invalid bytes with the Unicode replacement rune U+FFFD but the implementation actually replaces it with the escaped form of the Unicode replacement rune. Given that the documentation differs from the implementation, the actual behavior is likely an oversight. Given how esoteric of behavior this is, we change the v1in2 behavior to avoid the unnecesary escaping and drop support for EscapeInvalidUTF8. This does not violate the Go compatibility agreement since we do not document what the exact syntactic output is. Also, there has already been prior precedence for changing the output: * [encoding/json: encode \b and \f as '\b' and '\f' in JSON strings](https://go.dev/cl/521675) * [encoding/json: encode \n in strings as "\n", not "\u000A"](https://go.dev/cl/4678046) * [encoding/json: encode \t as \t instead of \u0009](https://go.dev/cl/162340043) * [encoding/json: use standard ES6 formatting for numbers during marshal](https://go.dev/cl/30371) Fixes #74551 Change-Id: Ib59a873c44713d302f1f6ab103ffba2520d63276 Reviewed-on: https://go-review.googlesource.com/c/go/+/687116 Auto-Submit: Joseph Tsai <joetsai@digital-static.net> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-07-11encoding/json/v2: report wrapped io.ErrUnexpectedEOFJoe Tsai
In the event that the input is just JSON whitespace, the underlying jsontext.Decoder treats this as an empty stream and reports io.EOF. The logic in unmarshalFull simply casted io.EOF as io.ErrUnexpectedEOF, which is inconsistent with how all other io.ErrUnexpectedEOF are reported, which are wrapped within a jsontext.SyntacticError. Do the same thing for consistency. We add a v1 test (without goexperiment.jsonv2) to verify that the behavior is identical to how v1 has always behaved. We add a v1in2 test (with goexperiment.jsonv2) to verify that the v1in2 behavior correctly replicates historical v1 behavior. We also fix a faulty check in v1 Decoder.Decode, where it tried to detect errUnexpectedEnd and return an unwrapped io.ErrUnexpectedEOF error. This is the exact semantic that v1 has always done in streaming Decoder.Decode (but not non-streaming Unmarshal). There is a prior bug reported in #25956 about this inconsistency, but we aim to preserve historical v1 behavior to reduce the probability of churn when v1 is re-implemented in terms of v2. Fixes #74548 Change-Id: Ibca52c3699ff3c09141e081c85f853781a86ec8e Reviewed-on: https://go-review.googlesource.com/c/go/+/687115 Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com>
2025-07-11crypto/rsa: drop contradictory promise to keep PublicKey modulus secretFilippo Valsorda
We claim to treat N as secret (and indeed bigmod is constant time in relation to the modulus) but at the same time we warn that all inputs to VerifyPKCS1v15 and Verify are public: > The inputs are not considered confidential, and may leak through > timing side channels, or if an attacker has control of part of the > inputs. See #67043 (which focuses on the inverse, recovering signatures by controlling the public key input to Verify), and in particular https://github.com/golang/go/issues/67043#issuecomment-2079335804. Stopping the Verify adaptive attack would require significantly more complexity, the kind that has caused vulnerabilities in the past (e.g. CVE-2016-2107). On the other hand, assuming that a public key is confidential is unlikely to work in practice, since it can be recovered from just two valid (message, signature) pairs. See for example https://keymaterial.net/2024/06/15/reconstructing-public-keys-from-signatures/. This comment was introduced in CL 552935, not really due to a need to specify that N was secret, but rather to clarify that E is not (so it could be used in variable-time exponentiation). Change-Id: I6a6a6964f3f8d2dc2fcc13ce938b271c9de9666b Reviewed-on: https://go-review.googlesource.com/c/go/+/687616 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-07-11crypto/rsa: fix documentation formattingFilippo Valsorda
Change-Id: I6a6a696422f9ab73b9ddee131b17d3c177fefc4e Reviewed-on: https://go-review.googlesource.com/c/go/+/687615 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Roland Shoemaker <roland@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2025-07-11runtime: turn off large memmove tests under asan/msanKeith Randall
Just like we do for race mode. They are just too slow when running with the sanitizers. Fixes #59448 Change-Id: I86e3e3488ec5c4c29e410955e9dc4cbc99d39b84 Reviewed-on: https://go-review.googlesource.com/c/go/+/687535 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Keith Randall <khr@golang.org>
2025-07-11cmd/link: do size fixups after symbol references are loadedCherry Mui
When we do a size fixup, we need to clone the symbol to an external symbol so we can modify it. This includes cloning the relocations, which includes resolving the relocations. If the symbol being fixed has a relocation referencing a non-Go symbol, that symbol has not yet been created, it will be resolved to an empty symbol. Load the references first, so the referenced symbol, even if it is a non-Go symbol, exists. Fixes #74537. Change-Id: I81525bd7c3e232b80eefeb0f18e13ba5331e1510 Reviewed-on: https://go-review.googlesource.com/c/go/+/687315 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com>
2025-07-10os: trivial comment fixJakob Borg
"Geese" here looks like an autocorrect-o of "oses", I think writing it out makes more sense. Change-Id: Iba89a6c0b94657e2e93937cc153f07aea1d04e04 GitHub-Last-Rev: 4f3a780f327d6c807e9b154d781ee69a10d391e4 GitHub-Pull-Request: golang/go#74332 Reviewed-on: https://go-review.googlesource.com/c/go/+/682776 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2025-07-10synctest: fix comments for time.Now() in synctestsChristian Hoeppner
Also add a test case to make sure that time.Now() results in the documented date. Change-Id: Ic4cc577eba485b7c6e1a64122da06d7075bbe12e Reviewed-on: https://go-review.googlesource.com/c/go/+/685677 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Christian Höppner <hoeppi@google.com> Reviewed-by: Damien Neil <dneil@google.com>
2025-07-10crypto/cipher: Fix comment punctuationMarkus Kusano
Change-Id: I7dc086a87d28ab847288eed13f719421420cd004 Reviewed-on: https://go-review.googlesource.com/c/go/+/686997 Reviewed-by: Alan Donovan <adonovan@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-09runtime: run TestSignalDuringExec in its own process groupMichael Anthony Knyszek
TestSignalDuringExec sends a SIGWINCH to the whole process group. However, it may execute concurrently with other copies of the runtime tests, especially through `go tool dist`, and gdb version <12.1 has a bug in non-interactive mode where recieving a SIGWINCH causes a crash. This change modifies SignalDuringExec in the testprog to first fork itself into a new process group. To avoid issues with Ctrl+C and the new process group hanging, the new process blocks on a pipe that is passed down to it. This pipe is automatically closed when its parent exits, which should ensure that the subprocess also exits. Fixes #58932. Change-Id: I3906afa28cf8b15d22ae612d071bce7f30fc3e6c Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-noswissmap,gotip-linux-amd64-longtest-aliastypeparams,gotip-linux-amd64-longtest,gotip-linux-386-longtest Reviewed-on: https://go-review.googlesource.com/c/go/+/686875 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-07-09crypto/tls: empty server_name conf. ext. from serverDaniel McCarney
When a TLS server uses the information from the server_name extension in a client hello, and the connection isn't resuming, it should return an empty server_name extension in its server hello (or encrypted extensions for TLS 1.3). For TLS <1.3 we we do this in doFullHandshake(), by setting the pre-existing serverHelloMsg.serverNameAck bool. We know that the connection isn't resuming based on the context where this function is called. For TLS 1.3, a new encryptedExtensionsMsg.serverNameAck bool is added, and populated as appropriate in sendServerParameters() based on whether the conn was resumed or not. The encryptedExtensionsMsg marshalling is updated to emit the encrypted extension based on that field. These changes allow enabling the ServerNameExtensionServer-* bogo tests that verify both the presence and absence of the server_name extension based on the relevant specifications. Resolves #74282 Updates #72006 Change-Id: I703bc2ec916b50906bdece7b7483a7faed7aa8e4 Reviewed-on: https://go-review.googlesource.com/c/go/+/684795 TryBot-Bypass: Daniel McCarney <daniel@binaryparadox.net> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Daniel McCarney <daniel@binaryparadox.net>
2025-07-08cmd/go: disable support for multiple vcs in one moduleRoland Shoemaker
Removes the somewhat redundant vcs.FromDir, "allowNesting" argument, which was always enabled, and disallow multiple VCS metadata folders being present in a single directory. This makes VCS injection attacks much more difficult. Also adds a GODEBUG, allowmultiplevcs, which re-enables this behavior. Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting this issue. Fixes #74380 Fixes CVE-2025-4674 Change-Id: I5787d90cdca8deb3aca6f154efb627df1e7d2789 Reviewed-on: https://go-review.googlesource.com/c/go/+/686515 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: David Chase <drchase@google.com> Commit-Queue: Carlos Amedee <carlos@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-07-08internal: make struct comment match struct namecuishuang
Change-Id: I85a4051bd3413bd843b17d22cf9120f615cfe8db Reviewed-on: https://go-review.googlesource.com/c/go/+/686295 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Carlos Amedee <carlos@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-07-08cmd/compile: document that nosplit directive is unsafeIan Lance Taylor
For #74478 Change-Id: I902e9a92cdacb5ad6dafa9896640f8196ba1d56a Reviewed-on: https://go-review.googlesource.com/c/go/+/686115 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2025-07-08cmd/compile: run fmt on ssaJorropo
prove.go used to make my editor and precomit checks very unhappy. Change-Id: I25f7ffa2191480bc1b4f91fa91ccf3e4768045fa Reviewed-on: https://go-review.googlesource.com/c/go/+/685818 Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Auto-Submit: Keith Randall <khr@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-07internal/trace: only test for sync preemption if async preemption is offMichael Anthony Knyszek
Currently, the test change made for the fix to #68090 is flaky. This is because the sync-point-only goroutine that we expect to be sync preempted might only ever get async preempted in some circumstances. This change adds a variant to all trace tests to run with asyncpreemptoff=1, and the stacks test, the flaky one, only actually checks for the sync-point in the trace when async preemption is disabled. Fixes #74417. Change-Id: Ib6341bbc26921574b8f0fff6dd521ce83f85499c Reviewed-on: https://go-review.googlesource.com/c/go/+/686055 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2025-07-07cmd/internal/doc: fix GOROOT skew and path joining bugsMichael Matloob
Use the goCmd() function to get the go command to invoke, so that when GOROOT is set, the go command that's invoked uses the same GOROOT. Otherwise there will be skew between the go command and the tools and runtime. Also use the environment when determining GOPROXY and GOMODCACHE, and use url.Join so the slashes in 'http://' aren't collapsed into one. Change-Id: Ie36ca2fffdb015a7f5f9bd7f514850e41fad2c1a Reviewed-on: https://go-review.googlesource.com/c/go/+/685319 Reviewed-by: Michael Matloob <matloob@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-07runtime: make traceStack testable and add a benchmarkMichael Anthony Knyszek
Change-Id: Ide4daa5eee3fd4f3007d6ef23aa84b8916562c39 Reviewed-on: https://go-review.googlesource.com/c/go/+/684457 Reviewed-by: Cherry Mui <cherryyz@google.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-07crypto/rsa: remove another forgotten note to future selfFilippo Valsorda
In CL 226937 I refactored the RSA-PSS implementation, and apparently left behind a note to think a bit harder about whether this bytes.Equal check should be constant time or not. It snuck through code review, so it's 2018 again, no one is worried about pandemics, I have just joined Google, and I am mailing CL 147637 again. Anyway, as discussed in #67043 and documented in CL 587277, the inputs to signature verification functions are not secret, and are allowed to leak through timing side channels. This means an attacker can already compute h (from signature and public key) and h0 (from message hash and public key). What the attacker can't do is produce a signature that yields the correct h (since that requires the private key). Change-Id: I6a6a4656d6255bdad628a94f48f7ea878a304263 Reviewed-on: https://go-review.googlesource.com/c/go/+/685255 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net> Auto-Submit: Filippo Valsorda <filippo@golang.org>
2025-07-07cmd/compile/internal/ssa: skip EndSequence entries in TestStmtLinesqmuntal
The TestStmtLines test has been accessing a nil pointer when it tries to look up LineEntry.File.Name on a line entry with EndSequence set to true. The doc for EndSequence specifies that if EndSequence is set, only it and the Address field are meaningful. Skip the entries with EndSequence set when building the set of files. I've reproduced this issue locally. Probably also fixes #49372, but will leave that for a follow-up CL. Fixes #74475 Updates #49372 Change-Id: Ic0664f7652b52a0a20239d13fe16454622740821 Reviewed-on: https://go-review.googlesource.com/c/go/+/685835 Reviewed-by: Than McIntosh <thanm@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Quim Muntal <quimmuntal@gmail.com>
2025-07-07sort: clarify Less docJohn Giorshev
clarifies the requirements for Less Fixes https://github.com/golang/go/issues/73420 Change-Id: I7d49b10fad78c618d946b3bb161ce19680ede47a GitHub-Last-Rev: 7a49ad81923048bfc99b265dd89f012eefcf5699 GitHub-Pull-Request: golang/go#74333 Reviewed-on: https://go-review.googlesource.com/c/go/+/683275 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Auto-Submit: Keith Randall <khr@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-03runtime: correct vdsoSP on S390XCherry Mui
It should get the caller's SP. The current code gets the address of the first parameter, which is one word above the caller's SP. There is a slot for saving the LR at 0(SP) in the caller's frame. Fixes #62086 (for s390x). Change-Id: Ie8cbfabc8161b98658c884a32e0af72df189ea56 Reviewed-on: https://go-review.googlesource.com/c/go/+/685715 Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-03hash: document that Clone may only return ErrUnsupported or a nil errorFilippo Valsorda
Updates #69521 Change-Id: I6a6a6964ce384a80c4c89efe67c260dc6e9ed6c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/685235 Auto-Submit: Filippo Valsorda <filippo@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Austin Clements <austin@google.com>
2025-07-02cmd/cgo/internal/testsanitizers: skip asan tests when FIPS140 mode is onqmuntal
Executing "GODEBUG=fips140=on go test -run TestASAN ./cmd/cgo/internal/testsanitizers" fails because FIPS 140 mode is incompatible with ASAN. Change-Id: I1a489f3398bbabf597fe7ffc0982c86c3b86e07e Reviewed-on: https://go-review.googlesource.com/c/go/+/685495 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Quim Muntal <quimmuntal@gmail.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-07-02testing/synctest: explicitly state Run will be removed in Go 1.26Deleplace
Updates #74012 Change-Id: I0407d9e87e9de6e02d3de0a462bc6a32c0faba4c Reviewed-on: https://go-review.googlesource.com/c/go/+/684875 Reviewed-by: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: qiu laidongfeng2 <2645477756@qq.com>
2025-07-01cmd/go/internal/modindex: apply changes in CL 502615 to modindex packageMichael Matloob
CL 502615 modified go/build to check for invalid import paths, but did not make those changes to the corresponding code in the modindex package. Apply those changes here. We should try to deduplicate the code to prevent this from happening again. For #73976 For #74446 Change-Id: I69fc5e2c829efb818c9974ec8126807a1c8f7913 Reviewed-on: https://go-review.googlesource.com/c/go/+/685317 TryBot-Bypass: Michael Matloob <matloob@google.com> Auto-Submit: Michael Matloob <matloob@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Matloob <matloob@google.com>
2025-07-01crypto/tls: ensure the ECDSA curve matches the signature algorithmFilippo Valsorda
Change-Id: I6a6a4656c1b47ba6bd652d4da18922cb6b80a8ab Reviewed-on: https://go-review.googlesource.com/c/go/+/675836 Reviewed-by: Roland Shoemaker <roland@golang.org> Auto-Submit: Filippo Valsorda <filippo@golang.org> TryBot-Bypass: Filippo Valsorda <filippo@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
2025-07-01crypto/ecdsa: fix crypto/x509 godoc linksFilippo Valsorda
Change-Id: I6a6a6964c0e8269305804dc2bb57f13f94f08ed5 Reviewed-on: https://go-review.googlesource.com/c/go/+/685236 Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Filippo Valsorda <filippo@golang.org> Reviewed-by: Roland Shoemaker <roland@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Daniel McCarney <daniel@binaryparadox.net>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 00:15:14 +0000