Activity

Yesterday
@gopherbot Please consider this issue for backport. It appears to be a case of stack corruption during fault handling, and we're now seeing this failure on both 1.23 and 1.22 release branches (e.g., …
Thanks. This does fix test failures on 1.23 branch (see [here](https://ci.chromium.org/b/8730719768254959025)), but there are still other test failures with tip (see [here](https://ci.chromium.org/b…
Thanks.
dmitshur commented on crypto/x509: remove x509sha1 GODEBUG9h
(1 comment) I tried to look if we've done this before, and I didn't spot any instances, so this might be the first. Not sure, but it seems that it would make the page more readable to update it. In…
dmitshur closed an issue sync/atomic: TestNilDeref failures10h
It's happening on the Go 1.23 release branch now. Closing in favor of #70288 again. I relaxed the pattern there and removed this issue from Test Flakes project, so watchflakes sends its reports th…
CC @golang/openbsd.
Thanks for the report. Note that the net/http/cgi package comment includes "This package is intended primarily for compatibility with existing systems." but it sounds like this issue might affect exi…
Closed by merging [CL 630215](https://go.dev/cl/630215) (commit 6f05fa7a4f632fee7fadada8d31cf8755c709610) to release-branch.go1.22.
Closed by merging [CL 630196](https://go.dev/cl/630196) (commit 847cb6f9ca43da48cb10e98808a74a40b41242fa) to release-branch.go1.23.
Note that the x/vuln longtest builders started to fail with Go 1.23 and 1.22 seemingly as of this CL, see [here](https://ci.chromium.org/ui/p/golang/builders/ci/x_vuln-go1.23-linux-amd64-longtest/b87…
TestUint64Modulo in golang.org/x/exp/rand has started to [fail](https://ci.chromium.org/ui/p/golang/builders/ci/x_exp-gotip-linux-arm64/b8730733624381859905/test-results?q=ExactID%3Agolang.org%2Fx%2F…
The TestToStruct test in `google.golang.org/protobuf/types/known/structpb` package has started to fail at Go tip, as of [go.dev/cl/627716](https://go.dev/cl/627716) (CC @randall77): ``` === RUN …
Note that TestTypeAlias in golang.org/x/crypto/ed25519 [fails](https://ci.chromium.org/ui/p/golang/builders/ci/x_crypto-gotip-linux-amd64/b8730799065470690641/test-results?q=ExactID%3Agolang.org%2Fx%…
(1 comment) Yes, both [go1.22-windows-amd64-longtest](https://ci.chromium.org/ui/p/golang/builders/try/go1.22-windows-amd64-longtest/b8730729501094353009/overview) and [go1.22-windows-amd64-race](ht…
(1 comment) Oh I see you mentioned this in a Gerrit comment.
Thanks. Not a big deal, but it might help to mention that this includes CL 630136 too. Please either s/gotip/go1.22/g on this line (since this branch needs Go 1.22 builders) or remove it.
(1 comment) No need to change in this CL in particular as it's minor, but noting for future CLs: it's common to use a blank line to separate the git footers (Change-Id, etc.) from the commit message…
Thanks. Some comments/questions. I understand you've considered the possibility of keeping this on builders, and dropping this only when GO_BUILDER_NAME == "", but decided to apply this change to bu…
CC @golang/compiler.
CC @rsc, @ianlancetaylor, @griesemer.
This Week
Those longtest failures (on PS 1) look like #70429, #70430, #70431 due to the parent commit a65f1a46 being after CL 608335 and before CL 629475. It passed on the rebased PS 2.
dmitshur commented on crypto/x509: remove x509sha1 GODEBUG1d
(1 comment) Perhaps it could work well to update this, now that it's known what the future release where it's removed will be.
dmitshur fixed an issue time: TestLoadFixed failures1d
Should be fixed on release branches too, now. Closing optimistically.
dmitshur commented on runtime: deprecate SetFinalizer1d
(1 comment) FWIW, the documentation for this release note linking support is in doc/README.md, and this short form indeed should work as listed on [line 43](https://cs.opensource.google/go/go/+/mast…
dmitshur commented on runtime: deprecate SetFinalizer1d
Noting here that https://go.dev/wiki/Deprecated is the place where it is documented that: > If function F1 is being replaced by function F2 and the first release in which F2 is available is Go 1.N…
dmitshur commented on crypto/sha3: new package1d
(1 comment) The "Minor changes to the library" section is intended for minor changes to existing packages. A new package normally deserves its own standalone section under "Standard library". See ht…
Note that runtime:mayMoreStackMove.TestSynctest is [failing](https://ci.chromium.org/ui/p/golang/builders/ci/gotip-linux-amd64-longtest/b8730812608564042305/test-results?q=ExactID%3Aruntime%3AmayMore…
(1 comment) Given this is still here, will the p256.go file not be overwritten next time `go generate` is done?
Some of the GLFW functions are methods in the Go bindings. For example, `void glfwRequestWindowAttention(GLFWwindow * window)` is [Window.RequestAttention](https://pkg.go.dev/github.com/go-gl/glfw/v3…
This is documented at https://pkg.go.dev/cmd/test2json as: > The test should be invoked with -test.v=test2json. Using only -test.v (or -test.v=true) is permissible but produces lower fidelity resu…
Thanks. Perhaps: ```suggestion enabled = define_for_go_starting_at("go1.24", presubmit = False), ``` ```suggestion enabled = define_for_go_starting_at("go1.24", presubmit = False),…
(4 comments) FWIW, x/tools still contains astutil, it just stops being vendored because `go mod vendor` doesn't consider imports in this _gen directory due to the leading underscore. Also here. Go…
dmitshur reviewed +2 on doc/godebug: fix tipo2d
This is a continunuation of https://github.com/golang/go/issues/70402#issuecomment-2484442242, tracking the change on the LUCI side. CC @golang/release, @mknyszek.
Updated plan, which takes into account https://pkg.go.dev/cmd/go@master#hdr-Build__json_encoding and https://github.com/golang/go/issues/70402#issuecomment-2484043547, is to determine that a given JS…
(1 comment) Is it expected that https://go.dev/s/style#indent-error-flow doesn't apply to errors of type `syscall.Errno`, explaining why this isn't written as `if errno != 0 { return errno }; return…
Thanks. I sent CL 629375 to use this new GODEBUG setting in LUCI, so this can land before the result_adapter/ResultDB changes are done and propagated. Since this GODEBUG is intended to be available …
Two reasons: to buy more time to work on the result_adapter/ResultDB side (beyond just the bare minimum behavior of not regressing beyond what we had before), and to test that using a GODEBUG for thi…
(2 comments) Optionally, there's an existing higher-level helper in testenv package that can be used: ```suggestion if testenv.Builder() == "" { ``` This message seems to be inverted compared to …
Updating this with some details that I'm seeing so far. The `Test result for "" is invalid: test_id: unspecified` error happens because the system that stores individual test results requires each…
Thanks. No problem, thanks.
Note that internal/runtime/maps.TestMapPut [fails](https://ci.chromium.org/b/8730991533000725377) on the `GOEXPERIMENT=noswissmap` builder.
Fixed in [CL 628555](https://go.dev/cl/628555).
@murp@ibm.com What's the reason to close this? Is issue #66685 fixed via another means, or no longer relevant?
(7 comments) See inline comment about this. I think it's fine to do when the original URL clearly points to its new location, but we probably shouldn't do it when there are many potential alternativ…
Last Week
(1 comment) Good to see the [deployment](https://go.googlesource.com/website#deploying) with the [go122 runtime](https://cs.opensource.google/go/x/website/+/master:cmd/golangorg/app.yaml;l=5;drc=e78…
dmitshur closed an issue sync/atomic: TestNilDeref failures1w
There are no trybots defined for this repo; bypassing.
Thanks, and congrats!
Thanks. Consider adding 'For #58113.' here.
(1 comment) I expect a test should suggest using a relative link here and elsewhere, so it works in more contexts.
Earlier
Thanks. Nice to see SECOND_GO is handy. (nit) Consider adding a blank line after line 1862, otherwise the "# Bump the timeout ..." comment sounds as if it applies to the entire block, while really …
(1 comment) Done in I42a24c462acf7340410614fa3b0dd80608efcdaa. Rebased this CL on top.
(1 comment) Done in I0a31a56df624f6052249122c66153b91bb321a37. Rebased this CL on top.
Indeed. I left an inline comment about that. In a modern version of the go command, running go mod tidy ignores requirements that come from files with the "ignore" build constraint. This should prob…
(1 comment) In a modern version of the go command, running `go mod tidy` in a module without a go directive will cause it to be added using the go command's own version. Leaving out the go directiv…
Thanks. Asking to understand the difference: perf_vs_gopls_0_11 exists only for the 16 vCPU amd64 builder, not 88 one, but here it's being added for both. Is the asymmetry intended? (SG if so.)
(Whoops, I wrote a draft reply but didn't send it earlier.) i and j are two indexes from slices.IndexFunc, whose results are immediately handled by a switch. Giving then longer names makes the switc…
(Marking this thread unresolved so this CL isn't accidentally submitted before Hana has a chance to see this thread.)
@hyangah@gmail.com, this CL is automatically generated as part of the monthly "tag golang.org/x repos" workflow. In addition to tagging, it also updates golang.org/x dependencies. I know you tempora…
Tasks added by expansions, in contrast to all other tasks, didn't handle the sub-workflow prefix. A while back I looked into it briefly, and saw that shallowClone didn't clone that one field, so figu…
I considered how we can fix this. One path is to modify the workflow so that it can't run two expansions in parallel. This is tricky, and would make the workflow code less readable - it currently cal…
I was able to successfully reproduce this "unknown task" error condition locally with a simplified dry-run release workflow: ![image](https://github.com/user-attachments/assets/0f846eda-b1cb-4f5f-…
During the recently Go minor release workflow, an issue was uncovered where some tasks that needed to be retried and/or approved couldn't be. Retrying the task, which certainly existed, produced the …
This is done.
This is done.
From https://build.golang.org/log/5e58860b238976b022020c1cb9b3537a20adc863: ``` Building Go cmd/dist using /tmp/gobuilder-mips64/go1.4/go. (go1.22.6 linux/mips64) Building Go toolchain1 using /t…
Noting here that if a LUCI builder isn't added to provide test coverage for this port, it risks becoming broken without anyone noticing. There's signal provided by the legacy builders, but it's not v…
We moved the NextMinor label to the parent tracking issue #68587, removing here.
Thanks. Just minor comments for the commit message. The repo name is only needed for the issue tracker. Please replace this prefix to be 'main.star: adjust ...'. We probably want to keep the issue …
(1 comment) FYI it wasn't applied. (It makes no significant difference in this particular case, that's why I made this suggestion optional, but letting you know in case it helps you avoid this happe…
Thanks. Optionally, we could go further and use the same wording here as in all other repos: ```suggestion This repository uses Gerrit for code changes. To learn how to submit changes to this repos…
runtime/race.TestRace failure is pre-existing, #70164, bypassing.
Minor comment, but I'll let Carlos review. Thanks. ```suggestion Components: []template.HTML{"the linker", "cgo", "the runtime"}, ```
Again, both windows-arm64 builders have gone offline as of around Nov 2-5, with first OOMs on Oct 29 ([here](https://github.com/golang/go/issues/69664#issuecomment-2445132269)): <img width="147" a…
Thanks. I've updated this CL to pull in the tip of x/sys now, which includes the revert.
@qmuntal I'm a bit confused by the specifics in your question (maybe you got the wrong CL number mentioned? that one pulls in many x/sys CLs all at once), but in general, if there is a serious issue …
dmitshur commented on time: TestLoadFixed failures2w
[CL 625197](https://go.dev/cl/625197) is an implementation of https://github.com/golang/go/issues/69840#issuecomment-2448571828.
This stops the test from failing with a known failure mode, and creates time to look into what the next steps should be, if any. For #69840.
There indeed turned out to be a small¹ dragon that lurked for some years, but I wouldn't have caught it ahead of trying this out. :) ¹ It's quite literally one byte long, probably couldn't be any …