**What type of PR is this?**

Adapt to a Bazel breaking change

**What does this PR do? Why is it needed?**

The `local_config_platform` repo is no longer available with Bazel@HEAD,
so the host constraints have to be loaded from `@platforms//host`.

Also prepare the BCR test repo for Bazel@HEAD with
`--incompatible_autoload_externally=` by applying buildifier lint fixes.

**Which issues(s) does this PR fix?**

**Other notes for review**

**What type of PR is this?**

Feature

**What does this PR do? Why is it needed?**

This makes it easier to deal with these toolchains in language-agnostic
aspects and helpers (in particular, bazel_env.bzl), that propagate to
toolchain targets.

Even though genrules now support `toolchain_type`s in their
`toolchains`, this does *not* allow Go SDKs to be used in genrules as
they don't expose the path to the Go binary via a Make variable. This is
intentional as we don't want to allow running `go` in `genrule`s.

**Which issues(s) does this PR fix?**

**Other notes for review**

…#4371)

When testing the bazel driver, we ran into an error that flaged that the
argument list as too long.

```
ERROR: ...json failed: (Exit -1): pkgjson failed: error executing Action command (from target //...) bazel-out/k8-opt-exec-ST-a828a81199fe/bin/external/io_bazel_rules_go/go/tools/gopackagesdriver/pkgjson/reset_pkgjson/pkgjson --id @//src/... --pkg_path ... (remaining 15 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
Action failed to execute: java.io.IOException: Cannot run program "/home/user/.cache/bazel/_bazel_rhang/install/7e4ce7b0d69e79cb6bd84c7f9dfefe6b/process-wrapper" (in directory "/home/user/.cache/pkgdrv/0ddf1c72b811bee41d29991c732306ef72553747/sandbox/processwrapper-sandbox/29913/execroot/__main__"): error=7, Argument list too long
ERROR: Build did NOT complete successfully
```

Digging into this issue, the cause is that the pkgjson command takes in
all of the fields of package archive data as arguments.

To work around this, we should preserve the original approach of writing
a pkg json, before #4338,
which used Skylark builtins to write the package content directly to
disk.

The pkgjson command is updated to parse ths json file directly and write
out a transformed pkg json with the cgo related corrections in order to
avoid limits regarding argument size.

Note:
    
This diff also makes changes to undo a breaking change (i.e. changing
the signature of the make_pkg_json function) that was made in
#4338.

I revert changes to the functionalty of make_pkg_json and add a new
replacement function make_pkg_json_with_archive.

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

We previously didn't show any error when an analyzer panicked and Bazel
would show a "mandatory output not created" error for the nogo action.

**Which issues(s) does this PR fix?**

**Other notes for review**

**What type of PR is this?**
Bug fix for Nix

**What does this PR do? Why is it needed?**
The current implementation depends on `mktemp` and `rm` being in the
PATH, which they're not on Nix. This alternative construction executes
`go build` directly without run_shell or the coreutils deps.

While here, I set a few extra env vars to disable new Go features we
don't want (GOTELEMETRY, GOENV).

If this works, we may be able to remove the Windows codepath.

**Which issues(s) does this PR fix?**

Fixes #

**Other notes for review**

Co-authored-by: Jay Conrod <jay@engflow.com>

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

This results in an empty version when rules_go is used as an override,
which should avoid the warning reported in
#4380.

**Which issues(s) does this PR fix?**

Fixes #4380

**Other notes for review**

<!-- Thanks for sending a PR! Before submitting:

1. If this is your first PR, please read CONTRIBUTING.md and sign the
CLA
   first. We cannot review code without a signed CLA.
2. Please file an issue *first*. All features and most bug fixes should
have
an associated issue with a design discussed and decided upon. Small bug
   fixes and documentation improvements don't need issues.
3. New features and bug fixes must have tests. Documentation may need to
be updated. If you're unsure what to update, send the PR, and we'll
discuss
   in review.
4. Note that PRs updating dependencies and new Go versions are not
accepted.
   Please file an issue instead.
-->

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

When run with `go test -cover`, the following test does not panic:

```
-- foo.go --
package foo

func foo() int {
	return 42
}
-- foo_test.go --
package foo

import (
	"flag"
	"testing"
)

func TestReassign(t *testing.T) {
	flag.CommandLine = flag.NewFlagSet("test", flag.ExitOnError)
	_ = foo()
}
```

However, with `bazel coverage`, it does panic:

```
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x100f8dbe4]

goroutine 1 [running]:
github.com/bazelbuild/rules_go/go/tools/bzltestutil.ConvertCoverToLcov()
        external/io_bazel_rules_go/go/tools/bzltestutil/lcov.go:39 +0x54
github.com/bazelbuild/rules_go/go/tools/bzltestutil.lcovAtExitHook()
        external/io_bazel_rules_go/go/tools/bzltestutil/lcov.go:181 +0x1c
github.com/bazelbuild/rules_go/go/tools/bzltestutil.LcovTestDeps.SetPanicOnExit0({{}, 0x18?}, 0x4b?)
        external/io_bazel_rules_go/go/tools/bzltestutil/lcov.go:175 +0x24
testing.(*M).after(0x1400007c280?)
        GOROOT/src/testing/testing.go:2374 +0x74
testing.(*M).Run(0x1400007c280)
        GOROOT/src/testing/testing.go:2185 +0x940
main.main()
        bazel-out/darwin_arm64-fastbuild/bin/go_default_test_/testmain.go:157 +0x7a4
```

The cause is that the test reassigned `flag.CommandLine`
and did not restore the original value.
While that's bad behavior, `go test` does not explode,
so neither should `bazel coverage`.

This change fixes the issue by grabbing a reference to
`flag.CommandLine` before the test runs.

**Which issues(s) does this PR fix?**

Fixes #4383

**What type of PR is this?**

Other

**What does this PR do? Why is it needed?**
It's relatively common for users to add `proto_library` to the `deps` of
go_proto_library. The resulting error message (which complains about a
missing attribute) is rather confusing, so let's improve it a bit.

**Which issues(s) does this PR fix?**

somewhat arguably fixes #4069

**Other notes for review**

---------

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

**What type of PR is this?**
Cleanup

**What does this PR do? Why is it needed?**
The `_cgo` messaging was added in 2018-2019. The `native.alias` is from
2021. Users have had a few years to address these warnings.

**Which issues(s) does this PR fix?**

Fixes #

**Other notes for review**

<!-- Thanks for sending a PR! Before submitting:

1. If this is your first PR, please read CONTRIBUTING.md and sign the
CLA
   first. We cannot review code without a signed CLA.
2. Please file an issue *first*. All features and most bug fixes should
have
an associated issue with a design discussed and decided upon. Small bug
   fixes and documentation improvements don't need issues.
3. New features and bug fixes must have tests. Documentation may need to
be updated. If you're unsure what to update, send the PR, and we'll
discuss
   in review.
4. Note that PRs updating dependencies and new Go versions are not
accepted.
   Please file an issue instead.
-->

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

The stdlib_json_file contains paths of compiled cgo files, which are in
the stdlib cache_dir. The gopackagesdriver reads those files, but this
dependency was not explicitly declared previously.

Usually, it works despite the missing dependency. But when you have a
Bazel cache configured, and then run `bazel clean` and run the
gopackagesdriver again, Bazel will not restore the cache_dir from the
Bazel cache. The gopackagesdriver then fails with an error like this:

error: unable to load JSON files: unable to resolve imports: open
[...]/bin/external/rules_go+/stdlib_/gocache/a4/a4f91e8314b27a4bce0e8fbc01bb9736cb9ed10da747af722c5a4f2fcb1213a3-d:
no such file or directory

This change adds a new output group containing the stdlib cache_dir, and
requests this from the gopackagesdriver, fixing the problem.

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

My company has a complicated, uncommon bazel set up with nested bazel
modules. We also use cgo extensively and have many go tests and binaries
that end up linking to shared C++ libraries generated via other bazel
modules. When such go tests are run with rbe, they fail due to failure
to locate the shared libraries within the runfiles directory.

On deeper investigation, I found that the existing `rpath` computation
assumes that both the executable and the library are present within the
working directory. In reality, the executable is present outside the
working directory but within the runfiles directory.

Normalizing the paths with respect to the runfiles directory fixes the
issue.

Relevant links:
- bazelbuild/bazel#14307

**Other notes for review**

I added a test to verify that rpath computation works with nested
modules. In fairness, this mainly guarantees that there's no regression
in existing functionality as the test passes even without my fix. So
far, I've not been able to produce a minimum example that showcases the
problem.

Existing tests in tests/core/cgo also exercise rpath computation.

---------

Co-authored-by: Dhiraj Goel <dhirajgoel@intrinsic.ai>
Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>

…4386)

**What type of PR is this?**

Bug fix

**What does this PR do? Why is it needed?**

Pass ldflags to cgo tool via a response file instead of `CGO_LDFLAGS`
env variable for go 1.23+. This avoids the "argument list too long"
error, which can happen if `CGO_LDFLAGS` is so large that it exceeds the
system limits.

Support to accept ldflags via file was added to `go` more than a year
ago. References:
- https://go-review.googlesource.com/c/go/+/584655
- Discussion: golang/go#66456

**Which issues(s) does this PR fix?**

Fixes #2654

---------

Co-authored-by: Dhiraj Goel <dhirajgoel@intrinsic.ai>
Co-authored-by: Jay Conrod <jay@engflow.com>

**What type of PR is this?**

Documentation

**What does this PR do? Why is it needed?**

bazel-contrib/bazel-gazelle#2125 renamed a file.

**Which issues(s) does this PR fix?**

N/A

**Other notes for review**

**What type of PR is this?**

Feature

**What does this PR do? Why is it needed?**

This moves the download of the "all versions" JSON, which can't hit the
repository cache, from each individual `go_download_sdk` into the module
extension. If the current version of Bazel supports facts, this
information will also be persisted in the lockfile, allowing for truly
airgapped builds assuming an up-to-date download (formerly repository)
cache.

See bazelbuild/bazel#26198 for the PR that adds
facts support to Bazel.

**Which issues(s) does this PR fix?**

Fixes #3945 

**Other notes for review**

Fixes
https://buildkite.com/bazel/rules-go-golang/builds/8008#01980e83-4469-4967-99a6-f8993a52bbcc

**What type of PR is this?**

Feature

**What does this PR do? Why is it needed?**

Implements support for the new format added in
bazelbuild/bazel#26262.

**Which issues(s) does this PR fix?**

Fixes #

**Other notes for review**

#4404)

**What type of PR is this?**

Cleanup

**What does this PR do? Why is it needed?**

**Which issues(s) does this PR fix?**

Fixes #

**Other notes for review**

**What type of PR is this?**

Performance improvement

**What does this PR do? Why is it needed?**

Avoid unnecessary work by skipping analyzers that don't emit facts when
reported diagnostics are known to be ignored.

**Which issues(s) does this PR fix?**

Work towards #4327

**Other notes for review**

**What type of PR is this?**

Feature

**What does this PR do? Why is it needed?**

By tagging a target with `"no-nogo"`, `nogo` isn't run at all, not even
for fact generation.

**Which issues(s) does this PR fix?**

Work towards #4327

**Other notes for review**

go1.25 removes the current runtime code coverage system adopted by
rules_go (nocoverageredesign)
https://go-review.googlesource.com/c/go/+/644997
which makes rules_go incompatible with the latest upcoming version of
go.

The change completely adopts the new integration test friendly
coverageredesign
system (https://go.dev/blog/integration-test-coverage) in rules_go.

Below I describe how the current rules_go coverage system currently
works, what
changes in the new coverage redesign, and what needs to change as a
result in
rules_go.

How nocoverageredesign currently works:

- rules_go invokes `go tool cover` to generate instrumented source files
that
are then passed to the Go compiler (in compilepkg.go). Instrumented
source
files update generated package variable counters.

- The rules_go generated test main (generate_test_main.go) calls
testing.RegisterCover to set a global variable that tracks references to
coverage generated package local variables that coverage instrumented
code
modify (ref:
https://github.com/golang/go/blob/go1.24.5/src/testing/cover.go#L72)
This replicates the behavior in go test's generated test main
(cmd/go/internal/load/test.go)

- rules_go specially adds a call to coverdata.RegisterFile call to all
coverage
instrumented files which connects each of the file coverage counter
variables
with a global object and enables rules_go to customize the file name
that
coverage variables are associated with.

- It's important to note that because rules_go accesses to this global
coverage struct,
it's able to manipulate the file path name associated with coverage
counter variables.
This is important because the lcov format that bazel uses expect exec
root relative files.

- When a test exits, This global object is flushed in a call to
`testing.coverReport()` to
generate a coverage report. This reports gets written a file configured
in
test.coverprofile flag.

- Via a special SetPanicOnExit0 hook, the coverage file set in
test.coverprofile
is coverted to a Bazel friendly Lcov format via logic in
bzltestutil/lcov.go

What changes in coverageredesign:

- A new flexible system for configuring coverage behavior. Instead of a
single
esting.RegisterCover function, there is a new testdeps package that
exposes hooks
to configure behavior.

- The global variable
(https://github.com/golang/go/blob/go1.24.5/src/testing/cover.go#L72)
that tracked all coverage data is completely removed. Instead, functions
in https://pkg.go.dev/internal/coverage/cfile that are called when
writing coverage reports on test exit are internally aware of and able
to access coverage counter variable data.

- Functionality to flush coverage counter variables write to an
intermediate
coverage directory in a binary format. Hooks configured in the testdeps
package
are responsible for translating this binary format into a human readable
coverage
output file.

- 'go tool cover' takes a new package based configuration "pkgcfg"
option that
enables this new coverage instrumentation logic in coverage source
files.

- Coverage counters can be flushed on demand via the APIs of
"runtime/coverage"
This allows coverage to work outside of test situations where coverage
used to rely on exit hooks generated into test mains to flush and write
coverage data.

What needs to change in rules_go as a result:

- Use the new testdeps configuration system in the rules_go generated
test main.
We can following the example of the go test generated test main.
ref:
https://github.com/golang/go/blob/go1.24.5/src/cmd/go/internal/load/test.go#L986

- Invoke 'go tool cover' with the new -pkgcfg flag. We can follow the
example of
how the go toolchain invokes coverage redesign instrumentation in

https://github.com/golang/go/blob/go1.24.5/src/cmd/go/internal/work/exec.go#L1932

- Not strictly necessary but removes technical debt, call
bzltestutil.ConvertCoverToLcov
inside of testdeps.CoverProcessTestDirFunc hook wrapper  instead of the
bzltestutil.LcovTestDeps SetPanicOnExit0 hook.

- Adjust the output of lcov profile to make file path keys in coverage
files
execution root relative.

Implementation Note:

Unfortunately, we still need
github.com/bazelbuild/rules_go/go/tools/coverdata
dependencies in coverage source files because the lcov coverage format
expects file paths associated with coverage data to be execution root
relative. coverageredesign writes Go coverage file data in the format of
`importpath/file_name` which is not execution root (e.g. `src/`)
relative.

During compilation is the only place we have the information to map
`importpath/file_name` to an execution root relative path so we have
to continue to use the trick of generating code that corrects the
file path coverage mapping at runtime.

This makes it hard for coverage to work outside of tests because depend
on a special
github.com/bazelbuild/rules_go/go/tools/coverdata dependency that can't
be
guaranteed because we don't control a generated test main in these
situations.

If Go coverage filepaths can be configured during invocations of the `go
tool cover`, we can break this dependency. I've filed an upstream go
ticket
to descrbe this issue golang/go#74749.

ref #3513