Comparing changes

Context: bazelbuild/bazel-central-registry#547

This relands cd98170, which was reverted by commit 4660427. The Xcode toolchain is now only enabled in tests.

By updating gazelle to a version that maintains a central registry of gazelle overrides, specifying `build_file_proto_mode` on `github.com/gogo/protobuf` is no longer necessary. This will allow us to get rid of the rules_go exception after the next rules_go release.

…x_sys` (#3512) * Fix use of `//go` by exposing `@org_golang_x_sys` when using Bzlmod Running `bazel run //go` (or `bazel run @rules_go//go` from another module) fails when using Bzlmod because the `@org_golang_x_sys` repository is not visible. Without Bzlmod, the repository is loaded through a WORKSPACE dependency and the error does not happen. Two-step minimal reproduction from root of this repo: 1. `touch WORKSPACE.bzlmod` 2. `bazel run --enable_bzlmod //go` Here's the error that produces: ```shell $ bazel run --enable_bzlmod //go DEBUG: gazelle@0.27.0/MODULE.bazel:7:6: WARNING: The bazel_gazelle Bazel module is still highly experimental and subject to change at any time. Only use it to try out bzlmod for now. WARNING: For repository 'com_google_protobuf', the root module requires module version protobuf@3.19.2, but got protobuf@3.19.6 in the resolved dependency graph. ERROR: /Users/brice/Documents/Code/rules_go/go/tools/go_bin_runner/BUILD.bazel:11:11: no such package '@[unknown repo 'org_golang_x_sys' requested from @]//unix': The repository '@[unknown repo 'org_golang_x_sys' requested from @]' could not be resolved: No repository visible as '@org_golang_x_sys' from main repository and referenced by '//go/tools/go_bin_runner:go_bin_runner_lib' ERROR: Analysis of target '//go:go' failed; build aborted: INFO: Elapsed time: 3.043s INFO: 0 processes. FAILED: Build did NOT complete successfully (45 packages loaded, 865 targets configured) currently loading: go/platform ERROR: Build failed. Not running target ``` Here's the point in the BUILD file where this repository is being referenced: https://github.com/bazelbuild/rules_go/blob/e558f56df9995f571e49de336c3831d407d9ff70/go/tools/go_bin_runner/BUILD.bazel#L25 * Remove `process_unix.go` and use `process.go` for all platforms. Eliminates dependency on `@org_golang_x_sys`. * Add Bzlmod test for //go --------- Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

* go_register_toolchains: update sdk_kinds After 89e3296, we have renamed _go_download_sdk to go_download_sdk_rule so that we could re-use the implementation inside the Bazel Module Extension setup. Update go_register_toolchains to pick up this change. * Update sdk.bzl

* Reference `rulesGoRepositoryName` (sourced from environment variable) instead of hard-coding `@io_bazel_rules_go` repo name. * gopackagesdriver: Inject rules_go repo name via x_defs This ensures that we always specify the correct repo name when invoking the aspect, even with Bzlmod (where users usually refer to rules_go as `@rules_go`, not `@io_bazel_rules_go`, but could choose any apparent repository name for it). --------- Co-authored-by: Brice <33697112+bricedp@users.noreply.github.com>

https://groups.google.com/g/golang-announce/c/Xdv6JL9ENs8

The definition of the go_rule function in now prints the following message: The go_rule function has been removed. Use rule directly instead. Remove reference to go_rule from the go_context documentation. Co-authored-by: Zhongpeng Lin <zplin@uber.com>

We never compile CGo with coverage instrumentation and the stdlib contains no user-provided C/C++ code, so linking coverage runtimes is never needed.

This was flipped in bazelbuild/continuous-integration#1579, but breaks //tests/core/cgo:versioned_dylib_test.

* Add defines for assembly build Fixes #1894 by adding GOOS_ GOARCH_ and GOOS_GOARCH_ defines for building assembly. * Return a copy of args * Use build.Default variables for os and arch Add a compilation test that uses another architecture with conditional inclusion of an assembly function. This mimics a real library that fails to build under rules_go. --------- Co-authored-by: Patrick Scott <patrick.scott@observeinc.com>

) Fixes failures such as: https://buildkite.com/bazel/rules-go-golang/builds/5066#01878f4b-c637-4080-b1df-47ff2e0e5f63/276-300 caused by bazelbuild/continuous-integration#1585.

On darwin, in repositories with many transitions configured such as rules_go.git, the action GoToolchainBinaryBuild could be run multiple times in parallel by Bazel. Each of these actions would execute a command like this in a sandbox: ``` $GO build -o $OUTPUT -trimpath \ go/tools/builders/ar.go \ go/tools/builders/asm.go \ go/tools/builders/builder.go \ go/tools/builders/cgo2.go \ go/tools/builders/compilepkg.go \ go/tools/builders/cover.go \ go/tools/builders/edit.go \ go/tools/builders/embedcfg.go \ go/tools/builders/env.go \ go/tools/builders/filter.go \ go/tools/builders/filter_buildid.go \ go/tools/builders/flags.go \ go/tools/builders/generate_nogo_main.go \ go/tools/builders/generate_test_main.go \ go/tools/builders/importcfg.go \ go/tools/builders/link.go \ go/tools/builders/pack.go \ go/tools/builders/read.go \ go/tools/builders/replicate.go \ go/tools/builders/stdlib.go \ go/tools/builders/stdliblist.go \ go/tools/builders/path.go ``` Then, each `go build` process would execute multiple `go tools compile` command up to the number of max Go routines it is set to. The default max number of Go routines for each `go build` process is the number of core on the machine executing the action. On a local build, this means that we could have up to n x n number of goroutines running in parallel when combining the asynchronousity of both Bazel and `go build`. After upgrading to Go 1.20.x, we observed that such parallelism could get a local MacOS machine run into a deadlock on the OS-level, halting spawn of new processes such as `git config`, or new Chrome tab browser. Typical sampling of a `go build` process stuck in deadlock would result in the following call graphs: ``` 2430 Thread_44978 DispatchQueue_1: com.apple.main-thread (serial) + 2430 ??? (in <unknown binary>) [0x1358] + 2430 runtime.asmcgocall.abi0 (in go) + 124 [0x100b702ac] + 2430 runtime.syscall6.abi0 (in go) + 56 [0x100b71a98] + 2430 __wait4_nocancel (in libsystem_kernel.dylib) + 8 [0x1a17a04f4] 2430 Thread_44999 + 2430 runtime.asmcgocall.abi0 (in go) + 201 [0x100b702f9] + 2430 runtime.pthread_cond_timedwait_relative_np_trampoline.abi0 (in go) + 28 [0x100b717ec] + 2430 _pthread_cond_wait (in libsystem_pthread.dylib) + 1276 [0x1a17d45a0] + 2430 __psynch_cvwait (in libsystem_kernel.dylib) + 8 [0x1a1797710] 2430 Thread_45038 + 2430 runtime.kevent_trampoline.abi0 (in go) + 40 [0x100b71518] + 2430 kevent (in libsystem_kernel.dylib) + 8 [0x1a179a060] ``` We could not reproduce outside of Bazel (using bash & to parallelize `go build`). We also could not reproduce this issue with Go 1.19 releases. Let's apply a rudimentry workaround by limitting the concurrency of `go build` process by setting it's max Go routines to 1. This should make this and future race conditions happen a lot less on all platforms. By doing this, we rely more on Bazel and less on Go runtime to saturate our CPU resources. This change should not affect remote execution as the default ResourceSet for each action is set at 1 CPU and 250MB RAM.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Comparing changes

Open a pull request

Commits on Apr 20, 2023

This comparison is taking too long to generate.

Uh oh!