Using _osx.go suffix will evict the file from go_library srcs attribute when using darwin platform

[Zenithar]

What version of gazelle are you using?

0.39.1

What version of rules_go are you using?

v0.50.1

What version of Bazel are you using?

6.5.0

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

Yes

What operating system and processor architecture are you using?

• darwin
• arm64

What did you do?

While using the awnumar/memcall, and more precisely the memcall_osx.go, it looks like running bazel run //:gazelle on a darwin/arm64 machine will generate a go_library without this file included.

I created a suffix_osx.go in the language/go/test data/platforms from the content of the suffix_darwin.go and executed tests; it looks like the file is ignored as the unmodified golden BUILD.want doesn't trigger a difference.

Alternatively, adding "osx": {"darwin"} into the OSAliases in

bazel-gazelle/rule/platform.go

Line 108 in da0ad18

var OSAliases = map[string][]string{

looks to fix the issue, but has side effects I can't judge.

What did you expect to see?

go_library(
    name = "memcall",
    srcs = [
        "memcall.go",
        "memcall_freebsd.go",
        "memcall_openbsd.go",
        "memcall_unix.go",
+       "memcall_osx.go",
        "memcall_windows.go",
    ],

What did you see instead?

go_library(
    name = "memcall",
    srcs = [
        "memcall.go",
        "memcall_freebsd.go",
        "memcall_openbsd.go",
        "memcall_unix.go",
-       "memcall_osx.go",
        "memcall_windows.go",
    ],

[Zenithar]

I understand that _osx is not a valid GOOS, but the file has a valid go-build tag targeting darwin platform. So, the library works as expected with a native unmanaged Go toolchain, while a Bazel-managed tool ignores this file.

[Zenithar]

The PR - awnumar/memcall#14 - fixed the conventional naming issue from the library PoV.