nogo rule causes ambiguous bazel-bin, bazel-testlogs directories in Bazel 6.0.0

[LINKIWI]

What version of rules_go are you using?

v0.37.0

What version of gazelle are you using?

None

What version of Bazel are you using?

6.0.0

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

Yes

What operating system and processor architecture are you using?

$ uname -srvio
Linux 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 GNU/Linux

Any other potentially useful information about your toolchain?

What did you do?

Please see the below for a minimally reproducible example.

.bazelversion:

6.0.0

WORKSPACE:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "io_bazel_rules_go",
    sha256 = "56d8c5a5c91e1af73eca71a6fab2ced959b67c86d12ba37feedb0a2dfea441a6",
    urls = [
        "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.37.0/rules_go-v0.37.0.zip",
        "https://github.com/bazelbuild/rules_go/releases/download/v0.37.0/rules_go-v0.37.0.zip",
    ],
)

load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")

go_rules_dependencies()

go_register_toolchains(
    nogo = "@//:lint",
    version = "1.19.3",
)

BUILD:

load("@io_bazel_rules_go//go:def.bzl", "nogo")

nogo(
    name = "lint",
    visibility = ["//visibility:public"],
)

Invocation:

$ bazelisk build //...

What did you expect to see?

bazel-bin symlink is valid and created.

What did you see instead?

bazel-bin is not created due to ambiguous destinations:

INFO: Invocation ID: 84e6b1d4-b26b-4a91-b30c-4459ff3f3088
INFO: Analyzed 2 targets (1 packages loaded, 38 targets configured).
INFO: Found 2 targets...
WARNING: cleared convenience symlink(s) bazel-bin, bazel-testlogs because their destinations would be ambiguous
INFO: Elapsed time: 0.198s, Critical Path: 0.01s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

Note that:

• This is a regression starting with Bazel 6 (the symlinks are created properly on Bazel 5)
• Removing the nogo target in BUILD, and removing the nogo parameter in go_register_toolchains, causes the symlink to be created correctly

The warning is sourced from here: https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildtool/OutputDirectoryLinksUtils.java#L172

To debug, I compiled a version of Bazel with additional debug logging, and found that the two candidate paths for bazel-bin are:

/home/kiwi/.cache/bazel/_bazel_kiwi/89a35363ec8de7131a16c2ed7419999a/execroot/__main__/bazel-out/k8-fastbuild/bin
/home/kiwi/.cache/bazel/_bazel_kiwi/89a35363ec8de7131a16c2ed7419999a/execroot/__main__/bazel-out/k8-fastbuild-ST-e0d274b3679e/bin

When I remove nogo, there is only one candidate path for bazel-bin, as expected.

[fmeum]

The way in which top-level symlinks are created changed in bazelbuild/bazel@6452024. Since the nogo rule applies a transition to itself, it adds another configuration to the top-level ones.

I have a fix that I will submit shortly.

[vihangm]

@fmeum This is also an issue with go_cross_binary rules. Can you also fix those?

[fmeum]

@vihangm The situation for them is different: go_cross_binary targets are built in a meaningfully different configuration than other top-level targets. If the new symlink strategy aims to not create the convenience symlinks if they would be ambiguous, then I think having your pattern match both go_cross_binary and other targets is such an ambiguous situation.

You can always add the manual tag or perhaps an appropriate target_compatible_with to a go_cross_binary target to prevent this.

[vihangm]

@fmeum That sounds reasonable. Adding the manual tag fixes the problem.

I guess my expectation was that go_cross_binary should probably not match wildcards and hence should be manual by default, but perhaps that's not what other people might expect. So your recommendation is more general and flexible.