Archive mode does not match when pure = off

[leungster]

What version of rules_go are you using?

0.51.0

What version of gazelle are you using?

0.40.0

What version of Bazel are you using?

Bazel 8.0.0

Does this issue reproduce with the latest releases of all the above?

Yes

What operating system and processor architecture are you using?

Darwin/ARM

Any other potentially useful information about your toolchain?

What did you do?

When crosscompiling a go_binary with goos, goarch, and pure = "off" I'm getting a mode mismatch error.
This error happens on both our CI runner (linux/amd) and locally on a M1 macbook.

    go_binary(
        name = "target",
        embed = embed,
        goarch = "arm64",
        goos = "darwin",
        pure = "off",
    )

What did you expect to see?

The target should build without error. This worked in 0.50.1.

What did you see instead?

Error in fail: Archive mode does not match @@//:target is darwin_arm64_debug expected darwin_arm64_debug

If I print a.source.mode and go.mode from this line, I get the same struct values.

// Debugged from CI hence different arch/os/linkmode

// a.source.mode
struct(amd64 = "", arm = "", cover_format = "lcov", debug = False, gc_goopts = [], gc_linkopts = [], goarch = "amd64", goos = "linux", linkmode = "pie", msan = False, pgoprofile = None, pure = False, race = False, stamp = False, static = False, strip = True, tags = [])

// go.mode
struct(amd64 = "", arm = "", cover_format = "lcov", debug = False, gc_goopts = [], gc_linkopts = [], goarch = "amd64", goos = "linux", linkmode = "pie", msan = False, pgoprofile = None, pure = False, race = False, stamp = False, static = False, strip = True, tags = [])

[ash2k]

Have the same issue. Trying to update rules_go from 0.50.1 -> 0.51.0 and getting a build failure:

(12:06:10) ERROR: /builds/gitlab-org/cluster-integration/gitlab-agent/cmd/kas/BUILD.bazel:16:23: in go_binary rule //cmd/kas:kas_linux_amd64_debug: 
Traceback (most recent call last):
	File "/home/ci/.cache/bazel/_bazel_ci/9ca8268df963885560ea55034139bea5/external/rules_go~/go/private/rules/binary.bzl", line 145, column 46, in _go_binary_impl
		archive, executable, runfiles = go.binary(
	File "/home/ci/.cache/bazel/_bazel_ci/9ca8268df963885560ea55034139bea5/external/rules_go~/go/private/actions/binary.bzl", line 43, column 25, in emit_binary
		archive = go.archive(go, source)
	File "/home/ci/.cache/bazel/_bazel_ci/9ca8268df963885560ea55034139bea5/external/rules_go~/go/private/actions/archive.bzl", line 78, column 17, in emit_archive
		fail("Archive mode does not match {} is {} expected {}".format(a.data.label, mode_string(a.source.mode), mode_string(go.mode)))
Error in fail: Archive mode does not match @@//cmd:cmd is linux_amd64_race_stripped expected linux_amd64_race_stripped
(12:06:10) ERROR: /builds/gitlab-org/cluster-integration/gitlab-agent/cmd/kas/BUILD.bazel:16:23: Analysis of target '//cmd/kas:kas_linux_amd64_debug' failed

The target is defined like this (via a layer of macros):

    go_binary(
        name = binary_name,
        embed = binary_embed,
        goarch = "amd64",
        goos = "linux",
        race = "on",
        tags = ["manual"],
        visibility = ["//visibility:public"],
        x_defs = _x_defs,
    )

• Defined in https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/ed1aac14a057630d36a4a7145e246c01b6c3f031/cmd/kas/BUILD.bazel#L16-21
• Macros are here https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/ed1aac14a057630d36a4a7145e246c01b6c3f031/cmd/cmd.bzl
• Bazel v7.4.1
• Gazelle v0.40.0
• Linux amd64

[fmeum]

I think that this broke in 5933f87 since struct and named providers such as GoConfigInfo are considered distinct even if they have the same fields. I don't know why our tests didn't catch this.

We could try to always use GoConfigInfo. @dzbarsky

I will also send a Bazel PR to add the provider type to the debug representation.

[dzbarsky]

Sorry for the breakage, sounds like we may be missing some coverage :) I can probably take a look in the next few days unless @fmeum you get to it first?

[dzbarsky]

I couldn't figure out a way to repro (if yall have an easy repro to add to rules_go, let's do it) but hopefully #4203 should fix it