go_binary: Add support to set a default GODEBUG per binary

[zecke]

Go supports setting default GODEBUG values in the go.mod file or per directive in the main package at the right location. This currently does not work with rules_go/gazelle.

Introduce an explicit godebug_default attribute on go_binary so that gazelle can easily manage it.

Supports bazel-contrib/bazel-gazelle!1945

What type of PR is this?

Uncomment one line below and remove others.

Bug fix
Feature
Documentation
Other

What does this PR do? Why is it needed?

Which issues(s) does this PR fix?

Fixes #

Other notes for review

[fmeum]

Thanks for working on this, but I think that an attribute on go_binary is the wrong location for this feature. Having potentially different semantics for the same line of code depending on the downstream consumer it is built for seems like too much of a foot gun.

Go language version and GODEBUG could be made configurable on a Go SDK and, with Bzlmod, directly via go.mod.

[zecke]

Thanks for working on this, but I think that an attribute on go_binary is the wrong location for this feature. Having potentially different semantics for the same line of code depending on the downstream consumer it is built for seems like too much of a foot gun.

My idea was to handle this like //go:embed. Have gazelle parse the .go files files and generate the go_binary based on the directives observed. Do you think something like rules_go's builder should scan the .go file to extract the directives from the main package?

//go:debug http2server=0
package main

const foo = 123

[abhishekmunie]

It would be ideal if developers could define these settings using the mechanisms described in https://go.dev/doc/godebug, and have Gazelle automatically translate them into the appropriate Bazel configurations. Currently, this inconsistency leads to confusion, as behavior differs between using the Go toolchain directly and using Bazel.

This discrepancy is also hindering migration to Bazel—features that previously worked under CMake are now breaking. If //go:debug is not the correct or intended approach, that should be clarified and addressed in the Go community, ideally through discussions in the appropriate forums.

Ultimately, rules_go should aim for feature parity with the standard Go toolchain to ensure a smooth and predictable developer experience.

ref: bazel-contrib/bazel-gazelle#1945

[fmeum]

Support for godebug directives could be added to Gazelle's go_deps extension. //go:debug lines would ideally be picked up by the Go compiler/linker (or rules_go's wrapper around them) without Gazelle even being involved.

Happy to support any contributions in this area. The problem with feature parity with native Go is that many of these features are spread across the internals of the Go compiler and the Go build system and these are not covered by backwards compatibility guarantees or even official documentation.