)]}'
{
  "log": [
    {
      "commit": "b957e9fc1139ada3b876d24d38215f537bdfe68c",
      "tree": "279c1f345c47c3de789cf4742324939fd4fe32e3",
      "parents": [
        "85b614ebe767934dd481fa2a7b6ab8803a829405"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Tue Oct 20 14:39:27 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Oct 20 14:39:27 2026 +0200"
      },
      "message": "Remove the `request_nogo` setting (#4761)\n\n**What type of PR is this?**\n\nOther\n\n**What does this PR do? Why is it needed?**\n\n`//go/private:request_nogo` was added in #2922 so that tools built in\nthe legacy host configuration, which couldn\u0027t apply the transition\n`go_context_data` used to set it to `True`, would fall back to the noop\nnogo. Host mode is gone, #4611 removed that transition and flipped the\ndefault to `True`, and since #4755 no rules_go transition sets it at\nall. `nogo_active` therefore only ever depends on `bootstrap_nogo`, the\nactual cycle guard that `go_tool_transition` sets for nogo and other Go\ntools.\n\nThis removes the setting and leaves `bootstrap_nogo` as the only nogo\nsetting:\n\n* `nogo_active` only checks `bootstrap_nogo`.\n* `bootstrap_nogo \u003d False` is part of the dict of default values that\nthe tool transitions start from, and only `go_tool_transition` sets it\nto `True`. The separate dict for the tool value and the overrides in the\nnon-Go tool and stdlib transitions that reset it to `False` are gone.\n\n**Which issues(s) does this PR fix?**\n\n**Other notes for review**"
    },
    {
      "commit": "85b614ebe767934dd481fa2a7b6ab8803a829405",
      "tree": "dedfc6404adf421aecbf83e2870fbb666ffa453f",
      "parents": [
        "d0c5a4226bc2eb5cd45a05a1f50d5def92b4d86d"
      ],
      "author": {
        "name": "Keith Mosher",
        "email": "kmosher@pulumi.com",
        "time": "Tue Oct 20 06:45:40 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Oct 20 10:45:40 2026 +0000"
      },
      "message": "Tag the nogo alias manual like the target behind it (#4759)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nThe `nogo` macro tags `\u003cname\u003e_actual` `manual`, so wildcards like\n`//...` skip it; the comment in the macro explains why. The alias\n`\u003cname\u003e`, which selects between that target and `//:default_nogo`, gets\nno tags, so `bazel build //...` and `bazel test //...` match the alias\nand build nogo anyway.\n\nThat build happens in a configuration derived from the target\nconfiguration (via `go_tool_transition`), not the exec configuration in\nwhich every Go target builds nogo. It is therefore a complete second\nbuild of nogo and all its analyzers\u0027 dependencies that nothing consumes.\nIn our repository that was about 500 `GoCompilePkg` actions.\n\nThis passes the same tags to the alias. nogo is still built as a tool\ndependency of every Go target, as before.\n\n**Which issues(s) does this PR fix?**\n\nNone filed.\n\n**Other notes for review**\n\n`tests/core/nogo/wildcard` checks that both targets the macro creates\nare tagged `manual`. Without the change it fails with `//:my_nogo is not\ntagged manual; manual targets: [//:my_nogo_actual]`.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\nCo-authored-by: Claude Opus 5.5 (1M context) \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "d0c5a4226bc2eb5cd45a05a1f50d5def92b4d86d",
      "tree": "4b29a8de66bf53e6725cd26d8c235659e5ef0df0",
      "parents": [
        "8b767472109827eac968a72298a40e42701f353e"
      ],
      "author": {
        "name": "Keith Mosher",
        "email": "kmosher@pulumi.com",
        "time": "Tue Oct 20 05:00:26 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Oct 20 11:00:26 2026 +0200"
      },
      "message": "Reset request_nogo to its default value in go_tool_transition (#4755)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\n`go_tool_transition` sets `request_nogo \u003d False` for Go tools, but that\nchanges nothing: `bootstrap_nogo \u003d True`, set in the same transition, is\nwhat already keeps nogo from running for them. The stray write only\nmakes tool configurations differ from every other configuration in one\nmore setting, and each difference forks the configuration of everything\nresolved in it. With a C++ toolchain that builds its runtimes from\nsource, such as hermetic-llvm, that means analyzing and building the\nruntimes again for every tool configuration.\n\n#4705 already stopped the stdlib and non-Go tool transitions from\nsetting `request_nogo`. This does the same for `go_tool_transition`, so\ntools differ from plain exec tools only in `bootstrap_nogo`.\n\nNothing in rules_go sets `request_nogo` to `False` any more; only a\ncommand-line flag does. nogo still runs for first-party code.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4753\n\n**Other notes for review**\n\n- `_common_reset_transition_dict` now holds the default `request_nogo \u003d\nTrue`, which makes the per-transition overrides in the stdlib and non-Go\ntool transitions redundant, so they are removed.\n- The comments on `request_nogo` and `nogo_active` named `request_nogo`\nas the circular dependency guard; they now name `bootstrap_nogo`.\n- The new test in `tool_settings_test` asserts that nogo\u0027s configuration\ndiffers from a plain exec tool\u0027s in no rules_go setting but\n`bootstrap_nogo`. Without this change it fails with `nogo differs from\nplain exec tools in private:bootstrap_nogo\u003dnull vs true,\nprivate:request_nogo\u003dnull vs false`.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\nCo-authored-by: Claude Sonnet 5.5 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "8b767472109827eac968a72298a40e42701f353e",
      "tree": "c4c4cc933214993c7e73e9bd965db98a61c063e8",
      "parents": [
        "20008e8ca02add2d4ae2f3edf514d94afa3ee0be"
      ],
      "author": {
        "name": "Yannic",
        "email": "yannic@engflow.com",
        "time": "Tue Oct 20 00:13:20 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Oct 20 00:13:20 2026 +0200"
      },
      "message": "coverage: skip blocks without statements in LCOV output (#4758)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nGo coverage profiles contain blocks with zero statements for empty\nfunction bodies. A common source is the unexported marker methods used\nto seal interfaces, for example `func (impl) privateFooDoNotCall() {}`.\n`go tool cover` excludes these blocks, but rules_go turned every line\nthey span into an uncovered `DA` entry. Empty methods therefore showed\nup as uncovered lines that no test can reach.\n\nThe bug was in two places, and this PR skips blocks with `numStmt \u003d\u003d 0`\nin both:\n\n- `go/tools/bzltestutil/lcov.go`, which converts measured coverage\nprofiles.\n- `go/tools/builders/baseline_coverage.go`, which produces baseline\ncoverage for packages that no test links. Its comment requires it to\nmatch the measured converter.\n\nA file that contains only empty functions still gets an `SF` record,\nwith `LF:0`, in both outputs.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4757\n\n**Other notes for review**\n\n- The existing `single file` case in `lcov_test.go` used a 0-statement\nblock. I changed it to 1 statement so it still tests line expansion.\n- Tested with `bazel test //go/tools/bzltestutil/...\n//go/tools/builders/... //tests/core/coverage/...`; all 18 tests pass.\n- I also checked the repro from #4757 against this branch using\n`local_path_override`:\n- Measured coverage: `DA:20,0` is gone, and the result is `LH:4 LF:6`\ninstead of `LH:4 LF:7`.\n- Baseline coverage on Bazel 9.3.0, for an untested package with an\nempty method: `DA:7,0` is gone, and only the real statement (`DA:9,0`)\nremains.\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\nCo-authored-by: Claude \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "20008e8ca02add2d4ae2f3edf514d94afa3ee0be",
      "tree": "3344fe0273d60e57a88f6dc4f82ad210573a92e8",
      "parents": [
        "7d3f58b093ddab21ecb4b429d8eefafaf64999f1"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Mon Oct 19 15:50:50 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Oct 19 15:50:50 2026 +0200"
      },
      "message": "go_sdk: read go.mod and go.work files by label (#4756)\n\n**What type of PR is this?**\n\nOther\n\n**What does this PR do? Why is it needed?**\n\n`go_sdk.from_file` read `go.mod` and `go.work` with\n`module_ctx.read(module_ctx.path(label))`. Resolving a label to a path\nmakes the repo containing the file available on disk, which reading a\nsingle file doesn\u0027t need. With Bazel\u0027s\n`--experimental_remote_repo_contents_cache`, this downloads every file\nof a cached repo before the extension can run (bazelbuild/bazel#31005).\nWith `module_ctx.read(label)`, only the file itself is fetched once\nbazelbuild/bazel#31493 lands. In Bazel\u0027s own CI with the cache enabled\n(bazelbuild/bazel#31755), the `path` call blocked the `go_sdk` extension\nfor 1–3 s per job.\n\nParse errors now refer to the file by its label, e.g. `@@//:go.mod:3:\nunexpected token \u0027extra\u0027 after \u00271.23.4\u0027`, instead of its absolute path\nin the output base.\n\n**Which issues(s) does this PR fix?**\n\nWork towards bazelbuild/bazel#31005\n\n**Other notes for review**\n\n`module_ctx.read` accepts labels in all Bazel versions with Bzlmod\nsupport. With a module using `go_sdk.from_file`, the generated SDK repo\nis the same before and after this change."
    },
    {
      "commit": "7d3f58b093ddab21ecb4b429d8eefafaf64999f1",
      "tree": "dc5fb735a2f84ddbd8e69ef0b1c571e940179c30",
      "parents": [
        "f1d6b1be9bd1d60a70ab0dc074dd390ca25109c0"
      ],
      "author": {
        "name": "Yunus Ozen",
        "email": "94426948+ozenyunus35@users.noreply.github.com",
        "time": "Sun Oct 18 13:48:55 2026 +0300"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sun Oct 18 12:48:55 2026 +0200"
      },
      "message": "nogo: report crashes instead of a missing .facts output (#4747)\n\n## What type of PR is this?\n\nBug fix.\n\n## What does this PR do? Why is it needed?\n\nFixes misleading error reporting when `nogo` crashes.\n\nThe `nogo` analyzer can exit with status code 2 in two\ndifferent situations:\n\n- An analyzer reports findings.\n- An unexpected Go panic terminates the analyzer.\n\nPreviously, `runNogo` treated both situations as analyzer\nfindings. When a panic occurred before the `.facts` file\nwas produced, the build reported a misleading\n\"output was not created\" error instead of exposing\nthe original failure.\n\nThis change distinguishes the two cases by checking\nwhether the expected facts file exists.\n\nIf the analyzer exits with code 2 and the facts file\nis missing, the original error output is preserved.\n\nNormal analyzer findings continue to be handled\nas before.\n\nA regression test under `tests/core/nogo/crash/`\ncovers the crash scenario.\n\n## Which issues(s) does this PR fix?\n\nFixes #4698.\n\n## Other notes for review\n\n**Validation**\n\n- Buildkite `buildkite/rules-go-golang` #9229 passed.\n- The regression test covers an analyzer crash\n  that does not produce a `.facts` file.\n- The implementation preserves existing behavior\n  for ordinary analyzer findings.\n\n**Compatibility**\n\nPR #4746 refactors `runNogo` and removes the\n`outFactsPath` parameter.\n\nIf #4746 merges first, this change may require\na small adjustment to the refactored function.\n\n**AI assistance disclosure**\n\nClaude Code (Opus 5.5) assisted with implementation\nand testing. I reviewed the changes and test results."
    },
    {
      "commit": "f1d6b1be9bd1d60a70ab0dc074dd390ca25109c0",
      "tree": "be1b7d5f5c58f2c3cbd431437511114ea5ab9834",
      "parents": [
        "cae4026dca153a773fa7a0c817c5ede09a99f6d8"
      ],
      "author": {
        "name": "Yunus Ozen",
        "email": "94426948+ozenyunus35@users.noreply.github.com",
        "time": "Sat Oct 10 14:48:15 2026 +0300"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 10 13:48:15 2026 +0200"
      },
      "message": "go_test: avoid recompiled archive conflicts between test targets (#4749)\n\n## What type of PR is this?\n\nBug fix.\n\n## What does this PR do? Why is it needed?\n\nFixes conflicting Bazel actions when multiple `go_test` targets\nin the same package recompile the same external dependency.\n\nPreviously, recompiled archives were named using only the\ndependency index, such as `.recompile2.a`.\n\nWhen two test targets recompiled the same dependency at the\nsame index, they declared the same output artifact despite\nrequiring different compilation actions. Bazel rejected the\nbuild with a conflicting actions error.\n\nThis change includes the requesting test target\u0027s name in\nthe archive suffix:\n\n`.recompile_\u003ctest_name\u003e_\u003cindex\u003e.a`\n\nThis makes the output paths unique for each test target.\n\nA regression test adds a second `go_test` target that\nrecompiles the same dependency as an existing test.\n\n## Which issues(s) does this PR fix?\n\nFixes #4736.\n\n## Other notes for review\n\n**Regression verification**\n\n- Before the fix: Bazel failed with conflicting actions\n  for `indirect_import_dep.recompile2.a`.\n- After the fix: Both test targets build and pass.\n\n**Validation**\n\n- Bazel 9.2.0\n- `//tests/core/go_test/...`\n- `//tests/core/coverage/...`\n- `//tests:buildifier_test`\n- 122 tests passed.\n\n**AI assistance disclosure**\n\nClaude Code (Opus 5.5) assisted with implementation\nand testing. I reviewed the changes and test results."
    },
    {
      "commit": "cae4026dca153a773fa7a0c817c5ede09a99f6d8",
      "tree": "2457126cba3390f39949f2c67dacfecc8471b3f5",
      "parents": [
        "2abe8cc56f6a8e8ce4d222b42e287d04d970fa54"
      ],
      "author": {
        "name": "Yunus Ozen",
        "email": "94426948+ozenyunus35@users.noreply.github.com",
        "time": "Sat Oct 10 11:23:03 2026 +0300"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Oct 10 08:23:03 2026 +0000"
      },
      "message": "go_path: remove the bin directory from embedsrcs paths as a prefix (#4748)\n\n## What type of PR is this?\n\nBug fix.\n\n## What does this PR do? Why is it needed?\n\nFixes incorrect embedded source paths generated\nby `go_path`.\n\nPreviously, `go/private/tools/path.bzl` removed\nthe Bazel bin directory using:\n\n`lstrip(ctx.bin_dir.path + \"/\")`\n\nHowever, `lstrip()` removes any leading characters\ncontained in its argument rather than removing\nan exact prefix.\n\nThis can corrupt valid embedded source paths.\nFor example:\n\n`lib/note/a.txt` → `lib/.txt`\n\nThe fix introduces `_trim_prefix()`, which checks\nwhether the expected prefix exists and removes\nit using string slicing.\n\nBoth affected `lstrip()` calls now use this helper.\n\nThis approach also avoids relying on `removeprefix`,\nwhich is unavailable in older supported Bazel versions.\n\nA regression test covers embedded source paths\nthat were previously corrupted.\n\n## Which issues(s) does this PR fix?\n\nFixes #4680.\n\n## Other notes for review\n\n**Regression verification**\n\nThe regression test reproduces the incorrect\nembedded source path before the fix and passes\nwith the corrected prefix handling.\n\n**Local validation**\n\n- Bazel 9.2.0\n- Relevant `go_path` tests passed.\n- Buildifier validation passed.\n\n**CI status**\n\nBuildkite #9231 was still running at the time\nof this report.\n\n**Compatibility**\n\nThe change is limited to embedded source path\nnormalization.\n\n**AI assistance disclosure**\n\nClaude Code (Opus 5.5) assisted with implementation\nand testing. I reviewed the changes and test results.\n\n---------\n\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "2abe8cc56f6a8e8ce4d222b42e287d04d970fa54",
      "tree": "654504d225715896f44d16a903b824518714c019",
      "parents": [
        "090bea98a70216066dc34b4c6731cd05b23ade7a"
      ],
      "author": {
        "name": "Corentin Kerisit",
        "email": "corentin.kerisit@gmail.com",
        "time": "Thu Oct 08 20:03:15 2026 +0900"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Oct 08 13:03:15 2026 +0200"
      },
      "message": "Fix normalization of explicit Clang header paths (#4739)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\ncgo\u0027s compiler path normalization misses `-internal-externc-isystem` and\n`-stdlib++-isystem`, leaving their relative header paths unresolved when\nthe Go build changes directories. With an explicit Clang C-header\ninstallation, building `runtime/cgo` consequently fails with `fatal\nerror: \u0027stdlib.h\u0027 file not found`.\n\nAdd both options to `cgoAbsEnvFlags`. Also skip `-Xpreprocessor`, like\nthe existing `-Xclang` handling, while awaiting a path operand.\nOtherwise `-Xpreprocessor -internal-isystem -Xpreprocessor\nrelative/path` rewrites the forwarding flag itself and leaves the path\nuntouched. The joined `-stdlib++-isystemrelative/path` spelling remains\njoined after normalization.\n\n**Which issues(s) does this PR fix?**\n\nFound while testing explicit Clang header components in hermetic-llvm,\nfollowing hermeticbuild/hermetic-llvm#806.\n\n**Other notes for review**\n\nFour new `TestTransformArgs` cases fail against upstream\n`090bea98a70216066dc34b4c6731cd05b23ade7a` and pass with this change.\n`go test env.go env_test.go flags.go` passes with Go 1.27.1.\n\n`bazel test //go/tools/builders:env_test` also [passes on macOS\nARM64](https://app.buildbuddy.io/invocation/03a2eca4-a11e-4b15-b50d-cecc6e525759).\n\nThe same patch applied to rules_go 0.62.0 fixes the actual GNU/musl cgo\nbuilds in hermetic-llvm: [all 19 root integration tests plus the\nrules_go env test\npass](https://app.buildbuddy.io/invocation/f37fc00c-ce2e-48e4-8782-efa4c46e0998).\nThe unpatched integration failed while building `runtime/cgo`.\n\nThe local upstream `bazel test //...` run stopped when Bazel\u0027s\n`generate-xml.sh` test runner segfaulted on\n`//tests/core/starlark:sdk_tests_test_0` under macOS. The full suite has\nnot passed locally."
    },
    {
      "commit": "090bea98a70216066dc34b4c6731cd05b23ade7a",
      "tree": "27f4512a039e000f0a887deaf626150010c15717",
      "parents": [
        "7928a9362b49f7897b96f0b6e1f2daf40ea43176"
      ],
      "author": {
        "name": "Vytautas Šaltenis",
        "email": "vytas@rtfb.lt",
        "time": "Wed Oct 07 20:16:51 2026 +0300"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Oct 07 19:16:51 2026 +0200"
      },
      "message": "Fix response file handling for compatibility with Go 1.27 (#4738)\n\nThere already was a fix for handling that in cgo context, so just reuse\nit in passLongArgsInResponseFiles.\n\nTo do that, I moved the contents of `cgo_response{_test}.go` to\n`env{_test}.go` as `encodeResponseFileArg()` will no longer be\ncgo-specific. In order to support a fallback to pre-1.27 version,\n`onVersionOrHigher()` was also moved to `env.go`.\n\nFixes #4721."
    },
    {
      "commit": "7928a9362b49f7897b96f0b6e1f2daf40ea43176",
      "tree": "ef4aee034d9daf4bd2cd21818519993adbf033ac",
      "parents": [
        "c18ec4766d81c57cb84f545ea2823d2bd9714766"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Sun Oct 04 02:14:38 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sun Oct 04 08:14:38 2026 +0200"
      },
      "message": "go: declare GoArchive provider fields (#4735)\n\n**What type of PR is this?**\n\nOther\n\n**What does this PR do? Why is it needed?**\n\nDeclare the fields of `GoArchive` in `go/private/providers.bzl` so Bazel\ncan validate `GoArchive` construction and use a defined provider schema.\nThe fields cover both `emit_archive` and the stub archives created by\n`_recompile_external_deps`, including `mode` and the private `_headers`\nand `_buildinfo_link_inputs` fields. Constructors that pass any other\nfields will now fail during analysis.\n\n**Which issues(s) does this PR fix?**\n\nNone.\n\n**Other notes for review**\n\n`buildifier -mode\u003dcheck go/private/providers.bzl` and `git diff\norigin/master --check` pass. Bazel 9.2.0: the three existing\n`go_*_go_archive_required_provider_test` tests,\n`//tests/core/go_test/x_defs:foo_test`, and `//tests/core/cgo:opts_test`\npass. The complete `//...` suite was not run because local disk space\nwas limited."
    },
    {
      "commit": "c18ec4766d81c57cb84f545ea2823d2bd9714766",
      "tree": "88a7a6a62b8850d2a6813c33b5f2db6d077ceb2f",
      "parents": [
        "0e12fcdba192d1a5bd508ec84abc829f1e3bf464"
      ],
      "author": {
        "name": "Régis Desgroppes",
        "email": "regis.desgroppes@datadoghq.com",
        "time": "Thu Oct 01 11:17:55 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Oct 01 11:17:55 2026 +0200"
      },
      "message": "fix(compilepkg): improve coverage reproducibility (#4733)\n\n**What type of PR is this?**\nBug fix\n\n**What does this PR do? Why is it needed?**\nCoverage instrumentation writes sources to `workDir/cover_N.go`, and\nthat random path ended up in the export data, so each compile of the\nsame package yielded a different fingerprint.\nBesides defeating caching for importers, this broke links under\n`--rewind_lost_inputs`, which bazelbuild/bazel#30415 enables by default:\na rewound compile no longer matched the importers kept from before.\n\n\u003d\u003e add `workDir\u003d\u003e` to the compiler\u0027s `-trimpath`, as `cmd/go` does with\nits object directory, ordering rewrites from most specific to most\ngeneral since the first match wins, and also trim the execroot in the\ncgo path (which only trimmed cgo\u0027s own temporary source directory).\n\nThis is covered by a new `Check coverage` subtest of\n`//tests/integration/reproducibility:reproducibility_test`, which builds\na pure Go `go_library` with `--collect_code_coverage` in two copies of\nthe workspace and compares the outputs, failing without this change.\n\n**Which issues(s) does this PR fix?**\nFixes #4732.\n\n**Other notes for review**\nOutputs without `--collect_code_coverage` are unchanged.\n\nThe subtest only instruments a pure Go library because coverage of cgo\npackages still depends on the execroot path, not covered here."
    },
    {
      "commit": "0e12fcdba192d1a5bd508ec84abc829f1e3bf464",
      "tree": "a9d9d1eacfe98c77f168e204791fcf0bdcffffdf",
      "parents": [
        "78e348aba7be3d30392f4c97a4b94ab456686cac"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Wed Sep 30 16:22:11 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Sep 30 14:22:11 2026 +0000"
      },
      "message": "Don\u0027t run Bazel in the release workflow (#4731)\n\n**What type of PR is this?**\n\nOther\n\n**What does this PR do? Why is it needed?**\n\nThe reusable release workflow runs `bazel test //...` before creating\nthe release archive. On GitHub\u0027s runners this takes more than an hour\nand has failed both the v0.63.0 and the v0.64.0 release with a timeout\nof `//tests/core/cross:proto_test`.\n\nEvery commit is already tested on Buildkite and the release archive is\ncreated with `git archive`, so there is no need to build or test\nanything with Bazel at release time.\n\nThe reusable workflow has no way to skip the test step and\nunconditionally appends `--disk_cache` and `--repository_cache` flags to\nthe command, so it is replaced with `true`, which ignores its arguments.\n\n**Which issues(s) does this PR fix?**\n\n**Other notes for review**"
    },
    {
      "commit": "78e348aba7be3d30392f4c97a4b94ab456686cac",
      "tree": "1b8518d6f816c096b579d3c0b4e99a48e2613c09",
      "parents": [
        "970e99d77c8bec98daed9b96845018617a65bd26"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Wed Sep 30 13:51:32 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Sep 30 11:51:32 2026 +0000"
      },
      "message": "Set an empty module version for Publish to BCR to replace (#4730)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nPublish to BCR only stamps the release version correctly if `module()`\nhas a `version` attribute. Without one, it picks up the `version` of the\nfirst `dev_go_deps.module` tag and then rewrites the version of the\nfirst `bazel_dep` instead. For v0.63.0, this resulted in a BCR entry\nthat depended on `bazel_features@0.63.0`, which had to be repaired by\nhand in https://github.com/bazelbuild/bazel-central-registry/pull/10070.\nSince the attestations for the broken `MODULE.bazel` and `source.json`\nfiles had already been uploaded to the by then immutable release, the\nentry also had to drop its `attestations.json`.\n\nAn explicit empty version is equivalent to no version, so rules_go still\nreports an empty version when used via a non-registry override (#4380).\nThis is the same setup as in bazel-gazelle.\n\n**Which issues(s) does this PR fix?**\n\nWorks around https://github.com/bazel-contrib/publish-to-bcr/issues/426\n\n**Other notes for review**\n\nReplaying the version stamping logic of Publish to BCR on the updated\nfile for `0.64.0` gives the expected patch:\n\n```diff\n@@ -2,7 +2,7 @@\n     name \u003d \"rules_go\",\n     # Replaced with the release version by Publish to BCR, which requires the attribute to be\n     # present. Empty rather than a placeholder so that overrides don\u0027t report a bogus version.\n-    version \u003d \"\",\n+    version \u003d \"0.64.0\",\n     compatibility_level \u003d 0,\n     repo_name \u003d \"io_bazel_rules_go\",\n )\n```"
    },
    {
      "commit": "970e99d77c8bec98daed9b96845018617a65bd26",
      "tree": "6b3df16d33167512e13a8cf269846519dee7f202",
      "parents": [
        "debbd38894323f58cc567c4b1ac352351e15f30f"
      ],
      "author": {
        "name": "Keith Smiley",
        "email": "keithbsmiley@gmail.com",
        "time": "Wed Sep 23 15:51:54 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Sep 24 00:51:54 2026 +0200"
      },
      "message": "Pass new -macos flag (#4725)\n\nThis was added in go 1.27 and now respects the bazel config for the\ncurrent macOS target version\n\nhttps://go.dev/doc/go1.27"
    },
    {
      "commit": "debbd38894323f58cc567c4b1ac352351e15f30f",
      "tree": "5a37b6d42a9c3d509a2d22eb152a880e908ce1ba",
      "parents": [
        "84c8f106c8043a0a3172bd04efebf00ea1b2b6ab"
      ],
      "author": {
        "name": "Keith Smiley",
        "email": "keithbsmiley@gmail.com",
        "time": "Wed Sep 23 01:20:36 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Sep 23 10:20:36 2026 +0200"
      },
      "message": "Pass -pthread over -mthreads on windows (#4722)\n\nGo itself recently started doing this\nhttps://github.com/golang/go/commit/9fb7b20135165dca0a106b4bcf9b599a2d19ed3b\n\nClang warns about how passing this flag is unused"
    },
    {
      "commit": "84c8f106c8043a0a3172bd04efebf00ea1b2b6ab",
      "tree": "03b9c49dbe9b739955375f06d92edf1dc1ce750c",
      "parents": [
        "e7c4c5c518faf07b34d0dfb702ab0e721623e650"
      ],
      "author": {
        "name": "Keith Smiley",
        "email": "keithbsmiley@gmail.com",
        "time": "Tue Sep 22 16:05:53 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Sep 22 23:05:53 2026 +0000"
      },
      "message": "Stop silencing error on windows (#4723)\n\nPreviously errors from your cc toolchain might be hidden:\n\n```\nlld: error: unable to find library -lmingwthrd\n```"
    },
    {
      "commit": "e7c4c5c518faf07b34d0dfb702ab0e721623e650",
      "tree": "3d6ab24e9006119ee21f7aadae87a37498002c1a",
      "parents": [
        "1b78046436028ebd84b36ffc2422c82467a01bfc"
      ],
      "author": {
        "name": "Régis Desgroppes",
        "email": "regis.desgroppes@datadoghq.com",
        "time": "Tue Sep 22 17:24:12 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Sep 22 17:24:12 2026 +0200"
      },
      "message": "Also pass GOEXPERIMENT to `go_tool_binary` actions (#4717)\n\n**What type of PR is this?**\nBug fix\n\n**What does this PR do? Why is it needed?**\n`_go_tool_binary_impl` builds `cmd/pack`, `cmd/covdata`, and its own\n`{srcs}` output directly from the SDK\u0027s Go source via `go build`,\nsetting several hermeticity env vars (`GOTOOLCHAIN`, `GO111MODULE`,\n`GOTELEMETRY`, `GOENV`) but never `GOEXPERIMENT`, in either its Windows\nbatch-script path or its Unix `ctx.actions.run` `env` dict.\n\u003d\u003e thread `sdk.experiments` into both, matching the same pattern\n`go/private/context.bzl` already uses for every other Go action\n(`\"GOEXPERIMENT\": toolchain.sdk.experiments`).\n\nFor an SDK whose stdlib needs a specific `GOEXPERIMENT` to compile at\nall, such as Microsoft Go\u0027s `crypto/internal/backend/fips140` package,\npart of which is gated behind a `GOEXPERIMENT`-driven build tag, the\nmissing forwarding made the from-source tool build fail with `undefined:\nsystemFIPSMode`: the file defining that symbol was skipped by the\nunsatisfied tag while other, always-compiled files in the same package\nstill referenced it.\n\nThis is covered by `TestGoToolBinaryExperiments`, reusing the existing\n`multiple_sdks_by_name` test case\u0027s `go_sdk_with_experiments`\ndeclaration (`experiments \u003d [\"rangefunc\"]`) to build `:builder` and\nassert the resulting binary\u0027s own build info reports `GOEXPERIMENT`\ncontaining `rangefunc`, since that sibling test only exercises\ntarget-code compilation, not `go_tool_binary` itself.\n\n**Which issues(s) does this PR fix?**\nFixes #4716.\n\n**Other notes for review**\nBuilt upon:\n- #3401: introduced setting GOEXPERIMENT as an env var on build actions,\n- #4022: refined how that same env var gets passed into actions.\n\n`sdk.experiments` defaults to an empty string, so this is a no-op for\nany SDK that doesn\u0027t set it.\n\n#4547 proposes a separate `toolchain_experiments` attribute so the\ntoolchain build can diverge from target code.\n\u003d\u003e this is narrower and orthogonal: `go_tool_binary` should forward the\nSDK\u0027s existing `experiments` the same way every other action already\ndoes, regardless of whether a separate override is ever added on top."
    },
    {
      "commit": "1b78046436028ebd84b36ffc2422c82467a01bfc",
      "tree": "c11b6b4cbe9b98132350dcb0e638f0324614294b",
      "parents": [
        "18a6fbb9f4fa93331640efddf81271eb467710f4"
      ],
      "author": {
        "name": "Ketaki tank",
        "email": "ktank@aurora.tech",
        "time": "Mon Sep 14 12:04:55 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Sep 14 19:04:55 2026 +0000"
      },
      "message": "bzltestutil: report testing.Attr attributes as JUnit XML properties (#4714)\n\n**What type of PR is this?**\n\n\u003e Bug fix\n\n**What does this PR do? Why is it needed?**\n\nGo 1.25 added [`testing.Attr(key,\nvalue)`](https://pkg.go.dev/testing#T.Attr), which\nrecords a key/value pair against a test and prints an `\u003d\u003d\u003d ATTR ` line\nin the test log.\nUnder `go_test` those attributes are currently dropped silently — they\nnever reach the\n`test.xml` Bazel writes, and the test author gets no indication the call\ndid nothing.\n\nThe data is present in the raw output: bzltestutil already runs tests\nwith\n`-test.v\u003dtest2json`, and `testing.Attr` only prints in chatty mode, so\nthe line is\ngenuinely emitted. It is lost in conversion, in two places:\n\n- `test2json.go` is a copy of go1.23.6\u0027s\n`src/cmd/internal/test2json/test2json.go`, whose\nheader notes the files \"should be kept in sync\". Upstream go has since\nadded\n`\"\u003d\u003d\u003d ATTR \"` to its `updates` marker list; the copy here has not, so\nthe line is\n  treated as ordinary output instead of producing an `attr` event.\n- `xml.go` has no notion of properties at all, so even a well-formed\n`attr` event would\n  have nowhere to go.\n\nThis PR fixes both halves:\n\n- `test2json.go` recognizes `\"\u003d\u003d\u003d ATTR \"` and parses `TestName key\nvalue` into the\nevent\u0027s `Test`/`Key`/`Value` fields. The parsing mirrors upstream go\u0027s\nown handling\nof the same marker, which nudges the vendored copy back toward being in\nsync.\n- `xml.go` gains `Key`/`Value` on `jsonEvent`, a `case \"attr\"` in\n`json2xml`, and a\n`Properties` field on `xmlTestCase`, rendered as `\u003cproperty\u003e` elements.\n\nWith the change, a test calling `t.Attr(\"requirement_id\", \"REQ-1234\")`\nproduces:\n\n```xml\n\u003ctestcase classname\u003d\"demo\" name\u003d\"TestWithAttr\" time\u003d\"\"\u003e\n\t\u003cproperties\u003e\n\t\t\u003cproperty name\u003d\"requirement_id\" value\u003d\"REQ-1234\"\u003e\u003c/property\u003e\n\t\u003c/properties\u003e\n\u003c/testcase\u003e\n```\n\n**Which issues(s) does this PR fix?**\n\nResolves #4713\n\n**Other notes for review**\n\nTests added:\n\n- `\u003d\u003d\u003d ATTR` line produces a correctly-populated `attr` JSON event.\n- Full round trip — raw test output → `Converter` → JSON → `json2xml` →\nXML — asserting\nthe `\u003cproperty\u003e` element actually appears. This one is deliberately\nend-to-end: patching\nonly `xml.go` would leave its `attr` case unreachable, and a test of\neither half alone\n  would not catch that.\n- Attributes recorded inside a subtest attach to the subtest\u0027s\n`\u003ctestcase\u003e`, not the\n  parent\u0027s.\n- A golden-file fixture pair (`testdata/attr.json` / `attr.xml`) for the\nexisting\n  `TestJSON2XML` table test.\n\nVerified on `master`: `gofmt` and `go vet` clean, `bazel test\n//go/tools/bzltestutil:all`\npasses, and the pre-existing `report`/`empty`/`timeout` fixtures pass\nunmodified — the\nchange is additive for tests that never call `Attr`.\n\nOne open question for maintainers: `setProperty` uses last-write-wins\nwhen the same key is\nrecorded twice, which matches GoogleTest\u0027s `RecordProperty` and keeps\nthe JUnit output\ntidy. `testing.Attr` itself does not define de-duplication semantics, so\nif you would\nrather append every occurrence, that is a small change and I am happy to\nmake it."
    },
    {
      "commit": "18a6fbb9f4fa93331640efddf81271eb467710f4",
      "tree": "ed90537aeb8433bb55c7e29b619ed9a99f5ef9bd",
      "parents": [
        "7da903b60f6e97643166e56ecd15c46f9aa61a66"
      ],
      "author": {
        "name": "Régis Desgroppes",
        "email": "regis.desgroppes@datadoghq.com",
        "time": "Fri Sep 11 19:13:44 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Sep 11 17:13:44 2026 +0000"
      },
      "message": "link: report only actually-reachable deps in build info (#4709)\n\n**What type of PR is this?**\nBug fix\n\n**What does this PR do? Why is it needed?**\n`runtime/debug.BuildInfo().Deps`, built by #4595 (thanks again!), walks\nthe full declared Bazel `deps` graph instead of the packages actually\nimported.\n\nThis diverges from `cmd/go`\u0027s own `(*Package).setBuildInfo` in\n`cmd/go/internal/load/pkg.go`, which walks only `p.Internal.Imports`.\n\nThe mismatch makes `debug.BuildInfo().Deps` over-report dependencies,\nproducing false positives for `govulncheck` and SBOM/vulnerability\nscanners that trust it to mean packages actually linked into the binary.\n\nEach compiled package now writes an `-imports` manifest listing the\n`packagePath`s its filtered sources actually import, the same set\n`checkImports` already computes for the compiler\u0027s `importcfg`.\n\n`GoLink` walks this manifest graph by BFS from the main package and\nfilters `package_metadata` down to the genuinely reachable set, instead\nof trusting the full declared closure.\n\nReachability is keyed by `packagePath` rather than Bazel label, since a\nsingle `go_test` rule compiles multiple archives, internal, external,\nand a synthetic `testmain`, that all share one label.\n\n`packagePath` is unique per compiled package within a link, matching the\nidentity the linker itself already relies on for deduplication via\n`depsSeen` in `buildImportcfgFileForLink`.\n\nA `go_binary`\u0027s own `packagePath` is purely cosmetic and not enforced to\nbe unique, so it can collide with a dependency\u0027s real one.\nThe main archive\u0027s own imports are therefore passed directly via a new\n`-main_imports` flag instead of being looked up by that ambiguous key,\nand its entry is excluded from the general `-imports` list `GoLink`\nwalks.\n`TestReadBuildInfoCollidingImportpath` reproduces this collision.\n\n`TestReadBuildInfoDeps` is updated to assert that a\ndeclared-but-unimported dependency no longer appears.\n\n`TestGoTestBuildInfoDepsEmbeddedLib` and `TestBuildInfoDepsEmbeddedLib`\nare added to cover the stub `GoArchive` branch that\n`_recompile_external_deps` takes for a library that is embedded but not\nitself imported.\n\n**Which issues(s) does this PR fix?**\nFixes #4708.\n\n**Other notes for review**\n`emit_link` derives the `-package_metadata` and `-imports` flags from\n`archive.transitive` plus `test_archives`, excluding the main archive\u0027s\nown entry from `-imports` since its `packagePath` can collide with a\ndependency\u0027s.\n\nThe link action\u0027s `File` inputs come from a dedicated, recursively-built\n`_buildinfo_link_inputs` field on `GoArchive`, not from\n`archive.transitive`, since `depset`s support lazy merging of same-typed\n`depset`s but not lazy transformation into a different element type, so\nthere is no way to extract `_imports`/`_package_metadata` `File`s from\n`GoArchiveData` elements without an eager pass.\n\nExcluding the main archive from `-imports` uses a `map_each` closure\nover its file path, with `allow_closure \u003d True` since only a small\nstring is captured, not a large analysis-phase object."
    },
    {
      "commit": "7da903b60f6e97643166e56ecd15c46f9aa61a66",
      "tree": "46bf997893c93dc17741966977467a80f386eb95",
      "parents": [
        "08a0c1268f044674215c97dfa7272d2137c6864c"
      ],
      "author": {
        "name": "Showta Ishizaki",
        "email": "zakinko@snowrabbit.org",
        "time": "Wed Sep 09 17:25:38 2026 +0900"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Sep 09 10:25:38 2026 +0200"
      },
      "message": "Detect the host platform on DragonFly (#4711)\n\ndetect_host_platform takes ctx.os.name as GOOS and maps the two cases\nwhere the JVM spells the name differently, \"mac os x\" and \"windows ...\".\nDragonFly is a third: the JVM reports \"dragonflybsd\" where Go says\n\"dragonfly\". Go ships dragonfly-amd64 in every release, and\nplatforms.bzl\nalready lists the pair.\n\nOn DragonFly 6.4 today a go_binary stops at\n\n    no such target \u0027@@rules_go+//go/toolchain:dragonflybsd\u0027\n\nWith this change the SDK and the toolchain get their right names.\nToolchain resolution on a DragonFly host still needs\n@platforms//os:dragonfly, which bazelbuild/platforms#143 adds; once that\nis in the platforms release rules_go depends on, one line in\nBAZEL_GOOS_CONSTRAINTS maps \"dragonfly\" to it. I have kept that line out\nof this change, since the label does not exist yet. With both applied\nlocally, a go_binary builds and runs on DragonFly 6.4 (Bazel 10.0.0-pre,\nGo 1.25.1: \"hello from dragonfly amd64\")."
    },
    {
      "commit": "08a0c1268f044674215c97dfa7272d2137c6864c",
      "tree": "9876477c8aad834194c89cab590869e4726ed9db",
      "parents": [
        "2392cc0e89eb4ac6e34b270eb1e3599bf1055e20"
      ],
      "author": {
        "name": "faximan",
        "email": "207300+faximan@users.noreply.github.com",
        "time": "Mon Sep 07 17:28:03 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Sep 07 15:28:03 2026 +0000"
      },
      "message": "cgo: support `compilation_context.external_includes` (#4710)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nWhen `--features\u003dexternal_include_paths` is enabled in Bazel, external\nrepository include directories are collected into\n`CcInfo.compilation_context.external_includes` rather than standard\nincludes.\n\nPreviously, `cgo.bzl` only traversed `defines`, `includes`,\n`quote_includes`, and `system_includes`, omitting `external_includes`.\nConsequently, cgo targets depending on C/C++ targets in external\nrepositories failed to resolve headers during cgo compilation.\n\nThis change:\n1. Forwards `compilation_context.external_includes` as `-isystem` in\n`cgo.bzl` when present.\n2. Adds a test case in `tests/core/cgo:external_includes_test` that\nbuilds a cgo target depending on an external repository `cc_library`\nwith `--features\u003dexternal_include_paths`.\n\n**Which issues(s) does this PR fix?**\n\nNone filed."
    },
    {
      "commit": "2392cc0e89eb4ac6e34b270eb1e3599bf1055e20",
      "tree": "97cf6adb2c44d561d1b983572af0468ddc384edb",
      "parents": [
        "975884f705a9721a3c39bad4033852b0b795a3ce"
      ],
      "author": {
        "name": "Logan Rosen",
        "email": "li_lrosen@microsoft.com",
        "time": "Fri Sep 04 17:21:49 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Sep 04 23:21:49 2026 +0200"
      },
      "message": "coverage: emit a real baseline for packages with no tests (#4669)\n\n**What type of PR is this?**\n\n\u003e Bug fix\n\n**What does this PR do? Why is it needed?**\n\nrules_go doesn\u0027t pass baseline coverage files, so Bazel falls back to\n`BaselineCoverageAction`, which writes only the path and\n`end_of_record`. An untested package lands in the report as `LF:0 /\nLH:0`, which is also what a file with genuinely nothing to cover looks\nlike. Consumers can\u0027t distinguish them, so 0/0 gets scored as 100% and a\npackage with no tests scores better than one with partial tests.\n\nThis runs `cmd/cover` over the target\u0027s own `srcs`, reads back the block\nposition table it appends, and emits LCOV with every coverable line at\ncount 0, handed to Bazel via `baseline_coverage_files`. For an untested\nlibrary:\n\n```diff\n SF:src/untested.go\n-FNF:0\n-FNH:0\n-LF:0\n+DA:4,0\n+DA:5,0\n+DA:6,0\n+DA:7,0\n+LF:4\n LH:0\n end_of_record\n```\n\n**Which issues(s) does this PR fix?**\n\nFixes #4668\n\n**Other notes for review**\n\nIt\u0027s 879 lines, but only 85 touch existing files. The rest is one\nbuilder action, one `.bzl`, and the tests.\n\nThe choices most likely to draw questions:\n\n- The line set comes from `cmd/cover` rather than a separate AST pass,\nso the baseline agrees with measured output by construction rather than\nby approximation. `cover -pkgcfg` with `EmitMetaFile` is the mechanism\n`go test -cover` uses for a package with no test files, which is exactly\nthis situation, and `covdata textfmt` decodes the result into the same\ntext profile `bzltestutil` already consumes. I tried an AST generator\nfirst, and against a file whose real coverage run gives `LF:21` it\nemitted 14 lines, missing `case` clauses, continuation lines of\nmulti-line statements, and closing braces.\n- `covdata` is built from the SDK\u0027s own sources in the same action that\nalready builds `pack` that way, since Go 1.25 dropped both prebuilt\nbinaries from the distribution to shrink it. The shared Go build cache\nmakes the extra build roughly a second, and a `covdata` compiled from\nits own SDK decodes whatever that SDK emits.\n- This adds an optional `covdata` attribute to `go_toolchain`. Custom\ntoolchain definitions that omit it simply emit no baseline, so nothing\nbreaks for them.\n- `Local: true` makes `cmd/cover` record each source under the\nexec-root-relative name it was given, so no path mapping round trip is\nneeded. It changes only the recorded name, not the block positions.\n- An empty meta-data file is the signal that a package has no coverable\nlines, which is structural rather than reconstructed from the sources.\nAn absent one fails the action, so a future change to `EmitMetaFile`\ncannot quietly report `LF:0` everywhere.\n- LCOV writing is hand-rolled, and the profile pattern is duplicated\nfrom `bzltestutil`, because `builder` is a `go_tool_binary` limited to\nthe standard library and `bzltestutil` imports `coverdata`.\n- `go_test` is deliberately untouched, since emitting baselines for\n`_test.go` files would regress results by scoring test files. Embedded\nlibraries are unaffected, as the `go_library` they come from emits its\nown baseline from its own `srcs`. The gap this leaves is a non-test\n`.go` file that lives only in a `go_test`\u0027s `srcs`, which gets no\nbaseline. Happy to close that by filtering test files out of the test\u0027s\nown srcs if you\u0027d prefer.\n- Sources come from `ctx.files.srcs`, not `go_info.srcs`, to match\n`source_attributes \u003d [\"srcs\"]`. `go_info.srcs` would pull in the\ngenerated coverage shim and embedded srcs, adding bogus and duplicate\nrecords.\n- Files with nothing to cover still get an `SF:` record with `LF:0`, so\nthe set of files in the report is unchanged. The zero is now measured\nrather than assumed.\n- cgo files get baselines like any other source. `compilepkg`\ninstruments them before cgo rewrites them, so a measured run reports\npositions in the unprocessed file, which are the ones this action reads\nback.\n- The action is path mapped under exactly the condition `compilepkg`\nuses, and skips it for cgo and for targets tagged `local`. The two have\nto agree, since a generated source under\n`--experimental_output_paths\u003dstrip` would otherwise get a stripped path\nin the baseline and an unstripped one from the compile action, leaving\nthe zeros in a record measured data never displaces.\n\nThis is guarded on\n`bazel_features.rules.instrumented_files_info_has_baseline_coverage_files`,\nand no dependency bump is needed since the current 1.36.0 pin already\nhas that flag. On Bazel 7 and 8 the kwarg isn\u0027t passed and behaviour is\nunchanged. The `polyfill_bazel_features.bzl` value is a constant\n`False`, since Bazel 9 is also the release that removed WORKSPACE\nsupport.\n\nNothing runs on ordinary builds. The action is gated on\n`go.coverage_enabled` and `go.coverage_instrumented`, so\n`--instrumentation_filter` is respected too.\n\nThe `go_bazel_test` covers an untested library, an untested binary, an\nuntested cgo library, a declaration-only file, a build-constrained file,\nand that measured coverage isn\u0027t displaced. It runs in CI on the Bazel 9\nlegs, and on Bazel 8 the `bazel_features` gate makes it incompatible so\na `//...` pattern skips it. A unit test covers the profile reader. I\nalso ran this across a ~680-file Go monorepo: same set of files in the\nreport, measured coverage byte-identical, and 21 files that had been\nreporting 100% now report 0%.\n\n---------\n\nCo-authored-by: Logan Rosen \u003cloganrosen@users.noreply.github.com\u003e\nCo-authored-by: Copilot App \u003c223556219+Copilot@users.noreply.github.com\u003e\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "975884f705a9721a3c39bad4033852b0b795a3ce",
      "tree": "7782acabed60560222031428a96ad705d99f4411",
      "parents": [
        "f6afe7478c645595839adc211644e6e5474d9fd3"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Thu Sep 03 18:29:06 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Sep 03 18:29:06 2026 +0200"
      },
      "message": "Reset request_nogo to its default value in the stdlib transition (#4705)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\n`go_stdlib_transition` resets `//go/private:request_nogo` to `False`\nalong with the other tool settings. The standard library never runs\nnogo, though, so the only effect of that reset is to move\n`@io_bazel_rules_go//:stdlib` into a configuration of its own: neither\nthe configuration of a target built with default settings (e.g. a plain\n`bazel build //some:go_binary`) nor that of a tool built via a plain\nexec transition (e.g. a genrule tool) has the setting set.\n\nThat separate configuration isn\u0027t free: every Go rule resolves the C++\ntoolchain, so the toolchain and everything it depends on are analyzed\nand, for toolchains that build runtimes from source, built once more.\nSince `GoStdlib` takes the toolchain files as inputs, that duplicate\nbuild also sits in front of every Go compilation on the critical path of\na cold build. In a build of BuildBuddy\u0027s executor on macOS with a\nhermetic LLVM toolchain, this is a second from-source build of\ncompiler-rt (281 C compiles) on both the target and the exec side.\n\nThis resets the setting to its default value (`True`) instead of the\ntool value. With that, the stdlib of a target built with default\nsettings shares the target\u0027s configuration, and the stdlib of nogo\n(whose own configuration has `request_nogo \u003d False`) shares the\nconfiguration of plain exec tools rather than keeping one of its own.\nThere is no cycle risk: the stdlib rule only depends on `//:go_config`\nand the toolchains, none of which reach nogo.\n\nThe same reasoning applies to two more places that set `request_nogo \u003d\nFalse` for targets that never run nogo, and the follow-up commits fix\nthose too so that a default build has no configuration forks left at\nall:\n\n* `non_go_tool_transition` inherited the value from the dict it shares\nwith `go_tool_transition`, which gave the builder, pack, the legacy\nprotoc toolchain and every `proto_library` a `go_proto_library` depends\non a configuration of their own.\n* `go_context_data` transitioned its `coverdata` dependency, a\n`go_tool_library`, which moved coverdata, the C++ toolchain it resolves\nand the Go SDK targets of its toolchain into a configuration of their\nown, once on the target and once on the exec side. The transition dates\nback to #4016 and was also relied on by `cgo_context_data` (#4512),\nwhich has since been removed (#4599).\n\n**Which issues(s) does this PR fix?**\n\nNone filed.\n\n**Other notes for review**\n\n* Two tests for the stdlib, one per claim. On #4704 alone they fail with\n`no stdlib is built in the configuration of //:plain, the stdlib\nconfigurations differ from it in: private:request_nogo\u003dnull vs false`\nand `a stdlib reachable from //:tool_user is not built in the\nconfiguration of //:plain, differing in: private:request_nogo\u003dnull vs\nfalse`.\n* A new test verifies the general property: every target reachable from\na Go binary or from a genrule tool is built in the target configuration,\nthe exec configuration or the configuration of nogo. On the first commit\nalone it fails with `121 targets are built in a configuration that\ndiffers from the exec configuration in private:request_nogo\u003dnull vs\nfalse: @io_bazel_rules_go//go/tools/coverdata:coverdata,\n@go_sdk//:pack.exe, @go_sdk//:builder, ...` and the corresponding\nmessage for the target configuration.\n* `static_runtime_lib_inputs_test` expected the C++ runtime archive\ntwice among the link inputs, once per configuration of the binary and\nits stdlib. With both in one configuration there is a single copy, which\nis what the test asserts now; `stdlib_runtime_lib_inputs_test` still\ncovers the two-configuration case via a tag the stdlib transition drops.\n* The test helper that reports differing settings now also covers\n`//go/private` settings (prefixed with `private:`), since that is the\npackage the difference lives in."
    },
    {
      "commit": "f6afe7478c645595839adc211644e6e5474d9fd3",
      "tree": "4aa7de97daf8b08150495ddf340cd410d3efc30b",
      "parents": [
        "02f12da8acee31a8d39e88b50819eb3cc98f4fd1"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Thu Sep 03 12:04:41 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Sep 03 12:04:41 2026 +0200"
      },
      "message": "Reset linkmode to its default value in tool transitions (#4704)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\n`go_tool_transition` and `non_go_tool_transition` reset\n`//go/config:linkmode` to `\"normal\"`, but the flag\u0027s default is\n`\"auto\"`, thus resulting in unnecessary config forking.\n\n**Which issues(s) does this PR fix?**\n\n**Other notes for review**"
    },
    {
      "commit": "02f12da8acee31a8d39e88b50819eb3cc98f4fd1",
      "tree": "2e3a7deb3e727cb2745aacc1652b98f282d1d157",
      "parents": [
        "3798bb5f3bbb61e36285705ab12d8b2aa78cf2cd"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Wed Sep 02 23:08:59 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Sep 02 23:08:59 2026 +0200"
      },
      "message": "Apply the static attribute at link time instead of via a transition (#4706)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nThe `static` attribute of `go_binary` and `go_test` only affects how the\nbinary itself is linked (`-extldflags -static` and the choice of\nexternal linking in `emit_link`), but `go_transition` turned it into a\nsetting that every dependency was configured with. Consequences:\n\n* A binary with `static \u003d \"on\"` compiled a private copy of all of its\ndependencies, plus nogo runs for all of them.\n* Two binaries that only differed in this attribute landed in two\nconfigurations.\n* The bookkeeping settings `//go/config:static` and `original_static`\nleaked into every non-Go dependency reached from such a configuration,\nincluding the C++ toolchain and its runtime deps.\n\nThis drops `static` from the transition and instead reads the attribute\nin `go_context`, which exposes the effective value as `go.static_link`\n(the attribute applied on top of the `//go/config:static` flag).\n`emit_link` uses that instead of `go.mode.static`. `mode` is\ndeliberately left alone since it describes how archives are compiled,\nand the archive consistency check compares it across dependencies.\n\nCommand-line uses of `--@io_bazel_rules_go//go/config:static` are\nunaffected, and Go tool binaries keep inheriting that value (#4689).\n\n**Which issues(s) does this PR fix?**\n\n\n**Other notes for review**"
    },
    {
      "commit": "3798bb5f3bbb61e36285705ab12d8b2aa78cf2cd",
      "tree": "43ed47b02860f827272c3892a661ab484323455e",
      "parents": [
        "c5006c2591367369f167d1aeb62d1ed0049ae9e0"
      ],
      "author": {
        "name": "Keith Smiley",
        "email": "keithbsmiley@gmail.com",
        "time": "Tue Sep 01 00:41:06 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Sep 01 09:41:06 2026 +0200"
      },
      "message": "Add missing bsd platform constraints (#4703)\n\nThese are already handled in other lookup tables but were missing here"
    },
    {
      "commit": "c5006c2591367369f167d1aeb62d1ed0049ae9e0",
      "tree": "1f7c9293f2017bf20cdcc95e04921499122474df",
      "parents": [
        "895b6e4454e0e28ce011771857f42852f115c4c7"
      ],
      "author": {
        "name": "janantharaj",
        "email": "95314735+janantharaj@users.noreply.github.com",
        "time": "Mon Aug 31 09:47:22 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Aug 31 18:47:22 2026 +0200"
      },
      "message": "Bump golang.org/x/tools to v0.48.0 for Go 1.27 nogo compatibility (#4701)\n\n\u003c!-- Thanks for sending a PR! Before submitting:\n\n1. If this is your first PR, please read CONTRIBUTING.md and sign the\nCLA\n   first. We cannot review code without a signed CLA.\n2. Please file an issue *first*. All features and most bug fixes should\nhave\nan associated issue with a design discussed and decided upon. Small bug\n   fixes and documentation improvements don\u0027t need issues.\n3. New features and bug fixes must have tests. Documentation may need to\nbe updated. If you\u0027re unsure what to update, send the PR, and we\u0027ll\ndiscuss\n   in review.\n4. Note that PRs updating dependencies and new Go versions are not\naccepted.\n   Please file an issue instead.\n--\u003e\n\n**What type of PR is this?**\nBug fix\n\n**What does this PR do? Why is it needed?**\nCurrently, when using Go 1.27.0 in rules_go `v0.63.0`, nogo fails with\nthe following error:\n\n```\nnogo: nogo: error running analyzers: 2 analyzers skipped due to type-checking error: external/gazelle++go_deps+com_github_aws_aws_sdk_go/internal/sync/singleflight/singleflight.go:9:8: could not import sync (internal error in importing \"sync\" (cannot decode \"sync\", export data version 4 is greater than maximum supported version 2); please report an issue)\n```\n\nThis is caused by a downstream dependency on `x/tools`, which only\nsupports `export data version 4`. Bumping to `v0.48.0` fixes the issue.\n\n**Test**\n1. I added a simple `local_path_override` with the changes in this PR to\nan external repository which depends on rules_go. Previously, I was\nencountering the error mentioned above, and now nogo successfully\npasses.\n2. `bazel test //tests/core/nogo/...` passes.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4681\n\n**Other notes for review**\n\n---------\n\nCo-authored-by: Jeremy Anantharaj \u003cjanantharaj@anduril.com\u003e"
    },
    {
      "commit": "895b6e4454e0e28ce011771857f42852f115c4c7",
      "tree": "84acab05e692e7aeea2642dc95c0b11c0ceca69a",
      "parents": [
        "60711bd746cdb62052ff94fea239c0dc6a96e6a1"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Wed Aug 26 12:56:53 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Aug 26 10:56:53 2026 +0000"
      },
      "message": "Preprocess PGO profiles in a separate action (#4684)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nrules_go hands the pprof profile to the compiler as\n`-gcflags\u003dall\u003d-pgoprofile\u003d\u003craw\u003e`. That bypasses the preprocessing the\n`go` command performs for its own `-pgo` flag, so every compiler\ninvocation parses the profile and builds the PGO call graph from\nscratch. `GoStdlib` runs one compiler per CPU inside a single action,\nand every `GoCompilePkg` action repeats the work, so peak memory scales\nwith the core count of whatever machine the action lands on. A single\n`GoStdlib` action has been observed peaking at \u003e60 GB.\n\nThis PR converts the profile once with `go tool preprofile` in a new\n`GoPreprofile` action and hands the result to every compile action.\n\n`go tool preprofile` was added in Go 1.23. Below that the profile is\npassed through untouched and behaviour is exactly as before.\n\n**Which issues(s) does this PR fix?**\n\n**Other notes for review**"
    },
    {
      "commit": "60711bd746cdb62052ff94fea239c0dc6a96e6a1",
      "tree": "ff64b28e1a2cf6a44f59c983d6bb3286e441ae69",
      "parents": [
        "885b3e5958e6b4a2652376bf361259a54cdd4fab"
      ],
      "author": {
        "name": "Régis Desgroppes",
        "email": "regis.desgroppes@datadoghq.com",
        "time": "Mon Aug 24 23:11:53 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Aug 24 23:11:53 2026 +0200"
      },
      "message": "link: preserve checksum qualifier from golang PURLs (#4700)\n\n**What type of PR is this?**\n\nFeature\n\n**What does this PR do? Why is it needed?**\n\n`moduleFromPURL` discards everything from the first \u0027?\u0027 or \u0027#\u0027 onward,\nso a checksum qualifier on a `pkg:golang/...` PURL gets silently\ndropped.\n\nbazel-contrib/bazel-gazelle#2409 is meant to add such a qualifier to the\nPURLs it generates for `go_repository`, carrying the module\u0027s go.sum\n`h1:` checksum.\n\nParse qualifiers as a URL query string, extract checksum, and set it on\nthe resulting `Module`\u0027s `Sum` field, so a binary linked with this\nmetadata exposes the same checksum through `ReadBuildInfo()` that `go\nbuild` already sets for its own binaries.\n\nQualifier values are percent-decoded via `ParseQuery`, consistent with\nhow the module path and version are already percent-decoded.\n\n`buildInfoDeps`\u0027s dedup key and sort comparator both now include `sum`,\nso 2 independently-authored `packageMetadata` files that disagree on the\nchecksum for the same path and version are kept as distinct entries,\nrather than silently merged, matching the existing handling for other\nconflicting metadata.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4699.\n\n**Other notes for review**\n\nThis would not have been possible without #4595, thanks to @sluongng!"
    },
    {
      "commit": "885b3e5958e6b4a2652376bf361259a54cdd4fab",
      "tree": "121bee71d3079f6de129073e068ea39a5ba46e6d",
      "parents": [
        "fd0d9f834ac93f03c39ad32183d71524f4f3413d"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Sat Aug 22 00:35:42 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Aug 21 22:35:42 2026 +0000"
      },
      "message": "link: add main module to build info (#4694)\n\n**What type of PR is this?**\n\nFeature\n\n**What does this PR do? Why is it needed?**\n\nrules_go records dependency modules in `BuildInfo.Deps`, but leaves\n`BuildInfo.Main` empty even when package metadata identifies the module\nthat\nowns an executable. Build-info consumers therefore cannot report the\nmain\nmodule path and version.\n\nThis change passes two distinct values to the linker:\n\n- The executable package\u0027s import path populates `BuildInfo.Path`.\n- The Go PURL in its package metadata populates `BuildInfo.Main`.\n\nPackage metadata is kept unconditionally on `GoInfo` and archive data.\nAt link\ntime, the target metadata is selected as the main module and that module\npath\nis filtered from the candidate dependencies. This prevents a `go_test`\nbinary\nfrom reporting its own module in `BuildInfo.Deps` without a test-only\nsuppression flag or a duplicate provider field.\n\nThe new `go.binary` and `go.link` parameters are appended to preserve\npositional compatibility for custom Starlark rules. Tests cover ordinary\nbinaries, embedded main packages, test binaries, binaries without\nmetadata,\nand direct `go.archive` to `go.link` callers.\n\n**Which issue(s) does this PR fix?**\n\nNo linked issue.\n\n**Other notes for review**\n\nBuild-info stack:\n\n1. #4694 — add main-module build info (this PR)\n2. #4695 — add stamped VCS build info\n\nThe second draft is cumulative against `master` because both heads are\nfork-owned. It depends on this PR and is rebased after this PR changes.\n\nValidation:\n\n- `bazel --nohome_rc test //tests/...` — 467 passed, 1 Darwin-only test\nskipped\n- `bazel test //go/tools/builders:all\n//tests/core/go_binary:buildinfo_test\n//tests/core/starlark:package_metadata_test //tests:buildifier_test`\n- `bazel build //docs/...`\n- `bazel test //docs/...`\n- `git diff --check`"
    },
    {
      "commit": "fd0d9f834ac93f03c39ad32183d71524f4f3413d",
      "tree": "86f3707d1dd77709a022d3b49522949f17cf59d4",
      "parents": [
        "efc00860f5ec773680a04c39918ac8b6186e05ae"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Fri Aug 21 23:11:07 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Aug 21 23:11:07 2026 +0200"
      },
      "message": "Bump default Go SDK to 1.26.7 (#4697)\n\n**What type of PR is this?**\n\nOther\n\n**What does this PR do? Why is it needed?**\n\nAs per our informal update policy, bump the default Go SDK from 1.25.0\nto 1.26.7, which is the latest patch version of the oldest supported\nrelease.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4696\n\n**Other notes for review**"
    },
    {
      "commit": "efc00860f5ec773680a04c39918ac8b6186e05ae",
      "tree": "920adb856c2bb9d2a16c00a835ebbab8cdae7391",
      "parents": [
        "9792f1c079a7602347e0fd966542b6d6b35a6c64"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Wed Aug 19 13:53:10 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Aug 19 11:53:10 2026 +0000"
      },
      "message": "link: add build settings to build info (#4691)\n\n**What type of PR is this?**\n\nFeature\n\n**What does this PR do? Why is it needed?**\n\nrules_go build information omits the configuration that produced a\nbinary. `go version -m` and `runtime/debug` clients use these settings\nto distinguish binaries built for different modes, targets, and\ninstrumentation.\n\nRecord deterministic settings already known to the link action. Use the\nGo 1.20 `debug.BuildSetting` and `BuildInfo.String` APIs, filter tags\nadded internally for instrumentation, avoid deriving unknown `GOARM`\ndefaults from the execution platform, and emit ARM64 and RISC-V tuning\nonly for Go 1.23 or later.\n\nThis builds on #4690 and is deliberately limited to\n`BuildInfo.Settings`; main-module identity and VCS settings will be\nproposed separately.\n\n**Which issues(s) does this PR fix?**\n\nPart of #3090.\n\n**Other notes for review**\n\nNone."
    },
    {
      "commit": "9792f1c079a7602347e0fd966542b6d6b35a6c64",
      "tree": "ecaa04c54027948e5d4f0041790a8ad47c52227f",
      "parents": [
        "61f19291a2b92814f8ce21bfccf1665a4c008ba9"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Fri Aug 14 23:21:35 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Aug 14 21:21:35 2026 +0000"
      },
      "message": "link: add package path to build info (#4690)\n\n**What type of PR is this?**\n\nFeature\n\n**What does this PR do? Why is it needed?**\n\nBinaries built with rules_go leave `BuildInfo.Path` empty even though\nanalysis knows the main archive import path. `go version -m` and\n`runtime/debug` clients use this field to identify the main package, as\nthey do for binaries built with `cmd/go`.\n\nPass the main package import path to the linker and serialize it with\nGo 1.20\u0027s `debug.BuildInfo.String` API. Extend the builder and\nend-to-end tests to cover binaries with and without dependency metadata.\n\nThis builds on #4595 and is deliberately limited to `BuildInfo.Path`;\nmain-module identity and build settings will be proposed separately.\n\n**Which issues(s) does this PR fix?**\n\nPart of #3090.\n\n**Other notes for review**\n\nNone."
    },
    {
      "commit": "61f19291a2b92814f8ce21bfccf1665a4c008ba9",
      "tree": "6054f8a6e6a64a023e25037917db39f647876abe",
      "parents": [
        "352e2426c83de8dc257f573b068c641c587939e2"
      ],
      "author": {
        "name": "H5-O5",
        "email": "166461697+H5-O5@users.noreply.github.com",
        "time": "Fri Aug 14 08:55:41 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Aug 14 15:55:41 2026 +0000"
      },
      "message": "Treat TestMain as the test entry point only when it takes *testing.M (#4679)\n\n### What\u0027s wrong\n\n`go test` decides whether a function named `TestMain` is the package\nentry\npoint from its **signature**, not from its name: only `func TestMain(m\n*testing.M)` is the entry point that wraps the run. A `func TestMain(t\n*testing.T)` is an ordinary test that merely happens to be named\n`TestMain`\n(see\n[`cmd/go/internal/load/test.go`](https://github.com/golang/go/blob/master/src/cmd/go/internal/load/test.go),\nthe `TestMain` case of `testFuncs.load`, which checks `isTestFunc(n,\n\"T\")`\nbefore treating the function as a test).\n\n`genTestMain` keys off the name alone, so a package containing `func\nTestMain(t *testing.T)` has that function registered as the entry point\nand\nthe generated main calls it with an `*testing.M`:\n\n```\ncannot use m (variable of type *testing.M) as *testing.T value in argument to pkg.TestMain\n```\n\nSuch a package builds and tests fine under `go test`, but fails to build\nunder rules_go — so `go_test` is unusable for it. We hit this on a real\nrepository while moving its `go test` suite onto Bazel: the package\nbuilt\nunder `go test` and failed to compile under `go_test`, with an error\nthat\npoints at generated code rather than at the user\u0027s source.\n\n### The fix\n\nThe `TestMain` check sat *above* the signature checks that were already\nbeing made for `Test*`/`Benchmark*`/`Fuzz*`, so it had nothing but the\nname\nto go on. Move it below them and take that branch only when the sole\nparameter is `*\u003csomething\u003e.M`.\n\nA `TestMain` with a `*\u003csomething\u003e.T` parameter then falls through to the\n`Test*` case and is registered as an ordinary test; any other signature\nis\nskipped, as an unrecognized `Test*` shape already was. Nothing else\nmoves —\nthe existing checks and the tolerance for an aliased `testing` import\nare\nreused as they are.\n\n### Test\n\nAdds `tests/core/go_test:testmain_signature_test`: a package whose only\n`TestMain` takes a `*testing.T`. It fails to build before this change,\nand\nafter it, asserts that the function is actually run as an ordinary test.\nThe `*testing.M` entry point stays covered by the existing\n`only_testmain_test`.\n\n### Verification\n\nBoth directions were checked with:\n\n```\nbazel test //tests/core/go_test:testmain_signature_test \\\n           //tests/core/go_test:only_testmain_test\n```\n\n- **With this change:** both targets `PASSED` — the new fixture builds\nand\n  runs `TestMain(*testing.T)` as an ordinary test, and the existing\n  `*testing.M` entry-point case is unaffected.\n- **With `go/tools/builders/generate_test_main.go` reverted to its\nprevious\nversion and the new fixture kept:** `testmain_signature_test` is `FAILED\nTO\n  BUILD`, with exactly the error this PR fixes —\n\n  ```\ntestmain.go:132:13: cannot use m (variable of type *testing.M) as\n*testing.T value in argument to l.TestMain\n  ```\n\nconfirming the fixture is a genuine regression test rather than one that\n  would pass either way.\n\nFixes #4677.\n\n---\n\nDrafted with Claude Code.\n\nCo-authored-by: Claude Opus 5 (1M context) \u003cnoreply@anthropic.com\u003e\nCo-authored-by: Jay Conrod \u003cjay@engflow.com\u003e"
    },
    {
      "commit": "352e2426c83de8dc257f573b068c641c587939e2",
      "tree": "8b58dbef62948e64e00021506d02e4bed8c81a93",
      "parents": [
        "c63998608f97f5b98893443a3cfad26ef76c11d2"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Fri Aug 14 16:33:33 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Aug 14 14:33:33 2026 +0000"
      },
      "message": "link: add external deps to Go build info (#4595)\n\nBinaries built with rules_go omit Go module metadata from\n`runtime/debug.ReadBuildInfo().Deps` because package metadata never\nreaches the link action. Dependency inspection is therefore incomplete\nfor external and vendored packages.\n\nThread Gazelle-generated `PackageMetadataInfo` artifacts through\n`GoInfo` and `GoArchiveData`, add them as link inputs, and parse their\n`pkg:golang` PURLs in the builder. Emit the resulting modules as\ndep-only modinfo for supported build modes.\n\nPackage metadata is an action output, so parsing it at link time avoids\ntrying to expose its JSON contents through Starlark providers. Read\nmetadata from both `package_metadata` and `applicable_licenses` for\nBazel compatibility, ignore non-Go PURLs, normalize unprefixed semantic\nversions, preserve opaque versions such as commit hashes, and represent\nversionless modules as `(devel)`, matching `cmd/go` behavior. Metadata\npropagation also tolerates exported `GoArchive` values created without\nthe new private field.\n\nBuild information follows the declared Bazel dependency closure because\nthat graph is available during analysis. It may therefore include\nmetadata for a declared dependency whose Go package is not imported.\nPackage metadata also need not describe one MVS-resolved graph, so\ndistinct versions for the same module path are preserved rather than\nsilently selecting one.\n\nTarget-owned metadata is not reported as a dependency for either\n`go_binary` or `go_test`; test binaries retain metadata from their\ndeclared dependency closure. Coverage and non-coverage links use the\nsame metadata traversal while preserving the existing coverage archive\ndeduplication required to avoid duplicate coverdata packages.\n\nRebase onto current `master`, including the Go 1.20 minimum-version\nchange. Use Go 1.20-compatible `os` and `io` APIs throughout the touched\ncode and keep metadata lookup compatible with Bazel 7 and Bazel 9.\nReplace the direct `rules_license` dependency and Stardoc patch with\n`package_metadata` for both Bzlmod and WORKSPACE users.\n\nValidation:\n- `bazel --ignore_all_rc_files test --test_output\u003derrors\n//tests:buildifier_test //docs:docs_go_core_rules-difftest\n//tests/core/starlark:package_metadata_test\n//tests/core/starlark:applicable_licenses_test\n//tests/core/go_binary:buildinfo_test`\n- `USE_BAZEL_VERSION\u003d7.2.1 bazel --ignore_all_rc_files test\n--lockfile_mode\u003doff --test_output\u003derrors\n//tests/core/go_binary:buildinfo_test\n//tests/core/starlark:package_metadata_test\n//tests/core/starlark:applicable_licenses_test`\n- `USE_BAZEL_VERSION\u003d7.2.1 bazel --ignore_all_rc_files test\n--lockfile_mode\u003doff\n--@io_bazel_rules_go//go/toolchain:sdk_version\u003d1.20.14\n//go/tools/builders:buildinfo_test`\n- `bazel build //docs/... \u0026\u0026 bazel test //docs/...`\n- From `tests/bcr`: `bazel build --allow_yanked_versions\u003dall //...\n@go_default_sdk//... \u0026\u0026 bazel test --allow_yanked_versions\u003dall //...`"
    },
    {
      "commit": "c63998608f97f5b98893443a3cfad26ef76c11d2",
      "tree": "3fc99282374938bd3905c2695bf360077681feb9",
      "parents": [
        "630a02d4d62c2378c998e09169ed73031c870d73"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Fri Aug 14 15:33:54 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Aug 14 13:33:54 2026 +0000"
      },
      "message": "Inherit static and pure settings for Go tool binaries (#4689)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\n`go_tool_transition` resets all `//go/config` settings to their default\nvalues, so a value set on the command line never reaches Go tool\nbinaries such as `nogo`. Whether a binary has to be linked statically or\nwithout cgo is a property of the platform it runs on rather than of the\nparticular target the user requested, so when the execution platform can\nonly run statically linked binaries (a musl-only CI image being the\nreported case), those tools end up dynamically linked and fail.\n\nThis restores `//go/config:static` and `//go/config:pure` to the value\nthey had before the last `go_transition`, which is the value set on the\ncommand line. Values set by the `static` and `pure` attributes of an\nindividual rule are still reset, so tools continue to be built in a\nsingle configuration no matter how many distinct attribute values the\nbuild contains. That is the difference to the workaround in #4378, which\ndrops the keys from `_reset_transition_dict` entirely and therefore\nbuilds one copy of every tool per attribute value.\n\n`non_go_tool_transition` keeps the full reset: how a Go binary is linked\nis irrelevant for a tool that isn\u0027t one, and Go proto plugins go through\n`go_reset_target` rather than `non_go_tool_transition`, so `protoc` and\n`proto_library` stay in a single configuration regardless of the Go\nsettings.\n\nBoth settings and their `original_*` shadow settings are scoped as\n`universal` so that they keep reaching tools under\n`--incompatible_exclude_starlark_flags_from_exec_config` (default in\nBazel 10). Both halves are required: with the scope missing on a shadow\nsetting, the value propagates into the exec configuration while the\nshadow setting resets, `go_tool_transition` can no longer tell a value\nset on the command line from one set by a rule attribute, and the\nattribute leaks into the tool configuration.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4378\n\n**Other notes for review**\n\n`--@rules_go//go/config:static` now applies to exec-configured Go tools,\nwhich seems right to me and can also be overridden via `flags` on\n`platform`."
    },
    {
      "commit": "630a02d4d62c2378c998e09169ed73031c870d73",
      "tree": "7dbdc3c10d125fd07e521135ff59cc85323ac739",
      "parents": [
        "8b7f66963ba806bc58bdaf5171b3375c2eb9a3e9"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Fri Aug 14 12:47:01 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Aug 14 10:47:01 2026 +0000"
      },
      "message": "ci: test with Bazel 8 and 9 via a matrix (#4670)\n\nThe main build and test tasks only ran with the default Bazel version\nfrom\n`.bazelversion`; only the BCR test module was exercised against 8.x and\n9.x.\nThis expands them over the existing `bazel` matrix and makes 9.2.0 the\ndefault,\nwhich turned up a fair amount of fallout.\n\n### CI\n\n* Ubuntu, macOS and Windows run the full suite on Bazel 8 and 9. Bazel 7\nkeeps\n  the minimum version task.\n* Stardoc\u0027s output depends on the Bazel version, so the docs are\ngenerated for\n  the default version and their diff tests moved to a dedicated task.\n\n### Bazel 9 compatibility\n\n* Load `CcInfo` and `CcToolchainConfigInfo` from rules_cc, return\nproviders\ninstead of a struct from a rule implementation, and load the native cc,\njava\n  and shell rules where fixtures use them.\n* `//go/toolchain:windows_amd64_cgo` listed both mingw constraint\nvalues, which\nbecame the same value in Bazel 8 and crashes Bazel 9. Pick the one\nmatching\n  where `@local_config_cc` comes from.\n* `objc_library` needs the Apple CC toolchain to be selected through\ntoolchain\n  resolution; the `--*crosstool_top` flags no longer do anything.\n* A cross-compiled test can\u0027t satisfy the default test toolchain Bazel 9\nadded,\n  and `filegroup` now forwards the runfiles of its srcs.\n\n### Bzlmod\n\nBazel 9 removed WORKSPACE, so `go_bazel_test` always generates a\nMODULE.bazel\nfile and the WORKSPACE template is gone. Targets that only resolved\nbecause\nWORKSPACE was still enabled on Bazel 7 declare their repositories\nthrough\nBzlmod, including the maintainer tools\u0027 dependencies and module\nextensions for\nthe generated test repositories.\n\nRepository names reach the fixtures differently as a result: `bazel\ninfo`\ndoesn\u0027t apply the main repository mapping to labels on the command line,\nso the\nplatform in `GO_BAZEL_TEST_BAZELFLAGS` is spelled canonically, and the\ncanonical\nname separator differs between Bazel 7 and later, which two tests assert\non.\n\n### Toolchains\n\n* Take protoc from the prebuilt toolchains protobuf ships rather than\nbuilding\nit from source, which is slow and fails on Windows. protobuf is pinned\nfor\nthis repository only, so the version users get is unchanged.\n`//proto:protoc`\n  is tagged manual for the same reason.\n* Take buildifier from `buildifier_prebuilt`.\n\n### Not covered\n\n* `--incompatible_auto_exec_groups` is disabled: protobuf\u0027s protoc\nauthenticity\ncheck calls `ctx.actions.run_shell` without a toolchain, and proto\ntoolchain\n  resolution is the default as of Bazel 9, so the two can\u0027t be combined.\n* `debian11_zig_cc` runs on Bazel 8: hermetic_cc_toolchain releases that\nwork\nwith Bazel 9 require a rules_cc that Bazel 7 cannot load. The zig\ntoolchain\nalso can\u0027t load shared libraries at runtime, so a few tests are skipped\nthere.\n* `rbe_ubuntu2404` runs on Bazel 7: `GoCompilePkg` declares an output\ndirectory\nfor the cgo-generated sources that stays empty when cgo is enabled on a\npackage that doesn\u0027t use it, and the remote executor doesn\u0027t report\nempty\n  output directories (bazelbuild/bazel#28286).\n* A few tests are skipped on Windows: they build protobuf from source,\nwhose\nprotoc the mingw toolchain links against a DLL that isn\u0027t resolvable\nwhen\nBazel runs it as a build tool, or they assert on the repository\ndirectory\n  name."
    },
    {
      "commit": "8b7f66963ba806bc58bdaf5171b3375c2eb9a3e9",
      "tree": "772602031e230977a2c21403aa8870e5d2f06591",
      "parents": [
        "9fb5d2b23e9a008d4d4d96d7fd210624e98dedd0"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Thu Aug 13 20:42:59 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Aug 13 20:42:59 2026 +0200"
      },
      "message": "go: require Go 1.20 or later (#4675)\n\nReview feedback on #4666 asked whether a Go 1.20 floor would let\nrules_go shed more old-version support. Go 1.18 and Go 1.19 are no\nlonger supported upstream, and advertising them retains compatibility\nbranches and tests that current releases do not need.\n\nRaise the minimum SDK and use Go 1.20 when go_sdk.from_file reads a\ngo.mod or go.work file without a version directive. Refresh the\ndocumentation and SDK-selection fixtures, then remove the pre-Go 1.19\nassembler detection, pre-Go 1.20 standard-library branches, and build\ntags that disappeared before Go 1.20.\n\nKeep the Go 1.20 nogo version normalization because go/types still\nrequires it until Go 1.21. Preserve the existing policy of warning,\nrather than failing, when an older SDK is explicitly selected. Continue\nhonoring precompiled standard libraries exposed through GoSDK.libs."
    },
    {
      "commit": "9fb5d2b23e9a008d4d4d96d7fd210624e98dedd0",
      "tree": "aa4078fbaf588a76fa59c7a9a29831b5592b6a91",
      "parents": [
        "9037229852959576ad1f3aad39c835ff79011950"
      ],
      "author": {
        "name": "Fionera",
        "email": "fionera@fionera.de",
        "time": "Wed Aug 05 17:35:43 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Aug 05 08:35:43 2026 -0700"
      },
      "message": "Introduce `[\"all\"]` scope for nogo (#4678)\n\n**What type of PR is this?**\nFeature\n\n**What does this PR do? Why is it needed?**\n\n**Which issues(s) does this PR fix?**\n\nWork towards https://github.com/bazel-contrib/rules_go/issues/4241 and\nbe a rebased version of #4277\n\n**Other notes for review**\n\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "9037229852959576ad1f3aad39c835ff79011950",
      "tree": "d80171278a93b516c77c84f8f8ca945ef883e423",
      "parents": [
        "0c5b01e9f72cfc4f1c0c81bb20070f3e8cf74af6"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Sun Aug 02 04:43:40 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sun Aug 02 10:43:40 2026 +0200"
      },
      "message": "go: preserve race mode for go_source rules (#4674)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\n`go_source` calls `go_context(..., maybe_needs_cc_toolchain \u003d False)`\nand intentionally does not declare a C/C++ toolchain. `go_context` still\ntreated the undeclared toolchain as unavailable, forced pure mode, and\nrejected race instrumentation. Preserve the configured mode for rules\nthat opt out and do not declare the C/C++ toolchain while retaining\nmissing-toolchain validation for normal Go rules. Add race-mode\nregression coverage for both standalone `go_source` and an embedding\n`go_library`.\n\n**Which issue(s) does this PR fix?**\n\nFixes #4673\n\n**Other notes for review**\n\nValidated with:\n\n```\nbazel test --jobs\u003d2 --local_test_jobs\u003d1 //tests/core/race:race_test //tests/core/starlark/cgo:missing_cc_toolchain_explicit_pure_off_test\n```"
    },
    {
      "commit": "0c5b01e9f72cfc4f1c0c81bb20070f3e8cf74af6",
      "tree": "b05932b128063d1888a8048f80397af9f4926b45",
      "parents": [
        "5a7613d15a801fa4eb0ac89cb858b4fd810b9dcc"
      ],
      "author": {
        "name": "Fionera",
        "email": "fionera@fionera.de",
        "time": "Fri Jul 31 11:01:38 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Jul 31 11:01:38 2026 +0200"
      },
      "message": "Build Go SDK file attrs in the exec configuration (#4650)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nThe experimental source-bootstrapped SDK\n(`experimental_bootstrap_go_sdk`) emits the `go` binary, the tool\nbinaries, and the GOROOT `src`/`pkg` layout from a generated bootstrap\ntarget. `go_tool_binary` runs the SDK\u0027s `go` binary in the exec\nconfiguration — the `go` and `tools` attrs of `go_sdk` are already `cfg\n\u003d \"exec\"` — so that binary infers `GOROOT` from its own exec-config\npath.\n\nThe remaining SDK file attrs (`root_file`, `libs`, `headers`, `srcs`)\nhad no configuration set, so Bazel supplied them under the target-config\npath. When those inputs don\u0027t sit under the exec-config `GOROOT` the\n`go` binary derives from its own location, the Go command can\u0027t find\nstandard-library packages such as `cmd/pack`, and the bootstrap builder\nbuild fails.\n\nThis pins `root_file`, `libs`, `headers`, and `srcs` to `cfg \u003d \"exec\"`\nso the whole SDK layout lands in one consistent configuration alongside\n`go` and `tools`. `package_list` is intentionally left unpinned: it is a\ngenerated list of standard-library import paths whose contents do not\ndepend on the configuration.\n\n**Which issues(s) does this PR fix?**\n\nSmall bug fix in the experimental bootstrap SDK — no associated issue.\n\n**Other notes for review**\n\nThis only changes how the `go_sdk` rule\u0027s own inputs are configured. For\nthe normal downloaded SDK these attrs point at static source files, so\nthey resolve to the same artifacts regardless of the transition; the fix\nmatters for the bootstrap SDK, where the layout is generated and would\notherwise be produced under the target configuration while `go` runs\nunder the exec one."
    },
    {
      "commit": "5a7613d15a801fa4eb0ac89cb858b4fd810b9dcc",
      "tree": "ae9360c7a7742a49e0042604c3aa0d9499a40364",
      "parents": [
        "cb284595377ca655c3f825c6cafafa260fb52012"
      ],
      "author": {
        "name": "Keith Smiley",
        "email": "keithbsmiley@gmail.com",
        "time": "Thu Jul 30 19:32:29 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Jul 31 02:32:29 2026 +0000"
      },
      "message": "Disable path mapping for stdlib actions with cgo (#4667)"
    },
    {
      "commit": "cb284595377ca655c3f825c6cafafa260fb52012",
      "tree": "e813dad23cbf7480a7183df654bee49c0b6aaa05",
      "parents": [
        "1f1eb5f5d9f9bcb7b06fc2e5c97a983c250e0331"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Thu Jul 30 07:55:51 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Jul 30 11:55:51 2026 +0000"
      },
      "message": "go: restore go_rule for custom Go rules (#4672)\n\n## Summary\n\nrules_go v0.62.0 requires rules that compile or link Go code with cgo to\ndeclare the optional C++ toolchain, Apple and C++ configuration\nfragments, and cgo attributes. Add a helper to define such rules\nergonomically.\n\nFixes #4662."
    },
    {
      "commit": "1f1eb5f5d9f9bcb7b06fc2e5c97a983c250e0331",
      "tree": "767ab05f4f5329fc89a735382f72302ce1c2006f",
      "parents": [
        "d51ee29eef619bd836f74e7bce9faa539c52a557"
      ],
      "author": {
        "name": "Keith Smiley",
        "email": "keithbsmiley@gmail.com",
        "time": "Tue Jul 28 23:26:25 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Jul 29 08:26:25 2026 +0200"
      },
      "message": "Use -ffile-prefix-map for reproducibility (#4671)\n\nFixes `__FILE__` macros being non-hermetic\n\nSupported since clang 10 (April 2020) and gcc 8 (May 2018)\n\nFixes https://github.com/bazel-contrib/rules_go/issues/4577"
    },
    {
      "commit": "d51ee29eef619bd836f74e7bce9faa539c52a557",
      "tree": "98ca2230ecc058af902a55fe3dac20331bffcec9",
      "parents": [
        "407f9f342d76884ba8cf97a4a678b8ddf9a2e80a"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Tue Jul 28 14:36:16 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Jul 28 14:36:16 2026 +0200"
      },
      "message": "go: require Go 1.18 or later (#4666)\n\nBecause maintainers no longer support Go SDKs older than 1.18,\nrules_go should not advertise Go 1.14 as its minimum. The old floor\nleaves obsolete version branches and tests in paths that every build\nmust carry.\n\nRaise the minimum and floor SDK selection for directive-less `go.mod`\nfiles at Go 1.18. Update SDK tests and documentation, and remove\npre-1.18 builder, test-main, assembly, embed, and nogo shims while\nretaining behavior required by Go 1.18 through Go 1.20.\n\nThe Go 1.18 through Go 1.20 `go/types` normalization and pre-Go 1.19\nassembler behavior remain version-gated. Building the complete `nogo`\nbinary with Go 1.18 is separately blocked by the repository\u0027s existing\n`x/tools` dependency, whose current sources require newer Go APIs and\nsyntax."
    },
    {
      "commit": "407f9f342d76884ba8cf97a4a678b8ddf9a2e80a",
      "tree": "ecc0b30df5ea576e4389a3c787ce23fc57c29747",
      "parents": [
        "4f78f635bddb6ce1b09145f9341bc15ee8c13d53"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Fri Jul 24 11:50:07 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Jul 24 09:50:07 2026 +0000"
      },
      "message": "Simplify the release process (#4661)\n\n\u003c!-- Thanks for sending a PR! Before submitting:\n\n1. If this is your first PR, please read CONTRIBUTING.md and sign the\nCLA\n   first. We cannot review code without a signed CLA.\n2. Please file an issue *first*. All features and most bug fixes should\nhave\nan associated issue with a design discussed and decided upon. Small bug\n   fixes and documentation improvements don\u0027t need issues.\n3. New features and bug fixes must have tests. Documentation may need to\nbe updated. If you\u0027re unsure what to update, send the PR, and we\u0027ll\ndiscuss\n   in review.\n4. Note that PRs updating dependencies and new Go versions are not\naccepted.\n   Please file an issue instead.\n--\u003e\n\n**What type of PR is this?**\n\nWorkflows\n\n**What does this PR do? Why is it needed?**\n\nFor regular releases, we use the stock Publish to BCR workflow: push a\ntag on current master to trigger the flow.\n\nThis makes it possible to disable the legacy Publish to BCR app and\nremove a bunch of code from the releaser, which now only retains the\nlogic to upgrade dependencies.\n\n**Which issues(s) does this PR fix?**\n\n**Other notes for review**\n\n---------\n\nCo-authored-by: Tyler French \u003cfrench.tyler.d@gmail.com\u003e"
    },
    {
      "commit": "4f78f635bddb6ce1b09145f9341bc15ee8c13d53",
      "tree": "39ab88f186c2dbf1177d2e4eed64d64edebd71d0",
      "parents": [
        "c6b35c2367d164f27af4825422d5c70c3365f6fb"
      ],
      "author": {
        "name": "Bryce Lampe",
        "email": "brycelampe@gmail.com",
        "time": "Thu Jul 23 23:16:43 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Jul 24 08:16:43 2026 +0200"
      },
      "message": "fix: respect path mapping for custom SDKs (#4663)\n\nWhen a custom SDK is provided, the flag is passed as a raw string so\n`--experimental_output_paths` can\u0027t strip it. The fix is similar to the\nexisting goroot handling (#4441).\n\nAlso add a test suite that aqueries with and without\n`--experimental_output_paths\u003dstrip` to lock in the behavior."
    },
    {
      "commit": "c6b35c2367d164f27af4825422d5c70c3365f6fb",
      "tree": "3bd565ee2483a8f2d2f48787d587b609d234814f",
      "parents": [
        "55b11d018debf710fe462a3318acb5ebfa52458b"
      ],
      "author": {
        "name": "Fabian Meumertzheim",
        "email": "fabian@meumertzhe.im",
        "time": "Tue Jul 21 16:16:44 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Jul 21 14:16:44 2026 +0000"
      },
      "message": "Revert \"Preserve common Go settings in go_stdlib_transition\" (#4658)\n\nReverts bazel-contrib/rules_go#4637"
    },
    {
      "commit": "55b11d018debf710fe462a3318acb5ebfa52458b",
      "tree": "728b1af7fef46f552ff2a2c83dd3098e24b8278b",
      "parents": [
        "442b400f8fc112ef2b26005a655043b53240b0cf"
      ],
      "author": {
        "name": "zbarsky-openai",
        "email": "zbarsky@openai.com",
        "time": "Sun Jul 19 15:10:13 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sun Jul 19 21:10:13 2026 +0200"
      },
      "message": "go: carry stdlib cgo link inputs into GoLink (#4657)\n\n**What type of PR is this?**\nBug fix\n\n**What does this PR do? Why is it needed?**\nruntime/cgo records CGO_LDFLAGS from the configuration used to build\nGoStdLib in package metadata. go_stdlib_transition intentionally filters\nirrelevant build tags and disables coverage, so a later GoLink action\nmay run in a different configuration.\n\nWhen a C++ toolchain\u0027s linker flags refer to generated runtime files,\nthe recorded flags point to the stdlib configuration\u0027s files. GoLink\nonly declared its own configuration\u0027s C++ toolchain files, so sandboxed\nlinks failed with an undeclared input.\n\nStore the stdlib configuration\u0027s cgo link inputs on GoStdLib and add\nthem to GoLink. This keeps the transition\u0027s stdlib sharing behavior\nwhile declaring the files whose paths may be replayed.\n\nAdd an analysis test with a generated C++ runtime archive and a build\ntag filtered by go_stdlib_transition. The test fails before this change\nbecause GoLink sees only one configured archive, and passes when both\ninputs are declared.\n\n\n**Which issues(s) does this PR fix?**\n\nFixes #\n\n**Other notes for review**"
    },
    {
      "commit": "442b400f8fc112ef2b26005a655043b53240b0cf",
      "tree": "ef6a35cbccca50931299f4c6ce21df5c246c1293",
      "parents": [
        "7fb2bde0fb988e41e137332b2cee1d65b21bdc71"
      ],
      "author": {
        "name": "Richard Lavoie",
        "email": "lavoie.richard@gmail.com",
        "time": "Fri Jul 17 16:34:07 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Jul 17 22:34:07 2026 +0200"
      },
      "message": "Add tests for cgo ldflags response-file encoding for Go 1.27 (#4656)\n\nThis adds tests for the cgo argfile change for GCC compatible file\nparser in 1.27+\n\nBonus: fixes a toolchain constraint issue for windows"
    },
    {
      "commit": "7fb2bde0fb988e41e137332b2cee1d65b21bdc71",
      "tree": "469cdca71554f21adf067bf7ed41fe662909002a",
      "parents": [
        "136dc5cbd011fe5efe053dd291cd23148d424e7d"
      ],
      "author": {
        "name": "ericsalo",
        "email": "93227906+ericsalo@users.noreply.github.com",
        "time": "Thu Jul 16 02:19:09 2026 -0500"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Jul 16 07:19:09 2026 +0000"
      },
      "message": "Add dedicated load files for go_binary(), go_library(), go_test() (#4655)\n\nas alternates to def.bzl. This tremendously simplifies migration to and\nfrom other environments which expect the same separation and brings Go\nin line with common practice for other languages (for example,\nrules_python does this).\n\n**What type of PR is this?**\n\nFeature\n\n**What does this PR do? Why is it needed?**\n\nIt\u0027s a nice quality-of-life for amphibian developers.\ngo_binary() and go_library() and go_test() now each have their own\nseparate .bzl files (in addition to def.bzl).\n\n**Which issues(s) does this PR fix?**\n\nFixes #4654\n\n**Other notes for review**\n\nThese are all just one-liners which happen to wrap the same functions in\ngo/private/ that are already wrapped by def.bzl, so they are a parallel\n(if trivial) code path. We could also be slightly more intrusive by\ndefining them to be the new SoT and redirecting def.bzl to point to them\ninstead."
    },
    {
      "commit": "136dc5cbd011fe5efe053dd291cd23148d424e7d",
      "tree": "fadd07a06e438eb3acd36071e4b9d717ff48da3d",
      "parents": [
        "0336744add8c620802ba450ca205956299d60052"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Thu Jul 16 08:41:30 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Jul 16 02:41:30 2026 -0400"
      },
      "message": "compilepkg: skip duplicate cgo compile (#4645)\n\nCoverage+cgo packages currently spend extra CPU in compilepkg because\nnogo needs original cgo-generated Go sources, not the\ncoverage-instrumented files passed to the compiler. The old path called\ncgo2 a second time to produce those sources. That second call also\nrecompiled every generated and user C-family source, linked the cgo\nprobe, and ran dynimport even though compilepkg discarded the object\noutputs.\n\nSplit cgo source generation from the compile/link phase and add a\ngenerate-only path for the nogo copy. Normal cgo compilation still uses\nthe full path, while the coverage+nogo pass writes generated Go sources\nfrom a separate cgo_nogo work directory and reuses the real\n_cgo_imports.go when available."
    },
    {
      "commit": "0336744add8c620802ba450ca205956299d60052",
      "tree": "5792c45a9a1d46c4fb5326241fce55d74dc389f7",
      "parents": [
        "abcc50a5f92f2454c5e5d2632cfd4d96717e98cc"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Sat Jul 04 05:19:44 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Jul 04 03:19:44 2026 +0000"
      },
      "message": "builders: filter test sources in place (#4646)\n\nLarge compilepkg and nogo actions can run test filtering after\nreadFileInfo has attached AST, import, and embed metadata to every Go\nsource. This matters because each discarded fileInfo may retain parser\nstate for a source file.\n\nThe old only and exclude modes allocated a second fileInfo slice. That\nincreased short-lived memory use and kept discarded metadata reachable\nlonger than needed.\n\nCompact the Go source slice in place for test filtering and zero the\ndiscarded tail. This preserves order and the existing off, only, and\nexclude behavior while reducing allocation pressure in the builders\npath.\n\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "abcc50a5f92f2454c5e5d2632cfd4d96717e98cc",
      "tree": "37fc74c97fd01e4826bc74c85967d8748e38bc24",
      "parents": [
        "bdb85d68f906791ed5d372e57231c01a692468b9"
      ],
      "author": {
        "name": "Keith Smiley",
        "email": "keithbsmiley@gmail.com",
        "time": "Fri Jul 03 14:59:14 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Jul 03 21:59:14 2026 +0000"
      },
      "message": "Support --force_pic for cgo interop (#4648)\n\nIf you set --force_pic on linux and then link go into a cc_binary, the\nC++ code is likely built with pic but the go code was not, leading to\nlinker failures. Now this default bazel flag is respected."
    },
    {
      "commit": "bdb85d68f906791ed5d372e57231c01a692468b9",
      "tree": "b1d0a569048e86b8e2d4798dc2836a22368e85cc",
      "parents": [
        "3615c2c28d73fb4f71b37ec729069a7e06399474"
      ],
      "author": {
        "name": "Teo Koon Peng",
        "email": "koonpeng@google.com",
        "time": "Fri Jul 03 11:43:34 2026 +0800"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Jul 03 03:43:34 2026 +0000"
      },
      "message": "Use param file to avoid argument list exceeding OS limit (#4649)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nRegression in 0.61 where `use_param_file` is not used, resulting in\nrules_go sometimes producing arguments that exceeds OS limit.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4643 `Argument list too long` error when building with `-c\nfastbuild`.\n\n**Other notes for review**\n\nSigned-off-by: Teo Koon Peng \u003ckoonpeng@google.com\u003e"
    },
    {
      "commit": "3615c2c28d73fb4f71b37ec729069a7e06399474",
      "tree": "7dfc93ae546c8c962c931be126066c2d32c55817",
      "parents": [
        "5ed523774dd68eaeece4c6922070d79f3c85f8f1"
      ],
      "author": {
        "name": "Richard Lavoie",
        "email": "lavoie.richard@gmail.com",
        "time": "Thu Jul 02 12:08:17 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Jul 02 16:08:17 2026 +0000"
      },
      "message": "Exclude test sources, not needed for the bootstrap SDK compilation (#4644)\n\n**What type of PR is this?**\n\nOther\n\n**What does this PR do? Why is it needed?**\n\nThis trim downs the required sources files to build the sdk. This also\nreduces the remote cache entry for that action.\n\nI can\u0027t remember how to reproduce, but some of the test filenames are\nalso invalid target names which resulted in errors in our CI\n\n**Which issues(s) does this PR fix?**\n\nN/A\n\n**Other notes for review**\n\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "5ed523774dd68eaeece4c6922070d79f3c85f8f1",
      "tree": "b94750799263f3a59b04336f074d706e0a0e0cd1",
      "parents": [
        "dd24e55a3427d461031bffcf56fd2e540a54bd65"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Thu Jul 02 17:24:34 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Jul 02 17:24:34 2026 +0200"
      },
      "message": "protoc: stream generated file copies (#4647)\n\ngo-protoc stages plugin output in a temporary directory and then copies\neach generated Go file to its declared output path. This matters because\nlarge generated protobuf files can make the old ioutil.ReadFile plus\nWriteFile path allocate a full byte slice for each output before writing\nit.\n\nCopy generated files with io.Copy instead. This keeps the same output\npaths, truncation behavior, and file mode, while bounding memory use to\nthe copy buffer instead of the generated file size."
    },
    {
      "commit": "dd24e55a3427d461031bffcf56fd2e540a54bd65",
      "tree": "f3597b2e67d3c5015509a898d68698904763e651",
      "parents": [
        "63335b2b8c8a1491e4f0b8045e4f96d9e9a45fce"
      ],
      "author": {
        "name": "Taiwon Chung",
        "email": "2008812+tchung1118@users.noreply.github.com",
        "time": "Wed Jul 01 22:16:24 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Jul 01 22:16:24 2026 -0400"
      },
      "message": "[builder/cgo] escape ldflags for invoking cgo starting Go 1.27 (#4641)\n\n**What type of PR is this?**\n\nBug fix\n\n\n**What does this PR do? Why is it needed?**\nGo 1.27 changes how the cgo tool expands `@file` response file\narguments. Starting in Go 1.27, any argument beginning with @ is\nexpanded before flag parsing using GCC-compatible tokenization — the\nfile content is split on whitespace into multiple tokens.\n\nRules_go passes cgo its linker flags via -ldflags @\u003ctmpfile\u003e, writing\nthe file as a plain space-joined string (e.g.,\n-fsanitize-undefined-strip-path-components\u003d0 -lm -lpthread). Before Go\n1.27, cgo handled @\u003cfile\u003e inside its own -ldflags flag handler, treating\nthe file content as a single string. With the new global expansion, the\nfile is tokenized before flag parsing, injecting each\nwhitespace-separated flag as an independent argument into cgo\u0027s own flag\nspace. The first token is consumed as the value of -ldflags, and the\nrest are parsed as unknown cgo flags, producing an error similar to the\nfollowing:\n```\nflag provided but not defined: -fsanitize-undefined-strip-path-components\n```\n\nThis PR fixes the issue by wrapping the ldflags file content in double\nquotes (with proper escaping of \\ and \") when building with Go 1.27+.\nGCC tokenization then yields exactly one quoted token — the complete\nldflags string — which is correctly consumed as the value of -ldflags. A\nseparate build-tag-gated file preserves the original behavior for older\nGo versions.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4640\n\n**Other notes for review**"
    },
    {
      "commit": "63335b2b8c8a1491e4f0b8045e4f96d9e9a45fce",
      "tree": "ae0972febd1481702ffd6aa3ea9bf50fc61f2edb",
      "parents": [
        "92826003d1be9071d6209b43338aa41abd0d56fa"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Tue Jun 23 13:36:15 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Jun 23 13:36:15 2026 -0400"
      },
      "message": "Declare GoArchive in rule provider declarations (#4638)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\n`go_binary`, `go_library`, and `go_test` return `GoArchive`, but their\nrule declarations did not consistently list `GoArchive` in `provides`.\nBazel therefore skipped aspects that use `required_providers \u003d\n[GoArchive]` before running the aspect implementation. Declare\n`GoArchive` for all three rules and add analysis tests that verify the\naspect runs for each rule.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4612\n\n**Other notes for review**\n\nValidated with `bazel test --jobs\u003d4 //tests/core/starlark:all` and\n`bazel test --jobs\u003d4 //tests:buildifier_test`."
    },
    {
      "commit": "92826003d1be9071d6209b43338aa41abd0d56fa",
      "tree": "d3a7082306848c6fa19234742d26f3a6adeb1609",
      "parents": [
        "370a75048291a6e03fd29bb96f20ecefac5416ad"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Mon Jun 22 14:52:39 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Jun 22 18:52:39 2026 +0000"
      },
      "message": "Preserve common Go settings in go_stdlib_transition (#4637)\n\n## Summary\n\nAuthor: zbarsky-bot\n\nStart `go_stdlib_transition` from all values in\n`_reset_transition_keys`; the transition then only filters\n`//go/config:tags` and disables `//go/private:bootstrap_nogo` and\n`//command_line_option:collect_code_coverage`. This keeps each Go rule\nand its `//:stdlib` dependency in the same configuration when resolving\nthe C++ toolchain.\n\nSince #4599 removed `cgo_context_data`, each Go rule resolves the C++\ntoolchain directly. Resetting `//go/private:request_nogo` made ordinary\nGo rules and `//:stdlib` resolve configuration-specific C++ runtime\narchives in different configurations, so `GoLink` could reference an\narchive that Bazel did not declare. Preserving every\n`_reset_transition_keys` value prevents `//go/config:static`,\n`//go/config:debug`, or future settings from recreating the same\nmismatch.\n\nThe regression test verifies the two required `//:stdlib` configurations\nfor an ordinary Go target and `coverdata`. `//:stdlib` has no `_nogo`\nattribute, so preserving `//go/private:request_nogo` does not run nogo\non `//:stdlib`.\n\n## Testing\n\n- `bazel test //tests/core/transition:hermeticity_test`\n- `bazel test //tests:buildifier_test`"
    },
    {
      "commit": "370a75048291a6e03fd29bb96f20ecefac5416ad",
      "tree": "0a850368ce16237686b4380029b000a75685cdde",
      "parents": [
        "8f974315778d3f75b52087b84c5b3fa331abfeb8"
      ],
      "author": {
        "name": "Aaron Son",
        "email": "aaron@dolthub.com",
        "time": "Wed Jun 10 14:25:30 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Jun 10 23:25:30 2026 +0200"
      },
      "message": "fix: add sanitize_pwd to unsupported cc toolchain features. (#4635)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nThe recently-added `sanitize_pwd` feature from rules_cc interacts poorly\nwith builders\u0027 absolute path calculation. It can cause Cgo compiles to\nfail as a result."
    },
    {
      "commit": "8f974315778d3f75b52087b84c5b3fa331abfeb8",
      "tree": "b865015c870bced0164f71c22de5865f7620b6fd",
      "parents": [
        "9667748a32de210cd4a813b15e9d987103ba0954"
      ],
      "author": {
        "name": "michaelm-openai",
        "email": "michaelm@openai.com",
        "time": "Mon Jun 08 13:09:27 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Jun 08 20:09:27 2026 +0000"
      },
      "message": "Add missing `go_link` exec group to more go_test (#4632)\n\nFollow-up to https://github.com/bazel-contrib/rules_go/pull/4630 so\nGoLink actions created by go_test targets receive the previously added\nexec group"
    },
    {
      "commit": "9667748a32de210cd4a813b15e9d987103ba0954",
      "tree": "8722a3df2303fc44a6a240c21d7b40d20506aa6e",
      "parents": [
        "075fea0f77abe12c98cb021f1af085ea8c8ce22f"
      ],
      "author": {
        "name": "michaelm-openai",
        "email": "michaelm@openai.com",
        "time": "Fri Jun 05 01:25:48 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Jun 05 10:25:48 2026 +0200"
      },
      "message": "Add `GoLink` actions to `go_link` exec group (#4630)\n\nAllow specifying execution info such as `resources:memory` for the\nGoLink action"
    },
    {
      "commit": "075fea0f77abe12c98cb021f1af085ea8c8ce22f",
      "tree": "7553e789f7c9196881f6f4a19616bd8b7c69a474",
      "parents": [
        "411d86ae39e9ff459107cdf2e105d5a4dd06d992"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Thu Jun 04 17:29:35 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Jun 04 21:29:35 2026 +0000"
      },
      "message": "Remove cc toolchain attr (#4601)\n\nThis is a legacy thing from before dedicated toolchains. We can drop it\nnow."
    },
    {
      "commit": "411d86ae39e9ff459107cdf2e105d5a4dd06d992",
      "tree": "3b73528d0afd66715ad92f7bff2b9eae843c849e",
      "parents": [
        "c8361e9a678814a74e92844c985c1d9e09764aff"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Thu Jun 04 14:44:38 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Jun 04 18:44:38 2026 +0000"
      },
      "message": "Update Gazelle to 0.51.3 (#4629)\n\nUpdate the Gazelle dependency from 0.45.0 to 0.51.3 in both MODULE.bazel\nand WORKSPACE.\n\nThis ensures it is new enough to build properly with cc toolchain\nchanges"
    },
    {
      "commit": "c8361e9a678814a74e92844c985c1d9e09764aff",
      "tree": "99fdccb3de72e9eaa301ba36e9dd579acfd489f9",
      "parents": [
        "2d3c81f26ee948dcd2297a0dc2177a97bf9a077d"
      ],
      "author": {
        "name": "leungster",
        "email": "leungster@gmail.com",
        "time": "Wed Jun 03 05:59:46 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Jun 03 12:59:46 2026 +0000"
      },
      "message": "fix: include CGO_TOOLCHAINS to _go_proto_aspect (#4625)\n\n\u003c!-- Thanks for sending a PR! Before submitting:\n\n1. If this is your first PR, please read CONTRIBUTING.md and sign the\nCLA\n   first. We cannot review code without a signed CLA.\n2. Please file an issue *first*. All features and most bug fixes should\nhave\nan associated issue with a design discussed and decided upon. Small bug\n   fixes and documentation improvements don\u0027t need issues.\n3. New features and bug fixes must have tests. Documentation may need to\nbe updated. If you\u0027re unsure what to update, send the PR, and we\u0027ll\ndiscuss\n   in review.\n4. Note that PRs updating dependencies and new Go versions are not\naccepted.\n   Please file an issue instead.\n--\u003e\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nAdds CGO_TOOLCHAINS to the proto aspect so it can propagate down to\ngo_proto_library targets.\n\nWhen enabling race detection on a `go_test` that depends on a\n`go_proto_library`, the CC toolchains weren\u0027t being propagated. This\nstarted breaking when the fallback from\nhttps://github.com/bazel-contrib/rules_go/pull/4599 was removed.\n\n**Which issues(s) does this PR fix?**\n\nFixes https://github.com/bazel-contrib/rules_go/issues/4624\n\n**Other notes for review**\n\n---------\n\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "2d3c81f26ee948dcd2297a0dc2177a97bf9a077d",
      "tree": "d191b4656f89a6cef09b89dbb14775ce31f987a4",
      "parents": [
        "a6f7272d58386e08843b78661dfb9029d4053cfd"
      ],
      "author": {
        "name": "Sitaktif",
        "email": "rchossart@apple.com",
        "time": "Wed Jun 03 10:10:06 2026 +0100"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Jun 03 11:10:06 2026 +0200"
      },
      "message": "fix: set nogo flags as universal (#4623)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nThis ensure the nogo flag doesn\u0027t get wiped when transitioning to an\nexec config when --incompatible_exclude_starlark_flags_from_exec_config\nis set.\n\nWithout this change, a cycle shows up in the dependencies when the\noption is set.\n\nFixes #4620\n\n(thanks @fmeum for the diagnosis!)"
    },
    {
      "commit": "a6f7272d58386e08843b78661dfb9029d4053cfd",
      "tree": "cec1303977fddb767db154a8e5539515ccf33025",
      "parents": [
        "eae864be66a69478d02455ff3a47a11cd1ef6afe"
      ],
      "author": {
        "name": "zhaixiaojuan",
        "email": "67671683+zhaixiaojuan@users.noreply.github.com",
        "time": "Sun May 31 22:27:41 2026 +0800"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sun May 31 14:27:41 2026 +0000"
      },
      "message": "Add loongarch64 support (#4610)\n\nWhat type of PR is this?\n\nBug fix\n\nWhat does this PR do? Why is it needed?\n\nIt matches GOARCH loong64 to something so that rules_go would work on\nLoongArch.\n\nWhich issues(s) does this PR fix?\n\nhttps://github.com/bazel-contrib/rules_go/issues/4609"
    },
    {
      "commit": "eae864be66a69478d02455ff3a47a11cd1ef6afe",
      "tree": "87b9f0f6d36ee64886bcf2625378846467022066",
      "parents": [
        "afd648f19231111a3090795f3aaa0aa55a071253"
      ],
      "author": {
        "name": "Austin Schuh",
        "email": "AustinSchuh@users.noreply.github.com",
        "time": "Sun May 31 04:24:01 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sun May 31 13:24:01 2026 +0200"
      },
      "message": "Add more flags to cgoAbsEnvFlags (#4619)\n\nClang has even more flags which provide include search paths. rules_go\nneeds to normalize those paths too in order for toolchains to be able to\nuse them.\n\nFixes: #4618\n\nSigned-off-by: Austin Schuh \u003caustin.linux@gmail.com\u003e"
    },
    {
      "commit": "afd648f19231111a3090795f3aaa0aa55a071253",
      "tree": "d3df94dd6d8063e0c9dc84a721098d687329e0cc",
      "parents": [
        "3a5559c6e54fe48d479abb14c4397bf3cc45a087"
      ],
      "author": {
        "name": "Robert Findley",
        "email": "rfindley@golang.org",
        "time": "Fri May 29 12:46:05 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri May 29 16:46:05 2026 +0000"
      },
      "message": "Revert \"fix: restore internal_archive.direct after cycle-break recompile\" (#4617)\n\nReverts bazel-contrib/rules_go#4606\n\nI think this contributes another case to #4607 -- per my investigation\nnot the *only* path to duplicate import paths, but it does make it\npossible.\n\nI\u0027m still investigating, but I think we should revert this patch and \"do\nit properly\", ensuring coherency of direct imports.\n\nI will send a follow-up, more principled fix that also fixes #4607."
    },
    {
      "commit": "3a5559c6e54fe48d479abb14c4397bf3cc45a087",
      "tree": "0cf4963b13771817ef7fa33b5385145e3b03549c",
      "parents": [
        "8952d114093dab5c42aa6ed9ffb7e7d400c5bb1a"
      ],
      "author": {
        "name": "Sitaktif",
        "email": "rchossart@apple.com",
        "time": "Thu May 28 22:10:24 2026 +0100"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu May 28 21:10:24 2026 +0000"
      },
      "message": "chore: remove reference to deprecated host mode (#4614)\n\n**What type of PR is this?**\n\nOther (cleanup)\n\n**What does this PR do? Why is it needed?**\n\nIt removes references to Bazel\u0027s host mode, which was removed in Bazel\n6. It is a follow-up to #4611\n\n**Which issues(s) does this PR fix?**\n\nFixes #4613"
    },
    {
      "commit": "8952d114093dab5c42aa6ed9ffb7e7d400c5bb1a",
      "tree": "5a8a613c49bd04bf2190ac5202b7cbcd342fe771",
      "parents": [
        "5ddb5172f9d5e3843de9c45d5d659f4fa38812df"
      ],
      "author": {
        "name": "Robert Findley",
        "email": "rfindley@anthropic.com",
        "time": "Thu May 28 11:41:23 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu May 28 17:41:23 2026 +0200"
      },
      "message": "fix: produce facts of required analyzers in nogo facts-only mode (#4615)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nIn facts-only compiles (packages outside the nogo `includes`, which\nincludes every external repository), nogo keeps an analyzer only if it\ndeclares `FactTypes` itself:\n\n```go\nif !factsOnly || len(a.FactTypes) \u003e 0 {\n```\n\nAnalyzers whose facts are produced by a *required* sub-analyzer are\ndropped entirely, so their requirement closure never runs and downstream\npackages never see those facts. The common shape is a checker that\nrequires a fact-exporting analyzer: staticcheck\u0027s SA1019 (use of\ndeprecated identifiers) requires its deprecation fact analyzer and\ndeclares no fact types of its own, so deprecation facts are never\nproduced for external repositories and uses of deprecated third-party\nAPIs in the main repository are silently missed. Analyzers like `printf`\nare unaffected only because they happen to declare their fact type\ndirectly.\n\nThis PR keeps an analyzer in facts-only mode when anything in its\nrequirement closure declares fact types, which matches the intent of the\nexisting comment (\"all analyzers that don\u0027t generated facts can be\nskipped\").\n\nVerified against a large monorepo by patching its rules_go: with the\nfix, SA1019 immediately reported uses of deprecated identifiers declared\nin external module dependencies that were silently missed before, while\nexternal packages themselves still produced no diagnostics.\n\n**Which issues(s) does this PR fix?**\n\nNo existing issue that I could find; happy to file one if preferred.\n\n**Other notes for review**\n\nThe new `tests/core/nogo/bzlmod/facts_only_test.go` pins the behavior\nwith a pair of custom analyzers mirroring the deprecation shape: the\nfact producer is only required, the nogo-registered analyzer declares no\nfact types, and the marked function is declared in a package outside the\nnogo `includes`. The first test fails without the `nogo_main.go` change\nand passes with it; the second checks that facts-only compiles still\nreport no diagnostics of their own.\n\nFixes #4616"
    },
    {
      "commit": "5ddb5172f9d5e3843de9c45d5d659f4fa38812df",
      "tree": "50a30507a5d09952b1674f79c8298a69b00d42f7",
      "parents": [
        "5d946afda8236b6f3fe555d772b9333f148c5995"
      ],
      "author": {
        "name": "Sitaktif",
        "email": "rchossart@apple.com",
        "time": "Tue May 26 17:47:17 2026 +0100"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue May 26 18:47:17 2026 +0200"
      },
      "message": "Set direct nogo attribute to prevent building nogo for the wrong platform when multiple exec platforms are set (#4611)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nThis PR fixes an issue whereby, when two or more exec platforms are set\n(via `--host_platform` and/or `--extra_execution_platforms`), it was\npossible for Nogo to be build for one exec platform A, but be executed\non exec platform B, leading to an \"exec format error\" / \"cannot execute\nbinary file\" error when the action is run.\n\nThis PR moves the nogo dep directly to the relevant rules instead of via\n`go_context_data`, removing the possibility for a discrepancy for the\ntwo exec configs.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4571\n\n**Other notes for review**\n\nI wasn\u0027t sure about the handling of \"legacy host mode\" mentioned in the\ncomments so I added a test that covers the case... if that\u0027s what the\ncomments meant by \"host mode\". Please someone check whether that\u0027s\nactually testing that (and/or if we still care about host mode)."
    },
    {
      "commit": "5d946afda8236b6f3fe555d772b9333f148c5995",
      "tree": "8ae4e642d2b045e5336bd904e07b92f233404098",
      "parents": [
        "63cd33e35b964fa63d587d905bb3102818314352"
      ],
      "author": {
        "name": "Bryce Lampe",
        "email": "brycelampe@gmail.com",
        "time": "Thu May 21 05:26:44 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu May 21 12:26:44 2026 +0000"
      },
      "message": "fix(nogo): generate accurate patches (#4602)\n\n**What type of PR is this?**\n\n\u003e Bug fix\n\n**What does this PR do? Why is it needed?**\n\nThe unmaintained [difflib](https://github.com/pmezard/go-difflib)\nlibrary we\u0027re currently using to generate patches doesn\u0027t correctly\nhandle whitespace. There is some discussion of this on the original\nimplementation #4102.\n\nIn particular, difflib always appends a phantom `\\n` character when\nsplitting lines, which the differ then treats as common context. Patches\nwhich remove trailing newlines (i.e. gofmt output) are incorrect as a\nresult. Several failing unit tests are included which demonstrate this\nand other problems with the library.\n\nAs a fix, I\u0027ve replaced the outdated difflib dependency with\n[go-udiff](https://github.com/aymanbagabas/go-udiff), which just exposes\nthe internal [diff\npackage](https://github.com/golang/tools/tree/master/internal/diff) used\nby gopls.\n\n**Which issues(s) does this PR fix?**\n\nFixes #\n\n**Other notes for review**"
    },
    {
      "commit": "63cd33e35b964fa63d587d905bb3102818314352",
      "tree": "afdd7d83650ac7979383f89d77fdc8a784bfd875",
      "parents": [
        "db13b337f0c3f48eda1d2c728d67c0e1f483a25c"
      ],
      "author": {
        "name": "Sitaktif",
        "email": "romainchossart@gmail.com",
        "time": "Tue May 12 12:03:23 2026 +0100"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue May 12 11:03:23 2026 +0000"
      },
      "message": "fix: put GoProtocGen in its own exec group (#4605)\n\nWhen building go_proto_library with two registered execution platforms\n(e.g. linux/x86_64 RBE registered first, darwin/arm64 local fallback),\nthe GoProtocGen action would fail with \"cannot execute binary file\":\n\n- go-protoc-bin is built via `cfg \u003d \"exec\"` in _go_proto_compiler, which\nindependently selects the first registered exec platform (e.g. linux ELF\nbinary).\n- Without --incompatible_auto_exec_groups, go_proto_library\u0027s Go\ntoolchain declaration may have additional constraints (e.g. darwin\narm64) and forces ALL rule actions onto darwin, including GoProtocGen.\n\nThis may lead to e.g. a linux binary executing on a darwin platform,\nleading to a \"exec format error\" error.\n\nFix: declare an unconstrained `go_proto_gen` exec group in\ngo_proto_library and assign GoProtocGen to it via `exec_group \u003d\n\"go_proto_gen\"`. The group has no toolchain constraints, making it\nequivalent to `cfg \u003d \"exec\"`, so Bazel picks the first compatible exec\nplatform — the same one that built go-protoc-bin via `cfg \u003d \"exec\"`.\n\ngo.env already carries GOOS/GOARCH/GOROOT as concrete strings from\ngo_context(), so the generated .pb.go files remain correctly targeted to\nthe host platform. The generator itself does not need to run on the\ntarget platform.\n\nFixes #4604 \n\n-- \n\nI pushed a way to reproduce the issue in\nhttps://github.com/sitaktif/rules_go/tree/rules-go-exec-format-error-repro,\nbut I don\u0027t have an actual test in this PR to prevent future regressions\nbecause I\u0027m not sure how to test that without an overly complicated and\nslow setup. Please share any suggestions on how to do that :-)"
    },
    {
      "commit": "db13b337f0c3f48eda1d2c728d67c0e1f483a25c",
      "tree": "f8e0eea0650357ae412befb3758da3c40436a1df",
      "parents": [
        "c031936df155d7d7862d6d046e57073083d0fe32"
      ],
      "author": {
        "name": "Keegan Carruthers-Smith",
        "email": "keegan.csmith@gmail.com",
        "time": "Tue May 12 11:48:32 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue May 12 09:48:32 2026 +0000"
      },
      "message": "fix/nogo: use resolved Label for GoGenNogo toolchain (#4608)\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nAutomatic exec groups breaks nogo for us since we don\u0027t use\n`repo_name\u003d\"io_bazel_rules_go\"`. It looks like nogo was the only place\nthat didn\u0027t use the preresolved label:\n\n```\n❯ git grep \u0027toolchain \u003d GO_TOOLCHAIN\u0027\nextras/gomock.bzl:        toolchain \u003d GO_TOOLCHAIN_LABEL,\nextras/gomock.bzl:        toolchain \u003d GO_TOOLCHAIN_LABEL,\ngo/private/actions/compilepkg.bzl:        toolchain \u003d GO_TOOLCHAIN_LABEL,\ngo/private/actions/compilepkg.bzl:        toolchain \u003d GO_TOOLCHAIN_LABEL,\ngo/private/actions/compilepkg.bzl:            toolchain \u003d GO_TOOLCHAIN_LABEL,\ngo/private/actions/link.bzl:        toolchain \u003d GO_TOOLCHAIN_LABEL,\ngo/private/actions/stdlib.bzl:        toolchain \u003d GO_TOOLCHAIN_LABEL,\ngo/private/actions/stdlib.bzl:        toolchain \u003d GO_TOOLCHAIN_LABEL,\ngo/private/rules/nogo.bzl:        toolchain \u003d GO_TOOLCHAIN,\ngo/private/rules/test.bzl:        toolchain \u003d GO_TOOLCHAIN_LABEL,\nproto/compiler.bzl:        toolchain \u003d GO_TOOLCHAIN_LABEL,\n```\n\n**Which issues(s) does this PR fix?**\n\nThis is a follow-up of #4139 which was about switching to the\npreresolved labels. PR #4141 was what introduced toolchain which didn\u0027t\nuse the label.\n\n**Other notes for review**\n\nI tested this with `bazel test --incompatible_auto_exec_groups\n//tests/core/nogo/bzlmod:includes_exclude_test`"
    },
    {
      "commit": "c031936df155d7d7862d6d046e57073083d0fe32",
      "tree": "23d3ab73da041e217a60232355890cf9bbad463f",
      "parents": [
        "9e3620fab9f2015d5c78c83e873cb6788ac762cf"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Sat May 09 01:33:27 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat May 09 07:33:27 2026 +0200"
      },
      "message": "Allow experimental ability to bootstrap go toolchain from source (#4553)\n\nThis allow users to apply targeted patches on top of the Go compiler in\nan easy way. The motivating use case is\nhttps://github.com/cerisier/toolchains_llvm_bootstrapped requiring a\nsmall compiler patch that landed upstream but did not make the Go 1.26\nrelease, but it can also be used to easily test Go compiler changes\nagainst a Bazel codebase\n\n---------\n\nCo-authored-by: Son Luong Ngoc \u003csluongng@gmail.com\u003e\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "9e3620fab9f2015d5c78c83e873cb6788ac762cf",
      "tree": "a096eadf167a9a29512aa0c6b6c7fbfeb68b61de",
      "parents": [
        "45e341cd7ffcc31db0cb337eb70cc08c13e957f2"
      ],
      "author": {
        "name": "Robert Findley",
        "email": "rfindley@golang.org",
        "time": "Fri May 08 05:47:28 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri May 08 11:47:28 2026 +0200"
      },
      "message": "fix: restore internal_archive.direct after cycle-break recompile (#4606)\n\nWhen a go_test embeds a library and an external test (x_test) source\nimports a package that transitively reaches the embedded library,\n_recompile_external_deps recompiles the internal archive with a filtered\ndeps list to break the cycle. (We call these intermediate test variants\nin cmd/go).\n\nHowever, when the go/packages driver queries package information for an\nx_test source, the go_pkg_info_aspect looks up imports in the first\narchive it encounters. Prior to this PR, that could be the internal\narchive, which only contained imports that were filtered in the middle\nof cycle-breaking.\n\nThis change restores the recompiled imports back onto the internal\narchive, so that the driver can reconstruct accurate import information\nfor the x_test package.\n\nCredit to @jgautier-dd for #4405, on which this was based.\n\nFixes #3981"
    },
    {
      "commit": "45e341cd7ffcc31db0cb337eb70cc08c13e957f2",
      "tree": "1ac097531cbf1ab127b40fcc6ef38ca48385d7bf",
      "parents": [
        "e3b3263e07463c337c394117ccf8aa4090a66048"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Thu May 07 11:44:05 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu May 07 11:44:05 2026 -0400"
      },
      "message": "Add C++ runtime libs to cgo action inputs (#4594)\n\nWith @llvm toolchain, libc++ is provided via cc_toolchain\u0027s\n`static_runtime_library`/`dynamic_runtime_library`. These groups should\nbe added to link actions otherwise cgo code that attempts to link libc++\nwill not work properly. It seems there were previous attempts to drop\nlibc++ - I\u0027m not sure the best way to harmonize these, some tweaking of\nthis PR may be necessary. @jayconrod @fmeum wdyt?"
    },
    {
      "commit": "e3b3263e07463c337c394117ccf8aa4090a66048",
      "tree": "c52fa61dc1d98cdadf176ab72f91b809bbcb7d4f",
      "parents": [
        "65c1b4d0c77d67e66fca162719ac375dc96514e1"
      ],
      "author": {
        "name": "Sahin Yort",
        "email": "thesayyn@gmail.com",
        "time": "Wed May 06 01:01:16 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed May 06 10:01:16 2026 +0200"
      },
      "message": "fix: avoid generating -Wl for dynamic libraries with an interface (#4574)\n\n**What type of PR is this?**\n\n\u003e Bug fix\n\n**What does this PR do? Why is it needed?**\n\n_cc_libs_and_flags only collected files from LibraryToLink.libraries and\nignored\nlinker_input.additional_inputs, so any files provided via that field\nwere never added to the GoCompilePkg or\nGoLink sandboxes. Additionally, when a LibraryToLink has both\ninterface_library and dynamic_library set, adding\nthe dynamic_library to libs caused it to flow into cgo_deps, which the\nGoLink rpath generation loop iterated\nover — with many such libraries this generates enough -Wl,-rpath flags\nto exceed the OS argument limit. The fix\ncollects additional_inputs from each linker input and makes them\navailable to the compile sandbox, while\ndynamic_library from interface+dynamic pairs is tracked separately as\nlink_inputs and threaded through GoArchive\nto GoLink as plain sandbox inputs — bypassing rpath generation entirely.\n\n**Which issues(s) does this PR fix?**\n\nFollow up to https://github.com/bazel-contrib/rules_go/pull/4569 which\nit incorrectly fixed.\n\n**Other notes for review**\n\n---------\n\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "65c1b4d0c77d67e66fca162719ac375dc96514e1",
      "tree": "7d317ad347c98bde516fc02f57143cf55ca01984",
      "parents": [
        "aadb72e60d6b24b086d082cb25af8b5ec00a51d2"
      ],
      "author": {
        "name": "Dean Lindqvist Todevski",
        "email": "dean.todevski@gmail.com",
        "time": "Fri May 01 21:10:29 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri May 01 19:10:29 2026 +0000"
      },
      "message": "Consistent auto-registered toolchain path naming (#4597)\n\n**What type of PR is this?**\n\n Bug fix\n\n**What does this PR do? Why is it needed?**\n\nAs discussed in\nhttps://bazelbuild.slack.com/archives/CA31HN1T3/p1776898907041159?thread_ts\u003d1776576264.819169\u0026cid\u003dCA31HN1T3.\nName autoregistered go toolchain paths consistently independent of host\nplatform.\n\n**Which issues(s) does this PR fix?**\n\nWe have a remote execution cluster running linux/amd64. The toolchain\npaths look different if we target it from a linux/amd64 or a\ndarwin/arm64 host, changing the ActionKey:s and thereby preventing us\nfrom sharing cache hits. Here is an example diff between aquery:s from\nthe two host platforms:\n```diff\nEnvironment: [CGO_ENABLED\u003d0, GOARCH\u003damd64, GODEBUG\u003dwinsymlink\u003d0, GOEXPERIMENT\u003d, GOOS\u003dlinux, GOPATH\u003d, GOROOT\u003dbazel-out/linux-amd64-opt-ST-c808acfdf156/bin/external/rules_go+/stdlib_, GOROOT_FINAL\u003dGOROOT, GOTOOLCHAIN\u003dlocal]\n-  Command Line: (exec bazel-out/linux-amd64-opt-exec-ST-4601870f3351/bin/external/rules_go++go_sdk+main___download_0/builder_reset/builder \\\n+  Command Line: (exec bazel-out/linux-amd64-opt-exec-ST-4601870f3351/bin/external/rules_go++go_sdk+main___download_0_linux_amd64/builder_reset/builder \\\n     link \\\n     -sdk \\\n-    external/rules_go++go_sdk+main___download_0 \\\n+    external/rules_go++go_sdk+main___download_0_linux_amd64 \\\n     -goroot \\\n     bazel-out/linux-amd64-opt-ST-c808acfdf156/bin/external/rules_go+/stdlib_ \\\n     -installsuffix \\\n@@ -2593,7 +2593,7 @@\n     -arc \\\n     \u0027@@rules_go+//go/tools/bzltestutil:bzltestutil\u003dgithub.com/bazelbuild/rules_go/go/tools/bzltestutil\u003dbazel-out/linux-amd64-opt-ST-4601870f3351/bin/external/rules_go+/go/tools/bzltestutil/bzltestutil.a\u0027 \\\n     -package_list \\\n-    bazel-out/linux-amd64-opt-exec-ST-4601870f3351/bin/external/rules_go++go_sdk+main___download_0/packages.txt \\\n+    bazel-out/linux-amd64-opt-exec-ST-4601870f3351/bin/external/rules_go++go_sdk+main___download_0_linux_amd64/packages.txt \\\n     -X \\\n     \u0027github.com/formulatehq/ingest/defaults.GitBranch\u003d{STABLE_GIT_BRANCH}\u0027 \\\n     -X \\\n```\n\nWith this change the toolchain path is\n`bazel-out/linux-amd64-opt-exec-ST-4601870f3351/bin/external/rules_go++go_sdk+main___download_0_linux_amd64/packages.txt`\nregardless of host platform.\n\n**Other notes for review**"
    },
    {
      "commit": "aadb72e60d6b24b086d082cb25af8b5ec00a51d2",
      "tree": "45237da05ac7c37686d5b0d9960962434fb714d6",
      "parents": [
        "0725e3249ce4eaeaee39a9a3530f656231855b22"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Wed Apr 29 13:29:18 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Apr 29 17:29:18 2026 +0000"
      },
      "message": "Use rules_cc to load cc symbols (#4579)\n\n**What type of PR is this?**\nRefactor/cleanup\n\n**What does this PR do? Why is it needed?**\nThese should disappear from @bazel_tools eventually\n\n**Which issues(s) does this PR fix?**\n\nFixes #\n\n**Other notes for review**"
    },
    {
      "commit": "0725e3249ce4eaeaee39a9a3530f656231855b22",
      "tree": "78397ce4c4e1c827def84e630a9ea68d1d44318a",
      "parents": [
        "2484069f1d7f41561d62f42e7e8700fa5026e5c3"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Mon Apr 27 20:54:36 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Apr 28 00:54:36 2026 +0000"
      },
      "message": "Stop including deprecated properties in context by default (#4389)\n\n**What type of PR is this?**\nCleanup\n\n**What does this PR do? Why is it needed?**\nWe would like to drop support for these properties completely, but for\nnow let\u0027s make them opt-in rather than opt-out. The core Go rules have\nnot been using them for 9 months or so.\n\n**Which issues(s) does this PR fix?**\n\nFixes #\n\n**Other notes for review**"
    },
    {
      "commit": "2484069f1d7f41561d62f42e7e8700fa5026e5c3",
      "tree": "2f4c81432db54bbf55b7ebf3f4a7b8c5435fb5fe",
      "parents": [
        "d83032da0b6cee93c43f6ce2c7d9c865700de961"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Mon Apr 27 18:35:54 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Apr 27 22:35:54 2026 +0000"
      },
      "message": "Remove cgo_context_data (#4599)\n\nIt\u0027s tempting to use a single target to centralize cc toolchain lookup,\nbut ultimately it is incorrect. Toolchain resolution must be performed\nby the rules using that toolchain, in order to properly match on the\nexec platforms. The other reason for cgo_context_data was that\npreviously optional toolchains were not possible, but now they are.\nCleanup this incorrect rule to thwart the temptations.\n\n---------\n\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "d83032da0b6cee93c43f6ce2c7d9c865700de961",
      "tree": "4d96a162896d7e5d0846de97e197bbf71f297028",
      "parents": [
        "feb90eb90cc0902e20848cdf3a7a0e1c288a712f"
      ],
      "author": {
        "name": "Keith Smiley",
        "email": "keithbsmiley@gmail.com",
        "time": "Mon Apr 27 12:11:05 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Apr 27 19:11:05 2026 +0000"
      },
      "message": "Fix invalid comparison (#4598)\n\n`go.mode` is a struct, so it was never equal to `LINKMODE_NORMAL`. I\u0027m\nnot sure what visible effect this had but I noticed it when debugging\nanother issue.\n\nCo-authored-by: Jay Conrod \u003cjay@engflow.com\u003e"
    },
    {
      "commit": "feb90eb90cc0902e20848cdf3a7a0e1c288a712f",
      "tree": "7d84123b5dbf4055fb3386e19184ebe236ec7bdd",
      "parents": [
        "eedda259fbbb5320faa0903ec3bac9ff3d4eedbe"
      ],
      "author": {
        "name": "David Zbarsky",
        "email": "dzbarsky@gmail.com",
        "time": "Mon Apr 27 13:46:43 2026 -0400"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Apr 27 13:46:43 2026 -0400"
      },
      "message": "perf: Only resolve cc toolchain for rules that will need it (#4593)\n\nThis PR is a re-write of\nhttps://github.com/bazel-contrib/rules_go/pull/4591 which was incorrect\n- the cc toolchain must be resolved by the rule owning the action that\nuses it, it cannot be resolved by a dependent rule (CgoContextData) as\nthat will not work correctly when there are multiple execution\nplatforms. See\nhttps://bazelbuild.slack.com/archives/CDBP88Z0D/p1776380536174449 for\ndiscussion"
    },
    {
      "commit": "eedda259fbbb5320faa0903ec3bac9ff3d4eedbe",
      "tree": "94a67b893cafbac934059f1a7f1116a9b11b654f",
      "parents": [
        "dfabfe9ab146aef567cb37284817de571a78e6ff"
      ],
      "author": {
        "name": "Jay Conrod",
        "email": "jay@engflow.com",
        "time": "Mon Apr 27 08:00:44 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Apr 27 15:00:44 2026 +0000"
      },
      "message": "gopackagesdriver: ignore bazel analysis errors (#4567)\n\n**What type of PR is this?**\n\n\u003e Bug fix\n\n**What does this PR do? Why is it needed?**\n\nBazel exits with code 7 (ANALYSIS_FAILURE) when querying a file that\u0027s\nnot mentioned in BUILD. gopackagesdriver can returns partial results for\ncode 1 (BUILD_FAILURE), but not 7.\n\ngopackagesdriver often hits this for a new file not added to BUILD. A\nfile\u003d query may still fail in this case because the query will match no\nlabels, but at least that\u0027s no longer a bazel error.\n\n**Which issues(s) does this PR fix?**\n\nFixes #4565\n\n**Other notes for review**"
    },
    {
      "commit": "dfabfe9ab146aef567cb37284817de571a78e6ff",
      "tree": "bc2d2ee2d92257efabfbef612b7e992128df084c",
      "parents": [
        "fcc41bbe67d83d3cd388890ff7c872832944347c"
      ],
      "author": {
        "name": "Teo Koon Peng",
        "email": "teokoonpeng@gmail.com",
        "time": "Sat Apr 18 15:04:50 2026 +0800"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Apr 18 07:04:50 2026 +0000"
      },
      "message": "gopackagesdriver: fix missing cgo files when RBE is used (#4589)\n\nBug fix #4588\n\nWe notice in our codebase that gopls fails to index some files. The\ngopackagesdriver logs show this error:\n\n```\nerror: unable to load JSON files: unable to resolve imports: open \u003comitted\u003e/_cgo_gotypes.go: no such file or directory\n```\n\nI feed the error to gemini and it proposed this:\n\n\u003cdetails\u003e\n\n\u003csummary\u003eGemini report\u003c/summary\u003e\n\n## Root Cause\n\nThe root cause lies within the `rules_go` Bazel ruleset, specifically in\nthe `go_pkg_info_aspect` aspect located at\n`go/tools/gopackagesdriver/aspect.bzl`.\n\nTo understand the issue, it is helpful to understand a few key concepts\nin this workflow:\n* **`pkg.json`**: A metadata file generated by the `go_pkg_info_aspect`\naspect for each Go target. It contains structured information (like\ndependencies, source files, and import paths) that `gopackagesdriver`\nuses to inform `gopls` about how the package is constructed.\n* **`compiled_go_files`**: A list within the aspect\u0027s provider that\ntracks all the Go source files destined for compilation. In Bazel,\nexposing these files in an output group (like `go_pkg_driver_srcs`)\ntells the build system that it must actually execute the actions to\ngenerate these files before the build command finishes.\n* **`cgo_out_dir`**: The output directory containing intermediate Go\nfiles generated by the `cgo` tool (such as `_cgo_gotypes.go` and\n`_cgo_export.go`). These files are generated from C/C++ sources or Go\nfiles containing `import \"C\"`.\n\nWhen the aspect processes a `go_test` target, it traverses the\ndependencies to find the archive containing the test sources. While it\ncorrectly generates the `pkg.json` metadata file pointing to the\ngenerated `cgo` output files within the `cgo_out_dir`, it forgot to add\nthe `cgo_out_dir` to the list of `compiled_go_files`.\n\nBecause `cgo_out_dir` was omitted from `compiled_go_files` (which maps\nto the `go_pkg_driver_srcs` output group), Bazel did not guarantee that\nthe `cgo` outputs were actually built and present on disk before\ncompleting the aspect execution. When `gopls` then parsed the `pkg.json`\nand attempted to read the generated source files, they were missing,\nresulting in the error.\n\n## Resolution\n\nThe issue was resolved by patching `rules_go` to ensure that\n`cgo_out_dir` is correctly added to `compiled_go_files` when processing\n`go_test` dependencies.\n\n```diff\ndiff --git a/go/tools/gopackagesdriver/aspect.bzl b/go/tools/gopackagesdriver/aspect.bzl\nindex dbe5663..8dc7d3e 100644\n--- a/go/tools/gopackagesdriver/aspect.bzl\n+++ b/go/tools/gopackagesdriver/aspect.bzl\n@@ -108,6 +108,8 @@ def _go_pkg_info_aspect_impl(target, ctx):\n                 if archive.data.label \u003d\u003d dep_archive.data.label:\n                     pkg_json_files.append(make_pkg_json_with_archive(ctx, dep_archive.data.name, dep_archive))\n                     compiled_go_files.extend(dep_archive.source.srcs)\n+                    if dep_archive.data.cgo_out_dir:\n+                        compiled_go_files.append(dep_archive.data.cgo_out_dir)\n                     export_files.append(dep_archive.data.export_file)\n                     break\n \n```\n\n\u003c/details\u003e\n\nI don\u0027t fully understand the root cause but the proposed fix is working\nfor us. Does the fix make sense?\n\nSigned-off-by: Teo Koon Peng \u003ckoonpeng@google.com\u003e\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "fcc41bbe67d83d3cd388890ff7c872832944347c",
      "tree": "7635601d267697ae0388b6a0f7e048ec852fa003",
      "parents": [
        "fc06c2473f6530bbb5901ab75667faadfcedef4f"
      ],
      "author": {
        "name": "James Sharpe",
        "email": "mail@jsharpe.net",
        "time": "Sat Apr 18 00:32:37 2026 +0100"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Apr 17 19:32:37 2026 -0400"
      },
      "message": "Revert \"context: prefer pre-computed CgoContextInfo from go_context_data\" (#4592)\n\nReverts bazel-contrib/rules_go#4591"
    },
    {
      "commit": "fc06c2473f6530bbb5901ab75667faadfcedef4f",
      "tree": "6f6fd4cf095519632854baeb4df25ae264c6019d",
      "parents": [
        "8808bb8c6604f1e7a2badbfcd9a9db4c32ba0a8c"
      ],
      "author": {
        "name": "James Sharpe",
        "email": "mail@jsharpe.net",
        "time": "Fri Apr 17 21:25:50 2026 +0100"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Apr 17 20:25:50 2026 +0000"
      },
      "message": "go/private: optimize _filter_options to avoid O(n²) scan (#4590)\n\nSplit the denylist into exact-match entries (dict lookup, O(1)) and\nprefix-match patterns (those ending in \"\u003d\", e.g. \"-fmax-errors\u003d\").\n\nOnly the rare prefix patterns require a linear scan, eliminating the\nprevious O(options × denylist) _match_option loop for the common case.\n\nThis provides a significant reduction in CPU time on large repos:\n| | Before | After |\n|--|--|--|\n| `_filter_options` CPU | 123s | 0.004s |\n| `_match_option` CPU | 56s | **0s** |\n\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "8808bb8c6604f1e7a2badbfcd9a9db4c32ba0a8c",
      "tree": "77f22e689a99e68fea00dccd4089c597e04f1edc",
      "parents": [
        "3b6b59aedb5c4500e422ae5634b9d47ef0aafa60"
      ],
      "author": {
        "name": "Hugo Beauzée-Luyssen",
        "email": "hugo@beauzee.fr",
        "time": "Fri Apr 17 15:34:41 2026 +0200"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Fri Apr 17 15:34:41 2026 +0200"
      },
      "message": "bzltestutil: fix re-exec failure on Windows when runfiles path exceeds MAX_PATH (#4586)\n\n\u003c!-- Thanks for sending a PR! Before submitting:\n\n1. If this is your first PR, please read CONTRIBUTING.md and sign the\nCLA\n   first. We cannot review code without a signed CLA.\n2. Please file an issue *first*. All features and most bug fixes should\nhave\nan associated issue with a design discussed and decided upon. Small bug\n   fixes and documentation improvements don\u0027t need issues.\n3. New features and bug fixes must have tests. Documentation may need to\nbe updated. If you\u0027re unsure what to update, send the PR, and we\u0027ll\ndiscuss\n   in review.\n4. Note that PRs updating dependencies and new Go versions are not\naccepted.\n   Please file an issue instead.\n--\u003e\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nFix `go_test` failures when the path containing the test executable is\nlonger than `MAX_PATH`.\nThe issue stems from `CreateProcess` which will systematically reject\nany working directory (whether passed explicitly or to be inherited)\nlonger than `MAX_PATH`, regardless of longpath prefix (`\\\\?\\`), long\npath setting being enabled in the registry, or `longPathAware` being\npresent in the binary\u0027s manifest.\n\n**Which issues(s) does this PR fix?**\n\nAFAIK, there is no open issue.\n\nI initially reported this to go\u0027s tracker as\nhttps://github.com/golang/go/issues/78601, but in the context of\n`rules_go` I don\u0027t think there is one.\n\n**Other notes for review**\n\nI wasn\u0027t sure what to do about testing. AFAICS testing `Wrap` might\nquickly become over complicated, and testing the new condition in\nisolation doesn\u0027t bring much. Please let me know if you have something\nin mind here!\n\n---------\n\nCo-authored-by: Joseph Gette \u003cjgettepost@gmail.com\u003e\nCo-authored-by: Fabian Meumertzheim \u003cfabian@meumertzhe.im\u003e"
    },
    {
      "commit": "3b6b59aedb5c4500e422ae5634b9d47ef0aafa60",
      "tree": "1dc3d45138c19e7096cc1148eee0cf7e527ec696",
      "parents": [
        "4f7900fab6689775d6f2060a338fc73f0d2d9d33"
      ],
      "author": {
        "name": "James Sharpe",
        "email": "mail@jsharpe.net",
        "time": "Fri Apr 17 00:25:27 2026 +0100"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Apr 16 23:25:27 2026 +0000"
      },
      "message": "context: prefer pre-computed CgoContextInfo from go_context_data (#4591)\n\nReorder the CgoContextInfo resolution in go_context() so that the\npre-computed value from go_context_data is checked before falling back\nto cgo_context_data_impl().\n\nThis avoids re-running the expensive cgo_context_data_impl for every\ngo_library target when a shared CgoContextInfo is already available from\nthe cgo_context_data rule.\n\nPerf improvements:\n| | Before | After |\n|--|--|--|\n| `cgo_context_data_impl` CPU | 132s | **0.02s** |"
    },
    {
      "commit": "4f7900fab6689775d6f2060a338fc73f0d2d9d33",
      "tree": "997c69a9e036c080ae688e9a8788787c297b4cce",
      "parents": [
        "552451c5d1f8fa47d3df2630eee6b39ab6c9bbf6"
      ],
      "author": {
        "name": "juanzolotoochin",
        "email": "88746611+juanzolotoochin@users.noreply.github.com",
        "time": "Tue Apr 07 13:43:49 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Apr 07 20:43:49 2026 +0000"
      },
      "message": "gopackagesdriver: disable path mapping for GoStdlibList action (#4585)\n\nSince https://github.com/bazel-contrib/rules_go/pull/4441, the\n`GoStdlibList` action uses `SUPPORTS_PATH_MAPPING_REQUIREMENT` and\npasses the cache directory via `add_all` (which enables path mapping).\nThis causes the stdlib builder to write path-mapped directory names\n(e.g. `bazel-out/cfg/`) into `stdlib.pkg.json`. The gopackagesdriver\nthen reads these paths at runtime to open source files, but the mapped\ndirectory doesn\u0027t exist on disk — the actual files are under the real\nconfig directory (e.g. `bazel-out/k8-fastbuild/`).\n\nThis breaks the gopackagesdriver for any Go target:\n\n```\nerror: unable to resolve imports: open .../bazel-out/cfg/bin/external/io_bazel_rules_go/stdlib_/gocache/...: no such file or directory\n```\n\nAffected stdlib packages are those with CGO-compiled files (`net`,\n`os/user`, `internal/runtime/cgobench`, etc.) whose `CompiledGoFiles`\nreference gocache entries under the mapped path.\n\n**Fix:** Unlike the stdlib build action (`_build_stdlib`), the\n`GoStdlibList` action produces `stdlib.pkg.json` which is consumed at\nruntime by the gopackagesdriver — not by Bazel. Path mapping is not\nappropriate here because the mapped paths are never resolved back to\nreal paths before being read. Revert to using `cache_dir.path` (real\nfilesystem path) and remove `SUPPORTS_PATH_MAPPING_REQUIREMENT` from\nthis action only.\n\nThis PR is an alternative to\nhttps://github.com/bazel-contrib/rules_go/pull/4584 which tried to\nresolve this at the gopackagesdriver but that solution was deemed\nbrittle."
    },
    {
      "commit": "552451c5d1f8fa47d3df2630eee6b39ab6c9bbf6",
      "tree": "b81903e965d3db00d1cbf47e6e775c7b060d102b",
      "parents": [
        "2ce3598fc987420d180649847f3bf1cc044494e6"
      ],
      "author": {
        "name": "hunshcn",
        "email": "hunsh.cn@gmail.com",
        "time": "Wed Apr 01 02:00:52 2026 +0800"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Mar 31 20:00:52 2026 +0200"
      },
      "message": "link: remove -z,now (BIND_NOW) from CC toolchain extldflags (#4578)\n\n## Summary\n\nFixes #4377.\n\nThe CC toolchain (`rules_cc`) typically passes `-Wl,-z,relro,-z,now` to\nthe linker for security hardening. However, `-z,now` forces all dynamic\nsymbols to be resolved at load time (BIND_NOW), which breaks Go\nlibraries that use `dlopen`/`dlsym` to load symbols at runtime.\n\nFor example, [NVIDIA\u0027s go-nvml](https://github.com/NVIDIA/go-nvml)\ndeclares NVML C functions in its header file, which CGO compiles into\nundefined dynamic symbols. At runtime, go-nvml loads these symbols via\n`dlopen(\"libnvidia-ml.so.1\", RTLD_LAZY | RTLD_GLOBAL)` inside\n`nvml.Init()`. With `BIND_NOW`, the dynamic linker fails immediately at\nprogram start:\n\n```\nsymbol lookup error: undefined symbol: nvmlComputeInstanceDestroy\n```\n\nThe same code works with `go build` because **the standard Go toolchain\ndoes not pass `-z,relro` or `-z,now` to the linker**.\n\n## Root Cause\n\n```\nrules_cc: unix_cc_configure.bzl    →  adds -Wl,-z,relro,-z,now to CC toolchain\nrules_go: context.bzl              →  picks up as ld_executable_options\nrules_go: mode.bzl                 →  extldflags_from_cc_toolchain() returns them\nrules_go: link.bzl                 →  passes as -extldflags to Go linker\n```\n\nThe resulting binary has `FLAGS: BIND_NOW` in its ELF dynamic section,\nwhile `go build` produces a binary without it.\n\n## Fix\n\nAdd `-Wl,-z,relro,-z,now` and `-Wl,-z,now` to `_LINKER_OPTIONS_DENYLIST`\nin `context.bzl`, consistent with how `-Wl,--gc-sections` and `-pie` are\nalready filtered for the same reason (CC toolchain defaults incompatible\nwith Go binaries).\n\nSince `go build` does not pass `-z,relro` either, filtering the compound\nflag entirely aligns with `go build` behavior.\n\n## Test plan\n\n- Added `bind_now_test.go` that inspects the ELF dynamic section of a\nnon-PIE cgo binary to verify `DF_BIND_NOW` / `DF_1_NOW` flags are not\nset (PIE excluded because the Go linker itself sets BIND_NOW for\n`-buildmode\u003dpie`)\n- Verified with a [minimal reproduction\nrepository](https://github.com/hunshcn/nvml-go-bazel) that the fix\nresolves the runtime symbol lookup error (the repo also includes a\n[user-level\nworkaround](https://github.com/hunshcn/nvml-go-bazel/commit/4110d4a)\nusing `gc_linkopts \u003d [\"-extldflags\", \"-Wl,-z,lazy\"]`)\n\n---------\n\nCo-authored-by: Claude Opus 4.6 \u003cnoreply@anthropic.com\u003e"
    },
    {
      "commit": "2ce3598fc987420d180649847f3bf1cc044494e6",
      "tree": "d0195d90061be03fde69f9121689e78664b40758",
      "parents": [
        "e7fb6ab0b4380ba16607152b0bef3e09ff66d8ab"
      ],
      "author": {
        "name": "luzhanning",
        "email": "35372007+luzhanning@users.noreply.github.com",
        "time": "Wed Mar 25 00:48:22 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Wed Mar 25 08:48:22 2026 +0100"
      },
      "message": "fix: Allow passing pgoprofile via the command line (#4580)\n\n\u003c!-- Thanks for sending a PR! Before submitting:\n\n1. If this is your first PR, please read CONTRIBUTING.md and sign the\nCLA\n   first. We cannot review code without a signed CLA.\n2. Please file an issue *first*. All features and most bug fixes should\nhave\nan associated issue with a design discussed and decided upon. Small bug\n   fixes and documentation improvements don\u0027t need issues.\n3. New features and bug fixes must have tests. Documentation may need to\nbe updated. If you\u0027re unsure what to update, send the PR, and we\u0027ll\ndiscuss\n   in review.\n4. Note that PRs updating dependencies and new Go versions are not\naccepted.\n   Please file an issue instead.\n--\u003e\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\nCurrently pgoprofile can be only set via BUILD files.\n\u0027--@io_bazel_rules_go//go/config:pgoprofile\u0027 will fail.\n\n**Which issues(s) does this PR fix?**\nAllow passing --@io_bazel_rules_go//go/config:pgoprofile thourgh command\nline\n\nFixes #4226\n\n**Other notes for review**\n\nCo-authored-by: zhanning.lu \u003czhanning.lu@bytedance.com\u003e"
    },
    {
      "commit": "e7fb6ab0b4380ba16607152b0bef3e09ff66d8ab",
      "tree": "91467584935e0fa189198c649ea4218c9d3fa938",
      "parents": [
        "6b4949e01d38d9eafecb071201a4f0a1ff81b651"
      ],
      "author": {
        "name": "Andrea Nardelli",
        "email": "nrd.nardelli@gmail.com",
        "time": "Thu Mar 19 16:44:38 2026 +0100"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Thu Mar 19 16:44:38 2026 +0100"
      },
      "message": "`go_bin_runner`: connect stdin (#4576)\n\n\u003c!-- Thanks for sending a PR! Before submitting:\n\n1. If this is your first PR, please read CONTRIBUTING.md and sign the\nCLA\n   first. We cannot review code without a signed CLA.\n2. Please file an issue *first*. All features and most bug fixes should\nhave\nan associated issue with a design discussed and decided upon. Small bug\n   fixes and documentation improvements don\u0027t need issues.\n3. New features and bug fixes must have tests. Documentation may need to\nbe updated. If you\u0027re unsure what to update, send the PR, and we\u0027ll\ndiscuss\n   in review.\n4. Note that PRs updating dependencies and new Go versions are not\naccepted.\n   Please file an issue instead.\n--\u003e\n\n**What type of PR is this?**\n\nFixes #4573 - more context written there"
    },
    {
      "commit": "6b4949e01d38d9eafecb071201a4f0a1ff81b651",
      "tree": "078b3a20c9739888e3c71f13f6274aa0e139a7e3",
      "parents": [
        "8e315a484519bb1b77238a232a82f91035143528"
      ],
      "author": {
        "name": "Son Luong Ngoc",
        "email": "sluongng@gmail.com",
        "time": "Tue Mar 17 23:08:03 2026 +0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Tue Mar 17 17:08:03 2026 +0100"
      },
      "message": "nogo: plumb SDK Go version into go/types (#4564)\n\nForward the selected SDK Go version from compilepkg into nogo and\ninitialize the corresponding go/types version plumbing during type\nchecking. This keeps nogo aligned with the active toolchain version\nwithout keying the action on unrelated gcflags.\n\nKeep gc_goopts -lang overrides unsupported for now. RunNogo still\nforwards only the SDK version, and compilepkg now documents that -lang\nparsing may be added later once nogo has proper gc flag parsing.\n\nAdd focused nogo coverage that checks both the RunNogo action"
    },
    {
      "commit": "8e315a484519bb1b77238a232a82f91035143528",
      "tree": "344d04b4538287fe8626ea14d34621b5946fb4be",
      "parents": [
        "d2997544dfec13ff17f8ab6f6d138dfda5ef44c0"
      ],
      "author": {
        "name": "Roman Mingazeev",
        "email": "Direnol@yandex.ru",
        "time": "Mon Mar 16 11:47:46 2026 +0100"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Mon Mar 16 10:47:46 2026 +0000"
      },
      "message": "fix: unstable import sorting for GoTestGenTest (#4570)\n\n\u003c!-- Thanks for sending a PR! Before submitting:\n\n1. If this is your first PR, please read CONTRIBUTING.md and sign the\nCLA\n   first. We cannot review code without a signed CLA.\n2. Please file an issue *first*. All features and most bug fixes should\nhave\nan associated issue with a design discussed and decided upon. Small bug\n   fixes and documentation improvements don\u0027t need issues.\n3. New features and bug fixes must have tests. Documentation may need to\nbe updated. If you\u0027re unsure what to update, send the PR, and we\u0027ll\ndiscuss\n   in review.\n4. Note that PRs updating dependencies and new Go versions are not\naccepted.\n   Please file an issue instead.\n--\u003e\n\n**What type of PR is this?**\n\nBug fix\n\n**What does this PR do? Why is it needed?**\n\nIt fixes non-deterministic output for `GoTestGenTest` that is caused by\nunstable import list sorting that might lead to cache misses during the\nbuild\n\n**Which issues(s) does this PR fix?**\n\nFixes #\n\n**Other notes for review**\n\nCo-authored-by: Roman Mingazeev \u003cdirenol@nebius.com\u003e"
    },
    {
      "commit": "d2997544dfec13ff17f8ab6f6d138dfda5ef44c0",
      "tree": "3b92313a91a5fb57257f02591cd7b64f4b184687",
      "parents": [
        "ca94a5b1d0fe87678ce01fcb75cb7839343b5f8e"
      ],
      "author": {
        "name": "Sahin Yort",
        "email": "thesayyn@gmail.com",
        "time": "Sat Mar 14 10:51:07 2026 -0700"
      },
      "committer": {
        "name": "GitHub",
        "email": "noreply@github.com",
        "time": "Sat Mar 14 18:51:07 2026 +0100"
      },
      "message": "fix: cgo: include dynamic library when interface library is set (#4569)\n\nOn Linux, some packages provide a linker script as the interface library\n(e.g. a bare `libfoo.so` containing `GROUP(...)`). The script references\nthe actual versioned dynamic library, which must also be present in the\nsandbox for the linker to resolve it."
    }
  ],
  "next": "ca94a5b1d0fe87678ce01fcb75cb7839343b5f8e"
}