-
Notifications
You must be signed in to change notification settings - Fork 18k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/compile: builders are unhappy with dev.typeparams #43866
Comments
Change https://golang.org/cl/286034 mentions this issue: |
Updates #43866. Change-Id: I15360de11a48c6f23f25c5ff3a15c117a34127ff Reviewed-on: https://go-review.googlesource.com/c/go/+/286034 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change https://golang.org/cl/286172 mentions this issue: |
I've tried running dev.typeparams's cmd/compile w/ -race on ppc64le, and it didn't expose any issues either. Not terribly surprising, since I don't think there's any ppc64le-specific code on dev.typeparams, so any race issues should be caught by the amd64 racecompile bot. Also, it does look like the x/build coordinator has some logic specific to handling "go_test:", so it does seem plausible the new "go_test_g3:" tests are causing some trouble: https://github.com/golang/build/blob/master/cmd/coordinator/coordinator.go |
This CL backports a bunch of changes that landed on dev.typeparams, but are not dependent on types2 or generics. By backporting, we reduce the divergence between development branches, hopefully improving test coverage and reducing risk of merge conflicts. Updates #43866. Change-Id: I382510855c9b5fac52b17066e44a00bd07fe86f5 Reviewed-on: https://go-review.googlesource.com/c/go/+/286172 Trust: Matthew Dempsky <mdempsky@google.com> Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
dev.typeparams was merged into master successfully. I believe this can now be closed. @mdempsky ? |
I'm going to close this. I filed #51399 to clean up dev.typeparams. |
A decent number of non-trybot builders at https://build.golang.org/?repo=&branch=dev.typeparams are failing. I was expecting the dev.regabi->dev.typeparams merge to help with this, and it did a little, but there's still a lot of red. We should probably try to investigate some of this before it becomes too hard to figure out the root cause.
A bunch of random notes:
A lot of the longtest builders initially started failing because of cmd/go: TestScript/mod_get_fallback relies on x/tools not being tagged #43795. E.g., this failure was because of a faulty test: https://build.golang.org/log/2b42b8d257452fded5ccd804a16b9f087bfca40e. This was fixed on master, and the fix was merged to dev.regabi and then dev.typeparams.
On dev.typeparams we did change cmd/dist to run "go test std cmd" with and without
-G=3
(https://go-review.googlesource.com/c/go/+/285052), and this seems to coincide with some of the longtest builders getting stuck. Maybe that CL is interacting poorly with the build coordinator? (/cc @dmitshur) This seems to also coincide with the windows-race and openbsd-386 builders reacting badly.The ppc64le builders have been failing for a while. The power9osu builder started failing at https://go-review.googlesource.com/c/go/+/279920. The buildlet became flaky a little bit after that, and seems to have gotten progressively worse, up to failing consistently recently. I tried reproducing on my personal ppc64le machine but didn't have any problems running all.bash with GOPPC64 set to either power8 or power9.
I also skimmed the diff between dev.regabi and dev.typeparams, and I didn't see anything obvious that I thought should affect these builders. Regardless, I plan to backport a lot of the non-types2-dependent changes to dev.regabi, which should help narrow down the root cause (and hopefully help reduce conflicts to make future merges easier).
There are some windows failures that I think are just due to test/run.go's list of known-failing tests uses UNIX file paths, but test.goFileName uses filepath.Join. So it'll have
\
characters instead of/
on Windows./cc @griesemer @findleyr @danscales
The text was updated successfully, but these errors were encountered: