Fabian Meumertzheim

I followed up on the goleak thread, maybe we can solve this by introducing an ignore mechanism that rules_go can use and goleak doesn't have to maintain.

Could we have both? Always specify `test.v` in the wrapper and use the output to populate the XML file, but by default filter out most lines. I could see this...

> Should go_register_toolchains just allow to specify go.env file? This was actually my first thought as well, but I now see undesirable side effects: The env variables one typically wants...

@linzhp makes a very good point. I will change the name of the `go_env` attribute to something like `go_fetch_env` to make it clear that build-related env vars won't be read.

I submitted https://github.com/bazelbuild/bazel-gazelle/pull/1748 instead, which moves the new `go_env` field to `go_deps`, hopefully making it more clear that this is only targetted at fetching of Go deps. What do you...

This is on my radar, but I plan to solve it by excluding the `go_sdk` extension from the lock file altogether. It is fully deterministic and essentially static, so it...

@JamyDev added a basic test that you could extend (if possible): tests/integration/gopackagesdriver/gopackagesdriver_test.go

@jayconrod There is still a failure on Bazel 5.4.0. I think it's fine if this fix doesn't support that version, so if you rather want to disable the test in...

This should be working. Could you share a self-contained reproducer? Also take a look at `@rules_go//go/runfiles`, a library that helps you find data files at runtime.

> In fact, I think @fmeum mentioned something about `*.x` files might already contain some of the analysis data to help aid compilation? I still haven't been able to delve...